metzger@mozart.uucp (Robert Metzger) (12/15/89)
In article <49700018@uicsrd.csrd.uiuc.edu> jaxon@uicsrd.csrd.uiuc.edu writes: > >I have a question on a different subject: > >Would anyone support modifying a Fortran 77 vectorizer to produce APL or APL2 >(or even Dictionary APL) output? Reply to jaxon@uicsrd.uiuc.edu (or here). If others are interested, we could define the problem in this newsgroup, and then those of us with access to Fortran vectorizers will see what we can do about it. I would suggest that input be restricted to true Fortran 77 (maybe plus the MilStd extensions, which everyone seems to have implemented). A second restriction would be to simply transfer all I/O statements to the target program, encapsulated in comments, so that the programmer can convert them manually. This covers BACKSPACE, CLOSE, ENDFILE, FORMAT, INQUIRE, OPEN, PRINT, READ, REWIND, WRITE I don't know what to do with ENTRY statements and alternate RETURNs, I suggest that routines that use them be excluded. Same for PAUSE and STOP. There are lots of other problems. I'll post some more if anyone else responds. As for output, either APL Classic (pre nested/general/enclosed/accursed) arrays, or Dictionary APL.
amull@Morgan.COM (Andrew P. Mullhaupt) (12/17/89)
In article <3987@convex.UUCP>, metzger@mozart.uucp (Robert Metzger) writes: > In article <49700018@uicsrd.csrd.uiuc.edu> jaxon@uicsrd.csrd.uiuc.edu writes: > > > >I have a question on a different subject: > > > >Would anyone support modifying a Fortran 77 vectorizer to produce APL or APL2 > >(or even Dictionary APL) output? Reply to jaxon@uicsrd.uiuc.edu (or here). > > If others are interested, we could define the problem in this newsgroup, > and then those of us with access to Fortran vectorizers will see what we > can do about it. > > I would suggest that input be restricted to true Fortran 77 > (maybe plus the MilStd extensions, which everyone seems to have implemented). > 1. I am missing the point of this project. This is probably because I don't really see what is being proposed. As one who is often (and will continue to be) involved in APL/FORTRAN software development, I feel sure I would be interested in this project if I understood precisely what is desired. It seems to me that the proposal is a FORTRAN to APL translator based on recognition of vectorizable loops. This doesn't strike me as a really useful tool because the resulting APL code is likely to be an order of magnitude slower than the FORTRAN, and even slower than the hand-translated APL. In the ten or so important cases where I've needed FORTRAN code to be translated to APL it has proved most useful to recode the algorithm from the APL point of view. 2. FORTRAN 77 might not be the optimal choice of input target since array oprtations in FORTRAN 8x are closer to APL, and I would expect better opportunities for primitive recognition. In fact, ANSI C and ANSI Extended Pascal may be more important inputs as time goes on. It would be possible to include these languages by using various bits of the gnu C compiler. Again, I want to ask for clarification on this project, since I can't figure out what is really involved. Later, Andrew Mullhaupt