[clean-list] Clean in the Real World

[Marco Kesseler]

>On 17-Dec-2003, Marco Kesseler <m.wittebrood@mailbox.kun.nl> wrote:
>> In terms of the official semantics, this may be referential 
>> transparant. In terms of what the programmer sees and experiences, it 
>> is not. THAT is something that I do not like at all.
>
>Well, the point is that all operations which might deliver different
>results each time are specially marked, e.g. by putting them in the
>IO Monad.  Programmers know that operations in the IO Monad might
>deliver different results each time.
>
>This is the reality of programming in "pure" languages: they don't
>actually prevent the use of all the impure constructs of imperative
>languages, indeed they allow such constructs, complete with most of
>the drawbacks for reasoning about programs that such constructs imply.
>What these languages do is to just explicitly flag such constructs as
>being impure, by putting them in the IO Monad (or equivalent), so that
>programmers can safely apply equational reasoning to the parts of the
>program which do not use them.

This reality of Haskell may not be entirely the same in Clean.

But I don't really want to end up in a discussion about the relative 
merits of Monads versus explicitly passing a unique world. What I do 
not like, is NOT that one CAN model inherently imperative stuff IN a 
functional language. It is rather that I question whether one SHOULD.

Would it be THAT BAD if I/O gets programmed in an imperative 
language, which subsequently calls pure functional code for doing the 
processing? In a straightforward way, I mean. It would certainly 
separate the impure constructs from the pure ones.

To be completely honest, I find it slightly disappointing if a 
solution encompasses Monads or similar. Disturbing too. It this the 
future of functional programming?

Marco