I don't know what the current state of the deliberations of the POP9x group
are, but I would like to make a suggestion about where (if anywhere) POP
should go from here.
I am proposing to make my own work target the Java Virtual Machine, because
I think it is going to be a highly portable and efficient target
architecture. I've talked to the some of the system types here and they,
with some caveats, agree - there are problems of supporting global
optimisation of the kind that modern compilers do, but standard local
optimisation should work ok.
Frankly, I think that we've lost the battle of tagged architectures, even
such slightly tagged architectures as the Poplog VM.
So, the JVM offers an approach in which there is a small number of "simple"
items in the original POP-2 sense (int, long, float, double). Any item that
is treated as an object (a compound item in the POP sense) is boxed.
Contrary to first impressions, the JVM can support higher order functions
(though of course Java itself does not per se). The essential trick is to
have a Procedure class that has apply methods. This is not unlike the
class_apply capability of POP-11. So the POP-11 expression hd(x) could be
equivalent to the Java:
hd.ap1(x)
where hd is a Procedure object and ap1 is an apply method, while the POP-11
expression x::y is equivalent to:
cons.ap2(x,y)
This cannot be made to work for POP-11 as is because of the open-stack, but
I think we could keep most of the language features, and actually get a
better language, by making some restrictions. Primarily it must be manifest
to the compiler who does what and with whom, that is the compiler must know
that f(x,y,z) means that f has exactly three arguments. We could preserve
the "open stack" aspects of POP, but they would have to be clearly flagged.
Thus the Java equivalent of:
[% x, y+2 %]
would be something like:
Stack.pushstackmark(); Stack.push(x); Stack.push(plus.ap2(x,y))
Stack.sysconslist();
There is of course no need to have a Java intermediate form - I just give
it as being more digestible than the JVM instructions.
This way one could make POP applets that would autolink their required
library support, which could be shared with other languages (e.g. I'd do my
Scheme in this new regime).
Currently, I'm working on implementing the JVM and Java in POPLOG, which
should give a platform that people in this group could work within.
Matching the Java spec in POPLOG can't be done both efficiently and
accurately (for Java specifies floating point precision very tightly). But
a workable (and quite fast) JVM could be achieved.
If, on the way, one is able to introduce simple type constraints into
POP-11, and exploit constant functions, one might get quite good code out
of POP. For example, having done:
sysunprotect("hd");
lconstant hd = front;
it is save to translate the POP-11 hd(x) as the field-access operation
x.front
in Java (front being a field of an object of the Pair class).
Robin.
|