-I've begun writing an Algol W [Compiler] for historical reasons[1]. __(Actually, this is on hold, I've found other things to do, but if this project interests you then please contact me.)__ One reason: Algol W was the first language to support [DataStructure]s as types, that's a fairly significant step. There are OpenSource implementations of Algol 60[4] and Algol 68[5] but none yet for this third dialect, Algol W. --GlynWebster 

-It was not [Pascal]. Then it was not [C]. OS/360 is not that popular a platform anymore. Algol W was rejected as the template language for Algol 68. NicolasWirth went on to invent [Pascal], which superseded Algol 60 and Algol W in schools. The Stanford Algol W [Compiler] seems to have had annoying limitations. And there was that whole "Is this GoTo really necessary?" thing. Historical reasons, like I said. :-) 

-I intend to make my implementation compatible with the Stanford Algol W [Compiler][3 ]. That seems to be the one that was most used , and it's one I have documentation for . 

-I'm writing in standard [C], and the [Compiler] will generate [GNU] [C] code . [Algol ]- and [Pascal ]-like languages can be translated into [GNU] [C] simply and directly because of [GNU ]'s extensions to the [C] language. (See gcc(1).) They fit so well to this task that I think this is the very reason [GNU] added them. Statement expressions, nested functions, variable length arrays and inline functions are the ones Algol W will need. Algol W programs need a garbage collector. I'm thinking of using the Boehm collector[8]. I'm writing in [C] just to reduce the number of tools necessary for someone else to get the [Compiler] going[7], although I'd prefer to be using [OCaml] for something like this. I might use [Splint | http://lclint.cs.virginia.edu/] annotations to try to take the curse off [C] . 

-I was thinking of modifying the [GNU Marst | http://www.gnu.org/software/marst/][4] [Compiler] to accept Algol W but Algol 60 and Algol W are enough different that I think the [GNU] [C] route might be easier.  

-I don't intend to extend the Algol W language. (If I want a nicer language I should to be designing a modern one of my own.) But the [Compiler] will allow inline [C] code; this is for writing the standard library and interfaces to existing [C] libraries, not general Algol W programming. And I intend to lift limits placed on the language by the Stanford [Compiler], nowadays we have the privilege of working on much better computers.  

-  

-!! Progress  

-  

-I have a Flex and Bison lexer and parser written, and buffer and symbol table modules to support them.  

-  

-I have worked out how to translate the most un-C-like features of Algol W into [GNU] C. (I didn 't want to discover it was impossible at the last moment!)  

-  

-I have translated most of the Algol W manuals from a partially [OCR]ed photostat[3] into [LaTeX], but I've decided to stop until I can get permission to republish it[2] . I was thinking of writing the [Compiler] in literate style[6], as a series of annotations and appendices to the reference document, but now I'm not so sure -- it would be copyright trouble if I wanted to release the [Compiler] under [GPL].  

-  

-!! Tasks  

-  

-; Parse tree : The part where malloc(3)s fly all over the place and the free(3)s struggle to keep up.  

-; Type analyzer: I intend this thing to be a [Compiler] rather that a translator, so no errors should crop up the [C] compilation stage.  

-; C code emitter: Translating the parse tree to [GNU] [C] code. The translation scheme needs to be well documented because programmers can include inline [C] blocks in Algol W code. They will need to know how the surrounding [Compiler]-generated [C] code is constructed.  

-; Algol W standard library (a.k.a. the prelude) : This can be written in mixed [C] and Algol code . I'd like to do two versions of this: one using native data types; one using IBM 360 types (EBCDIC characters and a different floating -point representation) so old numeric programs give exactly the expected results, and images of old data card decks can be read .  

-; Algol W manual: Find and author and ask permission to republish . I assume they're all still alive. Somewhere. (Meanwhile: does anyone know how to get pretty tables out of [LaTeX ]?)  

-; Manual and man pages: Of course . 

-[2] The editor went on to be the manager of the team designing the Alpha [CPU] chips, and now I can't find his email address. I think he's hiding from headhunters.  

-  

- [3] [Stanford University Technical Report CS-TR-71-230.pdf | ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/68/89/CS-TR-68-89.pdf] [[3.5MB], "This manual refers to the version of the Algol W [Compiler] dated 1.6 January 1972". It has a formal description of the language and a manual for its standard library is in the back, which is good. (This document was a print-out that sat in a ring-binder for years before someone scanned it with some weird OCR system that starts with a bitmap of the page, then replaces as many characters as it can with PDF text after guessing at their fonts. The system must work well on laser-printed documents, but electric-typewriter and ball-point documents seem to be just on the point were its effectivness begins to break down. The result is readable but quite weird in places.)