What about a port to Windows CE (i.e., for Pocket PC's). Or even better yet, hugs for Pocket PC! -Matt On Sunday 09 March 2003 11:27 pm, Tony Sloane wrote:

John Meacham wrote:

...

This may be an intractable goal, but is any project out there

anywhere

...

close to a working haskell 98(ish) implementation for the Palm

Pilot?

...

There would probably have to be some compromises, like 16 bit Ints

and

...

perhaps some other restrictions, but i don't think its impossible to

get

...

some sort of lazy implementation to work on such a resource starved architecture so has anyone given it a shot?

Here at Macquarie University we have done some work on this. Matthew Tarnawsky ported the nhc98 runtime to the Palm as part of his 2002 honours project working with myself and Dom Verity. With this port it's possible to compile programs on a desktop machine and load the bytecode onto a Palm for execution. There is a limited interface to the Palm GUI libraries.

Having said that, there is much to be done. The current implementation has only been lightly tested and there are a number of design decisions that we want to revisit, particularly relating to how garbage collection works. We are starting to port the work to a recent version of nhc98 and are looking at some of these questions.

We hope to have something for others to play with in a few months. Stay tuned to this list for an announcement.

Cheers, Tony Sloane

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

Wait a minute! As far as I have understood, "threaded" refers (in this context) to a style of writing (byte code) interpreters. A threaded interpreter does not have a dispatch loop which reads the next byte code and then invokes the correct handler (typically by using the byte code as an index into a table of handler addresses). Instead, the dispatch code (fetch byte code, select handler) is integrated into each handler, eliminating the return branch from the handler to the dispatch loop and allowing the overlap of the dispatch code with the handler code for much improved instruction scheduling. Just my 2 öre. /kff

Wang Meng writes: | Hi All, | | Any one of your have the experience of defining a state of a state monad | as a polymorphic type? | I want to have: | | > type State = Term a => [a] | > data M a = M (State -> IO(State,a)) | | GHC yields a error message "Illegal polymorphic type". | How to resolve this? If you only want to vary the state type between separate monadic computations, all you need to do is parameterise your datatype over the state type:

data M s a = M (s -> IO (s, a))

This is available in some libraries, such as http://www.haskell.org/ghc/docs/latest/html/base/Control.Monad.State.html You could use it like this:

import Control.Monad.State type M s = StateT s IO

If, on the other hand, you want to vary the state type *during* a single monadic computation, it gets messy. You could try one of the following. - Declare a datatype with a branch for each instance of Term, and use this as the state type. > data State = TermType1 TermType1 > | TermType2 TermType2 > | ... > | TermTypeN TermTypeN - Do something similar with an existential type. > data State = forall a . Term a => State a - Don't use monadic state at all, but instead pass the state around explicitly. Regards, Tom

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. [...] Furthermore, the i/o model must be developed to accomodate the event-driven style typical for both embedded and interactive systems.

What would be extermely nice for embedded systems work is a functional language with very lightweight threading (as in concurrency, not as in threaded code) and easy inter-thread communication. One could then assign e.g. a thread per an I/O pin in a microcontroller and write programs in a style that matches the problem domain. I have toyed around with a design for a sort of pico-Erlang to accomplish this, but it is just vaporware at the moment. I have looked at some work on embedded functional programming, but it seems to be concentrated on resource constrained decices but still rather high-end systems, rather than the extremely resource impoverished 8-bit controller world I am interested in. -- pertti