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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
