Usual apology : This description is obviously not finished yet. It isn't at the top of my list of priorities either, but if you're interested please ask me if you want any more information.
Languages have interested me for as long as I can remember. That hasn't made me a polyglot - I speak only English with any degree of fluency - but I find the machinery of language an absorbing subject. At school I was fascinated by the ideas of sentence structure and parsing ( that was a long time ago ), and when I found that similar topics were important in computer languages I set to to find out about them. Since then, languages - both natural and programming - have turned up from time to time in things I've done. This is no longer a primary preoccupation, but I thought I'd draw it all together for my own interest.
My direct acquaintanceship with programming languages began when I learnt Fortran in 1961. ( It was actually Gotran, a sawn-off Fortran simple enough to be interpreted by a programme resident in the memory of an IBM1620 computer, but close enough to Fortran to count. ) I gave my first lecture course in Fortran in Singapore around 1965; at the time, I had not written a real Fortran programme, but as we didn't have a computer that didn't matter too much. Other languages followed as the occasion demanded.
By the time I left Singapore and changed into a computist, I was moderately knowledgeable about the idea of parsing and compiling, and sufficiently confident to offer myself to ICL as one who could write compilers. ( In hindsight, my confidence was probably just about justified. ) ICL responded by setting up an interview for me with an operations research specialist; neither of us could work out why, but we had an enjoyable dinner.
My second try at inventing a language of my own produced Lilac ( List-Implemented List-Applicable Compiler : the acronyms get worse from here on ) in about 1972. The Lilac language was a functional language with reverse-Polish parenthesis-free syntax which implemented standard list operations head, tail, and cons. There was provision for saving values ( set ), literals, conditionals, primitive input and output, arithmetic, and some other things. The compiler worked by scanning the input instructions backwards, which makes sense for a reverse-Polish expression.
Lilac itself was implemented in assembly language using my first try at inventing a language of my own. That was CLIST, a set of macros I'd written to support a short course in list processing we gave at Derby. Proper garbage collection was provided ( and worked ). In effect, CLIST set up a model of a stack machine and used this to manage the list structures. Very little remains of CLIST, and therefore of Lilac; the manual is all there is, and it includes a few pages of CLIST macro descriptions.
Then I came to Auckland, and started implementing other people's languages. The first was Cobol. Having made myself known as interested in languages, I was the natural choice when the Accountancy department wanted someone to present a course on Cobol to their students. ( That seemed to me a bit like choosing an expert musician to shift a piano, but at least it gave me a chance to fiddle about ( pun intended ) with some interesting ideas. ) A minor difficulty when learning Cobol is that you have to write the first three divisions, all about data declarations, before you can get down to any programming. That's tedious, and it means you have to learn lots before you can do anything. I thought I could make a Cobol compiler which would make sensible assumptions and put in the declarations for you, so you could start with the programme part ( the Procedure Division ), and write working programmes from the start. I did; it was called Stubol. There's a tutorial text and a technical report if you're interested.
The next language was Basic. This was a computer centre effort, mounted when minicomputers became cheap enough to be realistic as machines to use for programming in university departments or schools. We acquired a Computer Automation Alpha LSI machine, with a memory of 8K 16-bit words; it was advertised as the first minicomputer to cost less than $10000. ( Dollars in the late 1970s were a lot bigger than they are now. ) Three of us worked on the system : Nevil Brownlee wrote the operating system, Peter Fenwick provided the arithmetic software, and I did the interpreter for the language. It was all assembly language, and it all worked, once we'd worked out that Peter had written his arithmetic using a stack which grew downwards, and I'd written the interpreter with a stack which grew upwards. Furthermore, it worked without a disc or other backing store, and could only be reloaded, arduously, from mark-sense cards. ( That's not quite true; the version we ran in the computer centre could be loaded from the B6700 machine, which was quite a bit easier, but the real method, intended for use in remote sites like the mathematics department, was to use the mark-sense card reader.
We were fairly unimpressed by the ad hoc versions of Basic we found around us, so went to some pains to define a consistent Basic; you could have conditional operators in expressions, function bodies could be assigned like variables, and other desirable features made our Basic unique. It's interesting to think that at about the same time Bill Gates was writing a significantly inferior version of Basic; perhaps it's a bit unfortunate that we had other things to do as well. Our Basic was never well documented; there's a tutorial text, not quite finished, and an even less finished working note.
A later development for the Alpha LSI machine was a rather curious assembler called ASPIC. Aspic was intended ( and used ) for teaching assembly language on the Alpha LSI minicomputer. The odd features of Aspic were to a great degree directed by the stand-aloneness of the computer ( see above ). As assembly-language programmes are notoriously prone to misbehaviour, it was not practicable to provide a real assembler in a machine which might take several minutes to reload, so Aspic was constructed with an interpreter for the machine on which it was normally executed. By this means, a degree of protection was attained, and it worked. A programme could also be run with the real hardware if desired, which was necessary for realistic input and output, but at least you could do a lot of testing in comparative safety.
Other activities connected with programming languages have included :
A list of things :
Go to me ( Alan Creak, in case you've
Go to Computer Science.