Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!husc6!spdcc!ima!compilers-sender
From: kgg@lfcs.ed.ac.uk (Kees Goossens)
Newsgroups: comp.compilers
Subject: Re: Translating Algol to C or Cobol
Keywords: ALGOL, C, translation
Message-ID: <4005@ima.ima.isc.com>
Date: 2 Jun 89 04:36:04 GMT
References: <3893@ima.ima.isc.com> <539@sjfc.UUCP>
Sender: compilers-sender@ima.ima.isc.com
Reply-To: kgg@lfcs.ed.ac.uk (Kees Goossens)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Lines: 47
Approved: compilers@ima.UUCP

In article <539@sjfc.UUCP> deh0654@sjfc.UUCP (Dennis E. Hamilton) writes:
>In article <3893@ima.ima.isc.com> Gordon Jenkins <gordon@pyr.gatech.edu> writes:
>>I'm looking for any information available on sources for tools to
>>aid in the conversion of ALGOL sources to C (or heaven forbid, COBOL).
>
>As the moderator commented, this would be quite a challenge.

I worked on project which translated a large subset of Algol68 to C.
The subset excluded most of the transput (IO), a more limited module
system than the original system (RS Algol68) has and some small restrictions
(eg selecting a field from an array of structures resulting in array:
[10] STRUCT INT first, REAL second END : array;
[] INT another array = first OF array; 
... # Note no ^ space! a nice feature... # )

It worked. And the generated C ran as fast as the original Algol68.
The code produces was truly horrendous.

> ...  Unfortunately, the nesting of procedures in ALGOL 
>is a very real requirement, as is the passing of closures as parameters

We had to pass environments around ourselves to get around this. Even so, 
the resultant code was runnable (rather than walkable :-).

>In no case would I expect a translation of ALGOL to COBOL to be
>intelligible to a human programmer, and the odds are that C translations
>would not be maintainable by human beings either.
> ... ALGOL translations should be at least as hairy,
>though for different reasons.

We generated unique variables names (for the module system to work)
of the form ABCDEF_orginalname to retain some of the original program.
The main problem was that we generated immense amounts of temporary
variables and brackets, mainly because it was not always possible to
tell whether something is going to evaluated more than once.

>-- Dennis E. Hamilton {uucp: ... !rochester!cci632!sjfc!deh0654}

Kees Goossens                       Keep in Touch with the Dutch:
LFCS, Dept. of Computer Science     JANET: kgg@lfcs.ed.ac.uk
University of Edinburgh             UUCP:  ..!mcvax!ukc!lfcs!kgg
Edinburgh EH9 3JZ, UK.              ARPA:  kgg%lfcs.ed.ac.uk@nsfnet-relay.ac.uk
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU
Plausible paths are { decvax | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request