palm?

[Jerzy Karczmarczuk]

Bjorn Lisper wrote:

> There is an interesting research question in here: how to design "lean"
> implementations of lazy functional languages so they can run on small
> handheld and embedded systems with restricted resources. In particular the
> restricted memory available poses an interesting challenge. What I would
> like to see is an implementation that is designed to be easy to port among
> different handheld/embedded systems, since there are quite a few of them (in
> particular there are many embedded processors). Probably a bytecode
> implementation is good since byte code is compact.  Nhc might provide a good
> starting point since it uses bytecode and was designed to be resource lean
> in the first place. I think the people at York even did some experiments
> putting it on some embedded system some years ago.

Just a side remark.
I wonder whether the byte-code approach is the best possible solution
taking into account the overload of the decoder. Why not threaded code?
The FORTH (and similar) experience, PostScript implementations, etc.
show that this paradigm may be more interesting. Anyway, when you read
for the first time the Talmud, ehmmm....., I mean the description of
the STG machine by Simon PJ and others, you see that some of their
ideas are not very far from code threading.

The classical FORTH style, with the separation between tha data and
return stacks seems quite appropriate for easy implementations of
higher-order control structures. If you saw the bells and whistles
inside a FORTH processor implemented on 8bit machines, you would
agree with me.

But I do not exclude the possibility that all this has been already
discussed and rejected for some serious reasons...


Jerzy Karczmarczuk