[erlang-questions] How about a new warning? Was: Re: trouble with erlang or erlang is a ghetto

[Tim Watson]

On 4 August 2011 23:29, Richard O'Keefe <ok@REDACTED> wrote:
> The person in question was Tony Arcieri, who built Reia

Wasn't paying attention to the details. Although I haven't used Reia,
I am aware of it and it is indeed very a impressive thing to have
built.

>
> It is important to understand the distinction that Tony Arcieri
> correctly makes between
> (A) single assignment in the *semantics* (data are immutable), and
> (B) single assignment in the *syntax* (variables can be assigned
>    only once).

Thanks for clearing that up - I confess I didn't notice the
distinction but on second reading you're quite right.

> The point he makes is that you can have (A), which he seems to be
> happy with, without requiring (B), which he is not: you can treat
> re*assignment* as re*binding*.  Thus in
>
>        X = f(),
>        X = g(X),
>        X = h(X)
>

I must confess I find that very confusing. I have written plenty of
imperative code over the years but it just feels wrong to keep
reassigning like that even in Ruby. Given that Ruby is Object Oriented
as well as imperative, I'd expect to see something more like `f.g.h`
perhaps with parens in later versions where they seem to be required
once again. If the code is not doing anything with these intermediate
variables, why type them in the first place? After all, `h(f(f()))` is
actually more concise than the alternative, and rubyists do seem to
like conciseness (although I'm being a little flippant, as this
doesn't mean they all prefer inlining).

When I can make function/method parameters and/or local variables
immutable, readonly, `final`, or whatever syntax is available to me, I
do. I find this delegates checking for a common class of errors to the
compiler. In Erlang I might use `{ok, X} = f(), {still_ok, X} = g(X)`
as a deliberate check from time to time.