Re: Translating Algol to C or Cobol

kgg@lfcs.ed.ac.uk (Kees Goossens)

          From comp.compilers

Related articles
Translating Algol to C or Cobol deh0654@sjfc.UUCP (1989-05-16)
Re: Translating Algol to C or Cobol kgg@lfcs.ed.ac.uk (1989-06-15)
Re: Translating Algol to C or Cobol juliar@hpcll17.HP.COM (1989-06-06)
| List of all articles for this month |

Newsgroups: comp.compilers
Summary:
Expires:
References: <3893@ima.ima.isc.com> <539@sjfc.UUCP>
From: kgg@lfcs.ed.ac.uk (Kees Goossens)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Keywords: ALGOL, C, translation

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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.