deh0654@sjfc.UUCP (Dennis E. Hamilton) (05/17/89)
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. Although many ALGOL notions might be simulated in C, there is a fundamental problem. The authors of C Language eliminated the need for "closures" in any form, and even ridicule the idea (commenting on why there are not local procedures because what would it mean to put a procedure on the stack, as I recall). Unfortunately, the nesting of procedures in ALGOL is a very real requirement, as is the passing of closures as parameters (call by "name"). The absence of any reasonable way to realize equivalents of thunks (specialized closures) is a serious technical limitation. In practice, the actual programs might be translatable by virtue of not exercising full ALGOL capabilities, but that is a tough bet to make. The translation to COBOL is even more limited, of course, since COBOL has no concept of local data at all, and the only form of dynamic data binding COBOL supports is the limited case of parameter passing. You might as well translate to FORTRAN. COBOL doesn't support pointers, so it provides little comfort as a way to fake ALGOL notions in the disguise of other constructs that are available. 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. (Ask someone who has had to troubleshoot C++ by debugging the generated C code what that was like. ALGOL translations should be at least as hairy, though for different reasons. [PS: C++ really suffers from the inability to introduce closures, too.]) -- Dennis E. Hamilton {uucp: ... !rochester!cci632!sjfc!deh0654} -- 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
kgg@lfcs.ed.ac.uk (Kees Goossens) (06/02/89)
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
juliar@hpcll17.HP.COM (Julia Rodriguez) (06/07/89)
>/ deh0654@sjfc.UUCP (Dennis E. Hamilton) / 5:03 pm May 16, 1989 / >a tough bet to make. The translation to COBOL is even more limited, >of course, since COBOL has no concept of local data at all, and the >only form of dynamic data binding COBOL supports is the limited case of >parameter passing. You might as well translate to FORTRAN. COBOL >doesn't support pointers, so it provides little comfort as a way to fake >ALGOL notions in the disguise of other constructs that are available. >In no case would I expect a translation of ALGOL to COBOL to be >intelligible to a human programmer, ... Just a couple of corrections in regard to COBOL. The 85 standard (ANSI X2.23-1985) added several facilities to COBOL. Among them are: nested programs, global data, and external data. COBOL does have the concept of local/global data. It does support dynamic data binding other than parameter passing. It is true that COBOL does not support pointers. I do not think that a translation to COBOL would be less intelligible than a translation to C. Automated translations are rarely intelligible in any case. Julia Rodriguez X3J4 member [From juliar@hpcll17.HP.COM (Julia Rodriguez)] -- 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