Tue Jun 4 18:01:40 CEST 2002
>I disagree, though the concurrency is invaluable.
> The original point of functional programming, at least as I've always seen
> it, was that computation was done in a referentially transparent way (see
> Backus's FP articles, for example). In the last decade or more, this has
> changed into functional programming being entirely about:
> 1. Higher order functions.
> 2. Type systems.
Good point. The interesting thing about Erlang in this respect is that
concurrency encapsulates side effects.
Ets-tables, ports and all that can all be viewed as _other_ processes
while your own process is entirely pure (if you forget about timeouts).
(The process dictionary, etc. can be viewed as passing an implicit state,
the DCG transformation discussed before.)
This is, it seems to me, much nicer than our siblings ML or Lisp, where you
side-effects to data. (Though ML at least marks the places where this can
clearly.) Haskell's approach (encapsulating side-effects in monads) appears
to Erlang's, though I haven't studied it closely enough to say.
It is much nicer, because you can rely on all data being referentially
transparent inside a process. In short: the "opaqueness" of your code is
limited to process communication, or if we also consider monitors and links,
More information about the erlang-questions