Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
environment idiom
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-12-13 (12:59)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] environment idiom
On Mon, 2004-12-13 at 20:56, Michael Walter wrote:

> > Another example is my Felix language. It has both functions
> > and procedures. Functions aren't allowed to have side effects,
> > yet they're not pure in the sense the result can depend
> > on variables which change between (but not during) invocations.
> > [This has an alarming effect on the optimiser ..]
> Can I read about the reasoning behind this on

No, I haven't really spent enough time on documenting
rationale yet. At least one excuse is that the system
is experiemental, and another is that, in fact, this
particular division of labour proves to have a major

A crude reason is: procedures don't use the machine stack,
which is a requirement for the microthreading to work.
Felix can run 1Meg threads on a small Linux box with
O(1) context switching.

OTOH, I decided functions should not be allowed to have
side-effects, for the usual reasons: referential transparency,
optimisation, etc. But they use the machine stack: two reasons
being performance and ability to integrate with C code.

The problem is that side-effect free is only equal to
pure in the total absence of any procedural code.
Otherwise you have two kinds of functions -- pure ones
that don't look at variables, and dirty ones that do.

Dirty functions are of course quite useful -- accessors
for objects for example, and freedom from side-effects
is still useful. But I have to separate the two kinds
or the optimiser can't work, and I can't define any sane

> > [...] Clearly you can reason about the
> > 'functional subsystem' using transparency, and then combine
> > the result with reasoning about the top level 'magic main'
> > where the program as a whole is not transparent ... and you still
> > have 'ease of reasoning' in the combination.
> Indeed (and Monads give you an attractive way to partly do this the
> other way around).

Yes Indeed!! Duality!

> Are there specific statements, for instance on the Haskell home page,
> which you dislike? 

I haven't looked :)

> Or do you dislike that fact that for instance in
> the statement "Monads allow for sideeffect free encoding of stateful
> computations" everyone is assuming that "encoding" refers to the
> encoding in the target language?

Yes, that's roughly the thing. The point being that this
really isn't enough. 

The problem isn't isolated to monads. That's only
syntactic sugar after all -- the issue relates to 
*all* functional programming, it's just clearer
to see with monads, particularly if you compare
monadic code with a more conventional interpreter
(eg a Haskell interpreter for Perl .. when you 
execute the Perl is it functional or procedural).

The thing is that high level language are 'just syntactic
sugar' for assembler .. the point being it just isn't
enough to talk about 'the program is functional', 
rather you need to say 'the encoding is functional
at the Haskell level and also at the first major
abstraction level but stateful at the third level'
or something like that .. and the question is,
how should I *really* say that?
> Okay, I was thinking (along the lines of the paragraph above) that you
> were unhappy about the way that people are talking about monads.

I am, because it confuses me! Their claims are clearly
both right and wrong! But I don't have the intellectual
apparatus to explain how this can be precisely.

Or even crudely :)

> Okay. So far I have never been confused by such statements about
> monads -- it was usually pretty clear what "pure" was referring to 

Yeah, but that's the problem: the implication is that
it is enough to just refer to the detail level.

But that isn't so, because a heavy user of the ST monad
might just as well stick with C. They may think they're
gaining something that they're not gaining.

But there is a converse! Not all stateful code
is hard to reason about. In fact by duality,
some ways of stateful programming -- yet to be understood --
are just as good as functional coding.

Which ones? I don't know but monads seem to offer clue!
Crudely, if your stateful program is turned into a Haskell
one using 'the least possible ST monadic code', your program
is probably sweet. You were probably emulating functional
code in procedural code :))

John Skaller,
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language