Re: [Caml-list] environment idiom

[skaller <skaller@users.sourceforge.net>]

On Mon, 2004-12-13 at 20:29, Michael Walter wrote:

> What is "the detail level"? Like the "language level" in contrast to
> the level of the current abstraction (for instance, State monad)?

Yes, that's the idea.

> Different note: I think you are missing out an important property of
> the functional encoding, which is its purity wrt composability.

Oh no, I'm not missing that! I'm very happily missing
the ugly warts of C++ that *stop* me composing things
transparently! 

The fact that Ocaml (and Felix) still allow procedural
code means I'm not forced to use functional techniques,
but Ocaml at least doesn't prevent me .. and C++ certainly did.

> In constrast, in a language such as C++ you cannot assume that..
>   vector<unsigned> sieve(unsigned);
> has no side effects.

Indeed. I am not missing the advantages of transparency,
the point I'm making is that even in an FP, when you're
considering your code at a higher level than the ground
syntax .. you may still lose the functional nature and
its advantages.

To avoid that I want to know far more precisely how to
characterise things . I know what a function is, so the
problem is that I do NOT know exactly what 'code' is :)

> Also consider the "print" part of your algorithm, which I ignored so
> far. In C++ it would be very easy to add it to sieve() thus making the
> function virtually useless to use but in the special case where you
> want to print the number instantly.
> 
> In Haskell, you *could* have a sieve :: Integer -> IO [Integer], but
> what you would really do is to decouple the sieve and I/O 

And you'd do that in C++ too. Only it would be harder ..

> (and this is
> made kinda "attractive" by the expressiveness of the language and the
> type system). 

Yes. I'm not saying monads are bad or anything, I'm saying
that the dang things are so powerful there is danger of
just doing bad old procedural programming with them.

And conversely, people hyping FP like OO: I believe
a language has to support stateful and functional programming
in a balanced way. The fact this is NOT currently the case
is due to a deficiency of theory -- it isn't because FP
is intrinsically better (just that FP is better understood).


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net