principle of least surprise

[Nick Linker]

Ulf Wiger (AL/EAB) wrote:

>The problem of that obviously is that normal erlang functions
>can contain side-effects, loops, and all sorts of scary stuff.
>  
>
Uh... this problem is typical for imperative languages, and I 
(unfortunately) encounter the same problem in Erlang. I wonder whether 
the problem with side effects is significant in real big projects in 
Erlang language?

>Haskell has 'monads', where all the scary stuff happens. Perhaps
>Erlang should introduce 'anti-monads' where scary stuff _can't_
>happen?
>  
>
"Monads" is not only choice to provide reference transparency. There is 
another approach in CLEAN language.

[quote]
"Although CLEAN is purely functional, operations with side-effects (I/O 
operations, for instance) are permitted. To achieve this without 
violating the semantics, the classical types are supplied with so called 
uniqueness attributes. If an argument of a function is indicated as 
unique, it is guaranteed that at run-time the corresponding actual 
object is local, i.e. there are no other references to it. Clearly, a 
destructive update of such a "unique object" can be performed safely."
[/quote]
[http://www.cs.ru.nl/~clean/CleanExtra/report20/chapter9/introduction.html]

>In "Wearing the hair shirt" 2003(*), Simon Peyton-Jones claimed
>that the only thing wrong with monads was the name: they should
>have called them "warm fuzzy things".
>  
>
Very interesting, thank you ;-)

>Erlang WFTs, in other words, would be the thing to allow in 
>guards.  (:
>
I'm sorry, what is 'WFTs'?

Best regards,
Linker Nick.