palm?

[Bjorn Lisper]

M. Parker:
>What about a port to Windows CE (i.e., for Pocket PC's). Or even better yet, 
>hugs for Pocket PC!
>
>-Matt

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.

Compilation of standalone programs is also interesting since especially
embedded programs often execute in fixed environments. Lots of room for
program specialization and subsequent code optimizations here.

But I think the programming model also must be developed. One will need to
give the programmer more control over resources when necessary. This
requires operational semantics with good cost models, notoriously difficult
with lazy languages. So one will have to continue the work to integrate
eager and stateful execution into the lazy model. Furthermore, the i/o model
must be developed to accomodate the event-driven style typical for both
embedded and interactive systems. I think the functional reactive stuff from
Yale (Fran/FRP) provides a really nice high-level notation but it is hard to
make guarantees about limited resource consumption in that model. There are
models with resource guarantees (E-FRP) but they seem to limited to be
really useful in practice. One would like to cover the spectrum in-between.

Now, if one would succeed in doing all this, then there would be support for
an embedded software development model where one could first write highly
declarative executable specifications, test them for logical bugs, and then
sucessively refine the code towards a resource-lean implementation using
more and more resource-aware primitives where necessary. I think this would
be a really interesting alternative to the current imperative practice (head
on with C or assembler) and the object-oriented trend with UML/java/C++.

Björn Lisper