ljdickey@water.waterloo.edu (L.J.Dickey) (12/04/89)
In article <628@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > No, I have not seen any programming language translation products that can > handle APL. The difficulty is probably the parallel operations on generic > arrays of dynamically differing size and dimension. It could be done in > C++, Ada, LISP, or other languages, but I have not seen it done. > I am not sure what the original question was, Hutchinson did not say, but translation tools from APL to other languages do exist. One example is the APL compiler written by Tim Budd. A key part of his APL compiler is a tool that translates a moderately restricted subset of APL to C for compilation. Of course Budd goes much further, since he also provides the hooks that allow the compiled code to be integrated with the other interpreted code in the workspace. The company STSC provides a compilation service on their mainframe product. This APL compiler was developed under the leadership of Clark Wiedmann. Finally, there is an APL to Ada translator developed by a major supplier of software to the US government. The creation of this tool was stimulated by the ease of software development in APL and the requirement of the buyer that their software written in Ada. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
wgh@ubbpc.UUCP (William G. Hutchison) (12/06/89)
In article <2811@water.waterloo.edu>, ljdickey@water.waterloo.edu (L.J.Dickey) writes: > > In article <628@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > > > No, I have not seen any programming language translation products that can > > handle APL. The difficulty is probably the parallel operations on generic > > arrays of dynamically differing size and dimension. It could be done in > > C++, Ada, LISP, or other languages, but I have not seen it done. > > I am not sure what the original question was, Hutchinson did not say, > but translation tools from APL to other languages do exist. Sorry, I intended this to be a personal reply, not a broadcast one. > One example is the APL compiler written by Tim Budd. Who and where is Tim Budd? > A key part of his APL compiler is a tool that translates > a moderately restricted subset of APL ... How restricted? > to C for compilation. > Of course Budd goes much further, since he also provides the > hooks that allow the compiled code to be integrated with the > other interpreted code in the workspace. Does this mean the C version cannot be run except under the control of an APL interpreter? > The company STSC provides a compilation service on their mainframe > product. [ ... ] This is not translation to another language (or is it?). > Finally, there is an APL to Ada translator developed by a major > supplier of software to the US government. The creation of this > tool was stimulated by the ease of software development in APL > and the requirement of the buyer that their software written in Ada. Specifics, please? > -- > L. J. Dickey, Faculty of Mathematics, University of Waterloo. > ljdickey@water.UWaterloo.ca ljdickey@water.BITNET > ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey Prof. Dickey: You left some technical issues unanswered... Isn't it the case that all these APL translators must include an interpretive runtime module? Thus, translating to another language is not complete unless one also has the runtime. -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh Unisys UNIX Portation Center "Unless you are very rich and very eccentric, P.O. Box 500, M.S. B121 you will not enjoy the luxury of a computer Blue Bell, PA 19424 in your own home", Edward Yourdon, 1975.
sippy@f.gp.cs.cmu.edu (Jay Sipelstein) (12/06/89)
In article <629@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: >In article <2811@water.waterloo.edu>, ljdickey@water.waterloo.edu (L.J.Dickey) writes: >> >> In article <628@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: >> >> > No, I have not seen any programming language translation products that can >> > handle APL. The difficulty is probably the parallel operations on generic >> > arrays of dynamically differing size and dimension. It could be done in >> > C++, Ada, LISP, or other languages, but I have not seen it done. >> >> I am not sure what the original question was, Hutchinson did not say, >> but translation tools from APL to other languages do exist. > >> One example is the APL compiler written by Tim Budd. > > Who and where is Tim Budd? He's at Oregon State, and has a book, An APL Compiler, which I believe is a modified version of his disseration. >> The company STSC provides a compilation service on their mainframe >> product. [ ... ] >> Finally, there is an APL to Ada translator developed by a major >> supplier of software to the US government. The creation of this >> tool was stimulated by the ease of software development in APL >> and the requirement of the buyer that their software written in Ada. There is also The Yorktown APL Translator (YAP) done by a group at IBM. Details can be found in Compiling APL: The Yorktown APL Translator, Graham C. Driscoll and Donald L. Orth, IBM J. Res Develop. Vol 30, No 6, 1986. This is a translator from APL to FORTRAN. Given a set of APL functions, they translate at the function level: if it is decided that a particular function, and all functions it calls can be translated, this is done. There are a set of criteria used to decide if a function is translatable (bad functions use things like Execute with unknown values, Quad Input, dynamic function creation, gotos to nonlabels and other difficult to compile constructs. Also deemed bad are computations using variables whose rank cannot be inferred at compile time (they seem to do some pretty clever stuff in order to determine rank). They also allow the programmer to insert comments of a certain form into the code to specify further information not deducible from the program itself. These comments are used by the translator to generate better code. Jay Sipelstein sippy@cs.cmu.edu
budd@mist.cs.orst.edu (Tim Budd) (12/07/89)
In article <629@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: >In article <2811@water.waterloo.edu>, ljdickey@water.waterloo.edu (L.J.Dickey) writes: >> One example is the APL compiler written by Tim Budd. > > Who and where is Tim Budd? I'm tim budd. I'm currently at oregon state university, e-mail budd@cs.orst.edu. > >> A key part of his APL compiler is a tool that translates >> a moderately restricted subset of APL ... > > How restricted? The APL compiler is described in a book called ``An APL Compiler'', published by Springer-Verlag. See the appendix for details. > > Does this mean the C version cannot be run except under the control of >an APL interpreter? > No. The compiler is a traditional batch style compiler, which produces a C program which is then compiled. > > Isn't it the case that all these APL translators must include an >interpretive runtime module? Thus, translating to another language is not >complete unless one also has the runtime. > Not if you toss out the execute function. My code is available via anonymous ftp from cs.orst.edu, directory pub/budd/apl. Warning - it is research software, guaranteed to be buggy with no support. Use at your own risk. --tim budd