Gail Shaw wrote:
> I haven't looked too deeply, but it's on my list of languages to learn.

Speaking of functional, I think Andrew has mildly mischaracterised 
Erlang as a functional language. While I've seen a few informal 
references to needing to use a functional style to program Erlang, none 
of the actual documentation says it's functional, and I never even saw a 
mention of "referential transparency."

Indeed, I ran across this gem in the manual:

......
    S = self(),
    P = spawn(fun() -> do_something(S, 1, 2, 3) end).
...... (or some such)
along with the footnote that this isn't the same as
    P = spawn(fun() -> do_something(self(), 1, 2, 3) end).

self() is the function that returns your current process id.
Spawn is the function that creates a new process to run the indicated 
function.  fun() -> ... end is lambda.

If you write the latter, the first argument is the process running the 
function. If you write the former, the first argument is the parent 
process (so to speak) that spawned the function and is likely expecting 
some sort of message coming back when do_something() finishes.

Plus, there's a number of very explicitly statefull collections of data 
in the system, including a hashtable for each process and a collection 
of named hashtables for each OS-level process running an Erlang interpreter.

What they *do* say is that Erlang is a single-assignment language. Not 
because it's "functional", but because it's easier to debug that way. 
(Or so the research claims.)  Me, I think I need to write a while() 
function. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message