[erlang-questions] Why single-assignment with non-shared state?

[Matej Kosik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulf Wiger wrote:
> 2007/10/20, Matej Kosik <kosik@REDACTED>:
>> Doesn't shadowing of meanings of variables in Erlang similarly
>> complicate reasoning? (in one position some variable has some
>> meaning and elsewhere in the term suddenly has different meaning).
> 
> Well, it could, but in most cases where it would be confusing, the
> compiler will give you a warning.
> 
> Personally, I try to use some naming convention for variables to
> minimize the risk of confusion.
> 
> 
>> Non-functional features of Erlang are present in its fundamental constructs:
>> - - send
>> - - receive
>> - - spawn
>> These cannot be modelled in (purely) functional languages, can they? How?
> 
> Almost by definition, the answer is "no", I think?  (:

Thank you for the answers,

Hm. Today I have look at the Wikipedia article and it (at the begining) says:

"The sequential subset of Erlang is a functional language".

This is correct.

However, Joe's new book says:

"Erlang is a functional programming language and has nonmutable state."
(page 32, at the top)

Isn't this false? With `spawn', `send' and `receive' you can model mutable state---the state of
processes changes over time and this is very useful. The change of the state can be observed from
the outside. Isn't this contradictory to the reality?

I agree that fragments of code written in Erlang's functional subset can be subject to
proof-techniques (about program correctness) developed for functional programs but what about the
non-functional constructs? Have you developed some proof techniques to cover also these constructs?
Which? I am interested. (I do not mean crashes).

> 
> (I guess I should let the real language experts answer this, but it's Saturday,
> and I don't have anything better to do right now. I trust I'll get my fingers
> slapped if I write something stupid).
> 
> At least it's difficult. Haskell uses 'monads', to clearly mark where the code
> has side-effects. This allows the compiler to trust that all code outside of
> the monad is pure. Other languages can use the fact that these operations
> are contained within the runtime, and can optimize them. Felix* does this,
> for example; I don't know about Concurrent ML. I believe that when Felix
> participated in the Language Shootout, its compiler reduced the concurrency
> benchmark down to a function that did nothing**. This doesn't mean that
> Felix models "fibres" as being pure, but as long as the effect of the
> impurity is understood, a smart compiler can sometimes eliminate it,
> or at least simplify it significantly. I guess this is sort of a grey area. (:
> 
> It is partly connected to the fact that most of the surroundings are pure,
> and very well understood. Erlang can, for example, decide to pass a
> pointer rather than copy a message, since there are no user-level
> operations that can mess with the low-level representation of the
> message. There was once a paper suggesting that a gen_server:call()
> could be reduced to a function call, under certain circumstances
> (http://www.erlang.se/workshop/2002/Stenman.pdf), but it
> suggested dynamic checking to ensure that the conditions were met,
> since it would be difficult to do statically in Erlang.
> 
> (OHaskell not only performs this check statically, it enforces it:
> http://www.cs.chalmers.se/~nordland/ohaskell/)
> 
> Erlang's approach is fairly pragmatic. It has basically tried to make sure
> that all non-pure operations can be modeled using spawn, send and receive,
> but the only parts of an erlang program that the compiler can trust to be
> free from side-effects are clause heads, the left hand side of an expression
> (pattern matching), and guard expressions. Every (non-guard) function call
> can potentially result in a side-effect. Some BIFs are also known to be pure
> and can be optimized by the compiler.
> 
> * http://www.felix-lang.org - a OCaml/C++ hybrid of sorts
> ** This Felix entry was disqualified, which caused some debate. Google
> will tell you more.
> 
> BR,
> Ulf W
> 

Best regards
- --
Matej Košík
ICQ: 300133844
skype: matej_kosik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHGyAmL+CaXfJI/hgRAsxxAJ4hFB3JPFbfTu0NSRhyp/9kIY8OBgCfSxUd
UjmucR1QFVgotr5GLqtOhn8=
=GhZY
-----END PGP SIGNATURE-----