Lambda the Ultimate

Occam is, as I think you're already aware, not really an "FP" language. Its sequential subset is pretty solidly imperative (more like Hoare's original 1978 CSP than the later version published in his textbook). The original occam doesn't support garbage collection either - largely because it statically allocates everything. Since occam-pi supports dynamic process creation and mobility, I imagine that it probably supports some kind of garbage collection (although I couldn't tell you what it uses). But I'm not sure if the Transterpreter (which is what you'd want to use to run occam on small micros) supports the full occam-pi language yet.

Sorry, I should be less completely random and imprecise when I talk about these things. I guess if there were something Erlang-esque (I'd heard of Termite and thanks for the reminder (below), I'll go look again) which is functional-but-with-easy-mutation that might bring nice properties to the development process. On the other hand, if Occam tools can help prevent painting myself into a deadlock corner, that's pretty attractive in my mind.

Occam by itself won't prevent you from generating deadlocks (although there are some common process-interaction patterns used within the occam community that allow you to avoid deadlock - Jeremy Martin's PhD thesis documents several of them). However, since occam has much in common with CSP it's fairly easy to model the process interaction in your occam program using CSP, and then apply a tool like FDR2 or Jeremy Martin's Deadlock Checker to verify freedom from deadlock (FDR2 also lets you verify a lot of other properties as well).

Some day I would like to know or determine if the patterns in Occam, OTP, P3L, and any others are similar or surprisingly different. I wonder how much the difference is due to language differences, or if there are patterns in one and missing in another which could be successfully brought over.

I'm skeptical that implicitly parallel (or concurrent) programming is the way to go for embedded systems. There are two reasons for my skepticism:

1. Predictability - we have enough trouble getting predictable timing out of existing systems, particularly when you throw in nifty compiler optimizations, caches, etc. Implicit parallelization seems like yet another opportunity for the compiler to do things that make it even harder to predict timing (perhaps if the language had syntax or annotations that let us express timing constraints the compiler would be required to fulfill).
2. World/Machine mapping - the real-world is parallel, and explicitly expressing the concurrency needed to respond to real-world events tends to lead to a clearer system architecture. It's also (in my experience) conceptually easier to write the code. I think it's noteworthy that the "dramatic example" of producer-consumer implicit parallelism in the embedded.com article you link to looks suspiciously like a process- or actor-oriented description of the problem (i.e. it's pretty much explicitly parallel, and identifies the actors in what sounds like synchronous dataflow network).

Cool! Glad to hear there's some activity around these things. With respect to PLT/implementation, can you perhaps summarize the challenges of getting a high-level language to work on a resource constrained system? E.g. are there HLLs which seem to more easily map down perhaps? Presumably something which cons's inefficiently would not be good (unless you can get tricky with mem reuse, I guess). How can we have our cake and eat it etc.

Functional reactive programming (FRP, discussed here) is a high-level functional approach, which is nice, but not high performance, embedded, or parallel.

There was at least some experimentation with real-time and embedded FRP, e.g. this.

My own contribution, Regiment, which became WaveScript, is a high-level, ML-like stream-processing language that attempts to capture some of the benefits of FRP while having high-performance parallel and distributed execution. We use a multi-stage evaluation to reduce the source (FRP-like) program to a dataflow graph that can be scheduled in parallel.

I mentioned Regiment several years ago, but it did not seem to garner interest then.

The folks at PacSoft are mean :-) in that they do all sorts of interesting things (like, also, Timber) but those things don't seem to get too far beyond the academic boundary?

Sounds true. I'm not personally looking for hard real-time + GC + multicore, although if that existed and wasn't a bear to use that could be really keen. (I'm not sure what differences there might be between multi-core and multi-cpu, by the way; are they possibly different beasts sometimes?)

If, say, Erlang could fit, it would be fine with me to have 1 Erlang per core/CPU, with their own memory areas, and use message passing among those core-bound VMs. I think Erlang is claimed to be soft-real-time, whatever that means :-)

Similar thing could go for Scala+Actors+Remoting or OCaml+MPI (yuck on both?) or whatever, I guess. So maybe it comes down to: a small enough friendly language that has a decent library for message passing... but I don't expect anything like that would really fit on the smallest of devices like the Propeller. That thing is pretty darned small, it seems. Well, maybe somehow PICBIT Scheme or something could be applied? Or the previously mentioned Transterpreter.

So, the question and the answers are very "it depends" upon the actual hardware I available.

Thanks for the reference to Stopless, I'll read the paper.

As for Metronome, it's real time sure but I doubt very much that it scales for SMP loads given that IBM doesn't talk at all about SMP in their presentations..