principle of least surprise
Tue Nov 22 11:34:00 CET 2005
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
>Haskell has 'monads', where all the scary stuff happens. Perhaps
>Erlang should introduce 'anti-monads' where scary stuff _can't_
"Monads" is not only choice to provide reference transparency. There is
another approach in CLEAN language.
"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."
>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
I'm sorry, what is 'WFTs'?
More information about the erlang-questions