forget

[C.Reinke]

> > A more lightweight syntax for funs would make that a lot nicer, of
> > course, and "do" might not be the most suggestive name, but it
> > avoids names for intermediates as well as language extensions..
> >
> > Btw, why can't variables be passed unbound to functions (that
> > would make more complex utilities easy)?
> 
> I think you have invented monads AND dataflow variables  :-)

Hey, you can't blame me for everything, you know!-)

Btw, I explicitly avoided monads, because with Erlang's heavy-weight
syntax, they would look even less usable than the more primitive
compose-a-list-of-funs definition I suggested.

> This is *very* difficult to implement :-)

You wouldn't by any chance know whether that's why Erlang's
designers chose not to have it in the language?-) 

Instantiation of "logical" variables used to be the standard means
of communication between and-parallel threads in the various
non-sequential prologs (5th generation, etc.), and is still not
dead for logic-based concurrent calculi. But you know that
because you looked at many of those before and during the evolution 
of Erlang, and the mailbox/send/receive-model has proven to be
practical (so far, more practical than 5th gen ideas;). 

  [it shouldn't be difficult to define a naive variant of a
  distributed single-assignment construct on top of Erlang's
  mailboxes: a thread with mailbox receives assignments from 
  writers and answers with success (first write commits) or 
  failure (consecutive incompatible write attempts); 
  synchronization of writers (all fail or all succeed) would
  be more difficult; Erlang didn't inherit non-deterministic
  user-defined rules, so dealing with or-parallelism is not
  an issue - hmm, could that be modeled via supervisors?-]

I wasn't suggesting to go back to that (well, at least not for
Erlang), but banning unbound variables from function calls might
be overly restrictive (given the, now remote, relation to prologs).

Why not permit unbound variables in function calls, and only outlaw
them in inter-thread communications? I looked at logic vs functional
languages a while ago, and most of the examples where logic
languages won where down to this late, but still single-assignment
use of variables. And its a lot easier (almost trivial?) to
implement within thread-boundaries.

> Then we send the unbound variable to two *different* processes - imagine
> they are on different machines (just to make it more fun).
> 
> They now both try to bind X at the same time :-) - one should succeed
> the other should fail - and it should work in the presence of errors ...
> 
> << this is what Oz does (see http://www.mozart-oz.org/) >>

It's been a long time since I visited Oz;) but the general ideas
go back a lot farther (though I don't recall to what extend those
early parallel "logic" languages dealt with distribution, as in Oz).

Cheers,
Claus

PS. I notice two aspects of Erlang that tend to aggravate the 
    problem discussed in the original thread (beyond the problems
    most functional languages used to have with this):

    - non-nesting variable scope (fortunately not adopted for
      the higher-order extensions)

      so one cannot reuse the same variable name, as one usually
      can with non-recursive lets.

    - relatively heavy-weight syntax

      making the use of higher-order functions less convenient
      than in Haskell (MLs have the same problem). So instead
      of defining their own higher-order control constructs
      (which otherwise tends to be home ground for functional 
      languages), people are asking for language extensions 
      (the same happened with behaviours).