[erlang-questions] Reassigning variables

[Matthew Dempsky]

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).

> 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.

> There's an EEP to allow "un-nested" cases.  This will allow
>
>        case requested_ad_size(...)
>          of bad      -> {skip, bad_size}
>        ; or case ad_status(...)
>          of disabled -> {skip, disabled}
>        ; or case game_filtering(...)
>          of filtered -> {skip, domain_filtered}
>           ; _ ->
>             choose_ad()
>        end
>
> Last I heard there was a good chance this would be adopted
> but with a different syntax (just dropping the 'or', I think,
> but don't quote me).

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.)

> 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.

> Yes, it is.  The 'case' expression above is not, however.

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