Re: APL Compilation (WAS: VM-friendly GC) (Carl Zmola)
Mon, 17 Feb 1992 23:29:18 GMT

          From comp.compilers

Related articles
VM-friendly GC (1992-02-08)
APL Compilation (WAS: VM-friendly GC) (1992-02-14)
Re: APL Compilation (WAS: VM-friendly GC) (1992-02-17)
Re: APL Compilation (WAS: VM-friendly GC) (1992-02-17)
Re: APL Compilation (WAS: VM-friendly GC) (1992-02-19)
Re: APL Compilation (WAS: VM-friendly GC) rbe@yrloc.ipsa.reuter.COM (1992-02-21)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Carl Zmola)
Keywords: storage, APL
Organization: University of Illinois at Chicago
References: 92-02-039 92-02-070
Date: Mon, 17 Feb 1992 23:29:18 GMT

In 92-02-067 the moderator (John Levine) writes:
>[It surprises me that IBM does more APL interpreters, no compilers.]

IBM does market a "Business Partner"'s APL Compiler. It compiles
to Fortran since that makes it much more machine independent.

I think the main reason there is no work on an APL compiler at IBM
is its ability to link with FORTRAN code easily. Thus only the code which
needs to be optimized is compiled.

If anyone out there thinks they can write a comercial quality APL
Compiler your welcome to try, but I'd much rather try to do something
productive. :-) It's just too hard to do. Compiled code will look very
much like an interpreter, with dynamic array's. Especially if you try to
implement IBM's APL2 dialect.


[HP did a compiled commercial APL nearly 15 years ago, it's not like it's
a big secret how to do it. You do need to be prepared to recompile when
shapes and types of data change, but in real code, they don't very often
and compilation can be a big win. Also, back when I was writing APL I
often had expressions that used outer products to create enormous
intermediate results that were squashed down by various sorts of reduction
functions. The interpreter choked on them, because they exceeded the
address space of the PDP-10 they were running on. Compiled code doesn't
need to materialize the intermediate arrays all at once and can handle
such expressions easily. I suppose IBM would explain that they've solved
this problem by increasing the size of the address space. -John]

Post a followup to this message

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