[erlang-questions] Ideas for a new Erlang

[Richard A. O'Keefe]

On 27 Jun 2008, at 11:49 pm, Sven-Olof Nystr|m wrote:
> I've met many people, who even after having quite a bit of experience
> with Erlang had trouble answering simple questions such as: if a
> receive matches many patterns, say
>
> receive
>    {foo, X} -> ... ;
>    {bar, Y} -> ...
> end
>
> and there are messages in the mailbox matching both patterns, which
> clause and which message is selected?


Hmm.  What does the Erlang reference manual say?

6.10 Receive
[1] Receives messages sent to the process using the send operator (!).
[2] The patterns are sequentially matched against the first message
     in time order in the mailbox, then the second, and so on.
[3] If a match succeeds and the optional guard sequence is true,
     the corresponding Body is evaluated.
[4] The matching message is consumed, that is removed from the mailbox,
     while any other messages in the mailbox remain unchanged.
Yup, it's sentence 2.  Now if there are 'many people' who can't be
bothered reading even the second sentence of the section that deals
with the construct, I fear there must be 'many people' who will be
helpless no matter WHAT constructs are offered or how they are
documented.
Perhaps the wording could be changed to

[2'] All of the patterns are matched against the first message (the
      one that has been waiting longest) in the mailbox.
[3'] If some pattern matches and the corresponding guard sequence
      succeeds,
[4'] the matching message is removed from the mailbox and the
      corresponding body is evaluated.
[2"] If the first message is not accepted, the second one will be
      tried, then the third, and so on.  If none of the messages in
      the mailbox is accepted, the process will wait for new
      messages, checking them one at a time in the order they arrive.
[4"] Messages in the mailbox that are not accepted are left in the
      mailbox without any change in their contents or order.
If there were no claim about 'many people' with 'quite a bit of
experience' not reading or not understanding the manual, I'd say to
leave the manual alone.  It seems clear enough to me.  But since
there is such a claim, maybe the revised wording above might help.
>> now Sven-Olof is obviously entitled to his opinion
>
> thanks :-)

That "obviously" is a staple of modern thought.  I am no longer as
persuaded as I was that it is true.  "The Ethics of Belief", by
William K. Clifford is uncomfortable reading, but salutory.
You'll find a copy at
http://www.infidels.org/library/historical/w_k_clifford/ethics_of_belief.html

Because Nystrom has met 'many people' who apparently have trouble
understanding the extremely strong similarity of behaviour between
'receive' and 'case', he HAS evidence for his belief that 'receive'
is hard to understand.

Because I struggled with Concurrent CML, but found Ada, Occam, and  
Erlang
intuitively obvious, I have evidence that 'receive' is not hard to
understand.

So we have a thesis, and an antithesis, and it's time to look for the
synthesis.  Clearly, whether 'receive' is easy or hard to understand
could depend on and presumably does depend on some factors such as
  - one's willingness to read the documentation
  - one's ability to read the documentation
  - one's experience with other notations such as CSP, Ada, Occam,
    TTCN-3 (where 'receive' can do some limited pattern matching,
    which when combined with 'alt' gives you a 'selective receive'
    that I will admit to be tricky), &c
  - whether one learned Erlang from a book or from a course,
  - in the latter case, whether the teacher understood 'receive'
    him/herself
  - and whether the teacher TAUGHT the students that 'receive' was
    difficult, the way many people teach that recursion is difficult,
    and many school maths teachers teach that "maths is too hard"
  - whether one has used profiling tools that report match attempts
    in receives, as well as match successes (_are_ there such tools?)

The only evidence I have to help me decide here is that the
information is not just there in the documentation, it's lying right
on the surface, very hard to miss.