[Haskell-cafe] Re: [Haskell] Top Level <-

Derek Elkins derek.a.elkins at gmail.com
Tue Aug 26 14:10:34 EDT 2008

On Tue, 2008-08-26 at 18:34 +0100, Adrian Hey wrote:
> I have a feeling this is going to be a very long thread so I'm trying
> to go to Haskell cafe again (without mucking it up again).
> Derek Elkins wrote:
> > Haskell should be moving -toward- a capability-like model, not away from
> > it.
> Could you show how to implement Data.Random or Data.Unique using such a
> model, or any (preferably all) of the use cases identified can be
> implemented? Like what about implementing the socket API starting with
> nothing but primitives to peek/poke ethernet mac and dma controller
> registers?

Data.Random and Data.Unique are trivial.  Already the immutable
interfaces are fine.  You could easily pass around a mutable object
holding the state if you didn't want to be curtailed into a State monad.

If you have full access to the DMA controller your language is not even
memory safe.  This is not a common situation for most developers.  I
have no trouble requiring people who want to hack OSes having to use
implementation-specific extensions as they have to do today in any other
language.  However, this is only a problem for capabilities (as the
capability model requires memory safety,) not for a language lacking
top-level mutable state.  Access to the DMA controller and the Ethernet
interface can still be passed in, it doesn't need to be a top-level

There are entire operating systems built around capability models, so it
is certainly possible to do these things.

> Why should Haskell should be moving -toward- a capability-like model and
> why does top level <- declarations take us away from it?

Answering the second question first: mutable global variables are
usually -explicitly- disallowed from a capability model.

To answer your first question: safety, security, analyzability,
encapsulation, locality are all things that Haskell strives for.
Personally, I think that every language should be moving in this
direction as much as possible, but the Haskell culture, in particular,
emphasizes these things.

It's notable that O'Haskell and Timber themselves moved toward a
capability model.

More information about the Haskell-Cafe mailing list