My first programming languages were Fortran, Compass (CDC 3000 assembly language), Basic, Algol, and Business Basic.
My next language was PLZ/SYS in 1978. It taught me a lot about language design, and that you can have brilliance and its opposite in the same language. That insight benefitted me tremendously over the rest of my career.
PLZ/SYS was produced by Zilog, a microcomputer chip company. Their most famous product was the Z80, an unauthorized and superior sequel to Intel's 8080. The Z80 is still in production.
Zilog also produced development systems because personal computing had not happened yet. These systems came with assemblers, linkers, and operating systems.
PLZ was to be their family of programming languages. These were minimalish languges, designed specifically for the little chips, all sharing a core grammar:
Two languages were released:
PLZ/SYS was realized as four programs:
Zcode was a bytecode stack language, inspired by BCPL's ocode, which was inspired by the Burroughs 5000 instruction set. UCSD Pascal pcode and Java bytecode are similar.
An executable could be made of zcode or obj or a mixture. Zcode was considerably smaller than obj because the Z80 instruction set design was not optimized for high level languages. So you could use obj and pay a memory penalty, or zcode and pay a time penalty. Ideally, you could blend, with seldom used code in zcode, and critical code in obj. The source code did not know or care.
PLZ had many influences. It borrowed typed declarations and pointer notation from Wirth's Pascal.
pointer: ^cat pointer^.lives -= 1
It borrowed increment operators and the bad idea of an address operator Ritchie's C. PLZ uses #octothorpe instead of the overloaded &ersand.
The control structures were borrowed from Algol 68.
if condition
then
...
else
...
fi
Loops were simple.
do ... od
An explicit exit was needed to terminate a loop.
The primitive types were
These names were great for a while, but as architectures grew into 32 and 64 bits, they became problematic, just as in C.
The designers of PLZ came from a variety of backgrounds and experiences. They clearly had conflicting opinions on style that they were unable to resolve.
At the time, lower case was beginning to become popular, but the majority of programmers had not yet transitioned. PLZ accomodated this by allowing the keywords to be all uppercase or all lowercase.
In the PLZ literature, there were example programs that were all uppercase, upper case with lower case keywords, lower case with upper case keywords (the style I preferred at the time), and all lowercase.
More troublesome, :colon which was used in declarations and loop
labelling, ,comma which separated arguments and array elements,
and ;semicolon which separated statements, were all treated as
whitespace. This was a compromise to allow all styles to be practiced, even the bad ones.
The punctuators provide redundancy which can expose errors. But the program the human sees can be
quite different from the program the compiler sees. That is trouble.
For example,
ARRAY [1, 0, -1]
is seen by the compiler as
ARRAY [1, -1]
The -minus sign is both an infix operator and a prefix operator. Because the ,comma disappears, the -minus sign subtracts instead of negating. They added a neg operator as a mitigation, but it does not help.
PLZ allows a procedure that takes no arguments to be called without the ()parens suffix. If such a function name is misspelled and the next statement is do, the compiler assumes that the misspelled function is actually a loop label and no error is generated. This confusion is due to the :colon after a label being unnecessary.
Comments begin and end with !exclamation point! That worked poorly.
It was too easy to forget to put in a closing !exclamation point!
You could not put !exclamation point in a comment to mark something important!
You could not comment out code that contained a comment!
If you make an even number of mistakes, it was possible that no error was reported and part of
your program was silently deleted!
It would have been better to make the comment end at the end of the line.
Most of PLZ was brilliant and I liked working with it. But I was burned by the design mistakes. The lesson I learned was that correctness is more important than opinions about personal style. These lessons stayed with me, which is why I am critical about style slop in other languages. It is why I designed JSLint the way I did to help defend programmers (especially me) from the design mistakes in JavaScript.
I like PLZ's module structure.
name: module
! The sections of your module go here!
end name
There are sections that can appear in your module: type, constant, external, internal, global. Each section contains a list of things. I thought it worked much better than the extern, static sillyness of C.
The grammar of the language was expressed with => statements. For example:
module => module_identifier module declarations* end module_identifier
declarations
=> constants
=> types
=> globals
=> internals
=> externals
constants => constant constant_definition*
types => type type_definition*
globals => global var_or_proc_declaration*
internals => internal var_or_proc_declaration*
externals => external restricted_var_or_proc_declaration*
constant_declaration => identifier := constant_expression
I liked this notation and wanted to use it on the JSON project. I wrote to Bill McKeeman, who was a consultant on the PLZ project and asked him what it was called and what the formal rules were. He told me that he had moved past it, and was now using a minimal grammar inspired by his mentor, Niklaus Wirth (of Pascal fame). I formalized that grammar and called it McKeeman Form.