Lambda the Ultimate

Nice. Experimental, true. But still nice.

If I can just pierce through the veil that stands between me and Haskell (everytime I think I "get it", I either pick up and read an app that leaves me completely puzzled or just stare at a blank Emacs buffer waiting in vain for code to pour from my fingers).

Postmaster looks interesting for what it intends to be: a very configurable MTA.

"everytime I think I "get it", I either pick up and read an app that leaves me completely puzzled or just stare at a blank Emacs buffer waiting in vain for code to pour from my fingers"

I know exactly what you mean. Many times when I look at Haskell code, I begin to wonder if it's possible to design a language that is *too* concise/expressive/terse. Then I think of awk/sed, and the answer is clear. ;>

A certain amount of redundancy can be a *good* thing.

If an MTA counts as "system programming", a web server also counts:
http://www.haskell.org/~simonmar/papers/web-server.ps.gz

The Yale Haskell group uses purely functional languages for things like robots and animations...
http://www.haskell.org/frp/

I've heard of Ensemble and have recently bookmarked it for a deeper look. From what I can see, OCaml has become what Standard ML (along with the Basis Library) alluded to be: a general purpose programming language (suited for application and system programming as well as experimental stuff) with interests outside of academia.

I haven't played with OCaml in a couple of years. I believe the biggest feature missing (for me) was a preemptive concurrency model that didn't use OS threads (ala Concurrent ML). I think that is what has held me back from diving deep into OCaml.

Yes, beyond having an affinity for the Basis Library, I also have an affinity for Concurrent ML (or Erlang's concurrency approach for that matter).

This is a unique book. I read it a year ago and it influenced me enough to pursue using Standard ML in a system programming context.

But, like almost all of the ML literature I've stumbled across, in the past year, its a couple of years old and doesn't seem to have made any movement. That is, its been hard for me to find any current ML stuff.

...work on SML has been in the context of compilers middle and back ends. There's been a LOT of work on typed compilation, and this is stuff that's mostly not visible to the programmer.

Four modifications are introduced to a test-bed purely-functional language [ed: I believe the language in question was Gofer] in order to facilitate embedded-systems programming: I/O register access; communicating processes; interrupts; and a real-time incremental garbage collector. Referential transparency is preserved. The conventional model of communicating processes is augmented by the use of type classes and constructor classes to add type security around message-passing.

Two case studies of embedded applications are programmed: a marble-sorter and a liftshaft. Both give encouraging results for the adequacy of the approach. Two important areas are identified for future research. (1) It is not clear to what extent lazy evaluation is a help or a hindrance in programming embedded systems. (2) Real-time expression and guarantees of schedulability would extend the attractiveness of functional languages still further.

(1) It is not clear to what extent lazy evaluation is a help or a hindrance in programming embedded systems. (2) Real-time expression and guarantees of schedulability would extend the attractiveness of functional languages still further.

Both issues were raised in scope of Timber as well.

(1) It is not clear to what extent lazy evaluation is a help or a hindrance in programming embedded systems.

Anyone has any pointers to research trying to answer this question?

I suspect the answer is that it's both and that it would be good for a language to support both lazy and strict evaluation. Certainly I can think of enough applications where things like streams are useful, and enough situations where lazy evaluation could cause space issues.

It may be of some interest as it defines a FPL with both data and codata and they're able to prove some space properties about it. A later paper merges it with region types.