[erlang-questions] Reassigning variables

[Richard O'Keefe]

On 18 Mar 2009, at 3:52 pm, Matthew Dempsky wrote:

> On Tue, Mar 17, 2009 at 7:38 PM, Richard O'Keefe <ok@REDACTED>  
> wrote:
>> _Easier_ to analyse?  I'd love to see an example.
>
> Sorry, by analyze, I meant review for correctness, and I was referring
> specifically to the diff.  It's easier to review
>
> + r(X) = foo(X),
>
> than
>
> - X2 = bar(X1),
> - X3 = baz(X2),
> - xyzzy(X3).
> + X2 = foo(X1),
> + X3 = bar(X2),
> + X4 = baz(X3),
> + xyzzy(X4).

Fair enough.  The ?let macro would have precisely the same
advantage, with no parse transform required.
>
>
>> This is a very familiar pattern from Smalltalk.
>> But surely you don't need a 'return' for that.
>
> Of course I don't *need* it, it works currently without that.  But I
> also don't *need* comments or variable and function names with vowels,
> but I find them handy in making the code more understandable
> sometimes.

I meant "but surely you do not need 'return' to do that READABLY."
Yes you DO need function names with vowels and you DO need comments
in order to write non-trivial working programs, let alone readable
ones.  But you don't need multiple returns.

>
>
>> There's an EEP to allow "un-nested" cases.
>
> Hm.  It feels immediately ugly, but so did Erlang's syntax in general
> when I first used it.  (I'm not a fan of putting the semicolons on the
> start of lines though.)

If you care about readability, you should be.  I find non-trivial
case expressions in Erlang almost totally unreadable with the
semicolons on the right.  In C/C++/Java/C#, you have 'case' at the
beginning of a line to tell you when a new case begins.  In Ada,
you have 'when'.  In PL/I, you have 'WHEN'.  The same kind of thing
applies in Fortran.  Something on the left to tell you a new choice
is beginning is enormously helpful.  Erlang-with-semicolons-on-the-
right completely lacks that visual cue.

I developed this style in Prolog after reading Peter van Roy's
thesis where he raged against Prolog for using both ',' and ';'
which were very hard to tell apart at the end of a line.  The
obvious answer was "don't put them both at the ends of lines
then".  Even with better fonts, it is very very helpful.  I grant
you that it isn't *familiar*, and I even grant that a keyword
would be a better cue than a semicolon.  But it's a big step
forward in readability while sticking within the language we have.

As for un-nested cases, it's so very close to being the kind
of if-then-elif-then-elif-then-else-fi that people have been
asking for in Erlang for a long time, that it's really very
amusing to have it called "immediately ugly".  I guess that's
a vote for the language we have.

>
>
>> Absent that, I'd probably do
>>
>>        case { requested_ad_size(...)
>>             , ad_status(...)
>>             , game_filtering(...)
>>             }
>>          of {bad,_,_}      -> {skip, bad_size}
>>           ; {_,disabled,_} -> [skip, disabled}
>>           ; {_,_,filtered} -> {skip, domain_filtered}
>>           ; _ ->
>>             choose_ad()
>>        end
>>
>> Admittedly, this evaluates all the criteria, but then,
>> in what we are expecting to be the usual case, we're
>> going to do that _anyway_.
>
> Sure, but in other use cases, the second or third checks being valid
> depend on the first or second checks passing.

First, there is no reason to expect one code style to cover all
possible cases.  I was aware of that issue when I wrote this
example.  Second, it's actually not hard at all to work around
that.  But third,

	"Bombinating in a vacuum" is bootless.
	We need REAL code to discuss.

For example, in cases where the second and/or third checks might
depend on the first, it might be possible to fuse the checks so
that this does not apply.

> There are other reasons I don't like the case expressions.

Reasons are what debate thrives on.
>