Right-to-left (was: Re: entry at other than main)

[Dolf Grunbauer]

In article <9828 at alice.UUCP> ark at alice.UUCP (Andrew Koenig) writes:
>In article <230 at ssp1.idca.tds.philips.nl>, dolf at idca.tds.PHILIPS.nl (Dolf Grunbauer) writes:
>> Another interresting thing of APL is that it is impossible to write a
>> compiler for APL, and that is why there are only interpreters for APL.
>Not true.  There are compilers for APL.  Hewlett-Packard had
>a very impressive one a dozen or so years ago.
>				--Andrew Koenig
>				  ark at europa.att.com

I think it is possible to have some sort of a precompiler for APL, which
does syntax and semantic checks for most functions basically to speed up
the actual interpretation. I expect APL works like this. But, as it is possible
in APL to build text strings and execute them as APL code, you will need to
compile (or interpret) this string at runtime. The same thing applies to
input, as input for APL can be the result of an APL statement, including 
using the global variables. In this case the input has to be compiled and
executed (like in: "RHO n" to get an array).
This means that during runtime of an APL program, you will still need the
compiler/interpreter of APL. This is different from languages like C, where
you can (for example :-) throw your compiler away and your compiled program
still works. When you do this with your APL compiler, probably most of
the APL programs will work, but not all. 
This is why I think (an to be true: was told) it is not possible to have
an APL compiler, in the sence of a C or FORTRAN compiler.
I think Henry Spencer meant this problem when he wrote:

> There are some quite impressive APL compilers, actually.  As with many
> such languages, the interpreter has to be around in the general case,
> but most real programs can be compiled quite satisfactorily.  A really
> aggressive compiler can even produce something quite efficient.
-- 
Dolf Grunbauer          Tel: +31 55 432764  Internet dolf at idca.tds.philips.nl
Philips Telecommunication and Data Systems  UUCP ....!mcvax!philapd!dolf
Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands