[erlang-questions] style question - best way to test multiple non-guard conditions sequentially

[Richard A. O'Keefe]

On 21/06/2013, at 3:41 PM, Jonathan Leivent wrote:
>> Well, for one thing, it might be an idea to rip the branching structure
>> out of the receive.
> 
> Yeah, sure.  But, I'm forced to do that, instead of deciding to do it if and when it's a good way to modularize the code.

Someone has a blog where they looked at how to write Erlang code
so that it's _obviously_ right, and ripping things into smaller
pieces was part of it.  If you can't name it, you don't understand it.


>  In this particular case, I'd like to see the full conditional all at once, compactly, without obfuscating plumbing, preferably in the receive statement with the other protocol messages.

"compactly" and "in the receive statement" is a contradiction.

I've seen too many Erlang state loops with giant functions stretching
over multiple pages.  I'm not talking about *adding* obfuscation, I'm
talking about *removing* it.

>  I think it would just help me think clearly about this key top level of the protocol's decision tree.
> 
> Again, I haven't done a good job justifying the existence of unrestricted sequential conditional statements.  But, considering their ubiquity in virtually all other programming languages, do you really think Erlang's omission of such a construct is a "feature"?

But we *STILL* haven't seen any *ACTUAL* code to tell whether anyone
other than you would experience a problem with the code, or whether
there might be a completely different way to structure the code.

No, I don't think that it's a feature.  Arguably, Erlang would have been
better off without 'if' entirely.

Let's face it "everybody else does it" is not a good argument for anything.
"Virtually all other programming languages" have bounded size integers.
"Virtually all other programming languages" rely *massively* on assignment
statements.

You and I have now spent more time talking about this than it would take
to just write the wretched code and get on with our lives.

In a way I *do* want to say that a language that won't let you code
automatically like "virtually all other programming languages" is an
opportunity to try to think differently about what you're doing.
That doesn't mean the old way is _wrong_; maybe the language really is
deficient.  But an opportunity to think differently is to be taken.

I was about to say "Any time I find myself yearning for a Fortran feature,
I stop and think", but actually, Fortran 2008 has finally picked up the
'let' feature of (most) functional languages -- although in typical
Fortran fashion it's called ASSSOCIATE.

Without seeing the actual code, nobody else can tell whether 'compactness'
is really a virtue in this case, or whether it gets in the way of 'clarity'.

I do repeat that more than 40 years after meeting formal logic,
I love logic, but am extremely suspicious of Boolean expressions in
functional languages.  Most Boolean-valued functions that have been
discussed in this mailing list turned out to be things that would be
better conceived some other way (like a Haskell Maybe or Either or
something with more than two possibilities).

How can I tell whether this is the case in your problem without seeing
the code?  (Yes, I know, old Johnny One-Note harping on a single string.)
> 
> Anyway, I appreciate the help with finding an alternative coding scheme - but if it doesn't exhibit the compactness I was hoping for - that I can visualize in an Erlang-like pseudocode - then this isn't really helping here.

I have to leave in order to get to my father-in-law's birthday party.
This is what I have by way of patches to erl_parse.yrl so far.

37c37,40
< if_expr if_clause if_clauses case_expr cr_clause cr_clauses receive_expr
---
> if_expr   if_clause   if_clauses
> case_expr cr_clause   cr_clauses
> cond_expr cond_clause cond_clauses
> receive_expr
56c59
< 'after' 'begin' 'case' 'try' 'catch' 'end' 'fun' 'if' 'of' 'receive' 'when'
---
> 'after' 'begin' 'case' 'try' 'catch' 'end' 'fun' 'cond' 'if' 'of' 'receive' 'when'
277a281
> expr_max -> cond_expr : '$1'.
387a392,398
> cond_expr -> 'cond' cond_clauses 'end'       : mk_cond($2).
> 
> cond_clauses -> cond_clause                  : ['$1'].
> cond_clauses -> cond_clause ';' cond_clauses : ['$1' | '$3'].
> 
> cond_clause -> expr clause_body              : {clause,?line('$1'),'$1','$2'}.
> 
1103a1115,1124
> 
> mk_cond([{clause,Line,Expr,Body}]) ->
>     {'case',Line,Expr,[
>       {clause,Line,[{atom,Line,true}],[],Body}]}.
> mk_cond([{clause,Line,Expr,Body}|Rest]) ->
>     [{clause,Next,_,_}|_] = Rest,
>     {'case',Line,Expr,[
>       {clause,Line,[{atom,Line,true}],[],Body},
>       {clause,Next,[{atom,Line,false}],[],[mk_cond(Rest)]}]}.

erlc is happy with this, but it has had no other testing.