[erlang-questions] variable exported from case in OTP 18

[ok@REDACTED]

> On Thursday 01 October 2015 19:28:23 zxq9 <zxq9@REDACTED> wrote:

>> I'm reminded of programming languages like IMP and Ada where
>> you are not allowed to write
>>    p() and q() or r()
>> because as a programmer you are presumed to be too dumb to
>> work effectively with the concept of operator precedence as
>> applied to Boolean operators.
>
> Hey! I actually kind of like Ada. :-)

Me too.  But I do not like being patronised.
Personally, I blame Wirth whose broken Pascal precedence
rules corrupted generations of programmers, including ones
who've never heard of Pascal.

> There is a balance between providing flexibility and providing constructs
> that almost encourage programmers to silently drop little landmines in
> their code. My initial (wrong) assumption that case is supposed to be
> treated as its own semantic scope (which is why I had always thought the
> warnings were there, and previous discussions here tended to make me think
> I wasn't alone in expecting them to work that way)

Why do people *expect* something that's expicitly contradicted
in the manual and textbooks?

> It makes me feel sad, all the same. I like limited scope and knowing for
> sure that it is limited.

I like that too, which is why I often wish Erlang syntax
were more Haskell-like.  The answer, of course, is to keep
Erlang clauses short.  Erlang syntax was strongly influenced by
Strand-88 syntax, and that was based on Prolog syntax, and
that's where the single-scope model comes from.


> Not declarative ones, imperative languages that include this or that
> generator/comprehension feature and are familiar with the cool kids.
>
> Python, for example:
>
>>>> [x for x in [1,2,3]]
> [1, 2, 3]
>>>> x
> 3
>
There is much to like about Python, but it has its share of
stupidities.  This is one of them.

>>> [x for x in []]
[]
>>> x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined

Talk about landmines!

> There is (was?) a way to make something similar happen in Ruby as well,
> but that language is a big pile of curious decisions anyway. I can't seem
> to find the syntax for it now.
"A big pile of curious decisions" sounds as though we've seen
the same things in Ruby.  I once described it as making it easy
for people to swim in the sacred crocodile pond.

>
> In the Javascript recommendation for list comprehensions the situation is
> more weird:

JavaScript.  Weird.  No surprise there.  But what you are talking about
is a situation where something ISN'T really s scope; which would mean
that people used to these things should find it surprising the Erlang
list iterations ARE scopes, not that cases AREN'T.

> Comprehensions in these sort of languages are more like wacky syntax over
> for loops with a few opportunities (apparently) for optimization.

The big difference is that Python and Ruby and JavaScript all have
Fortran-style mutable variables, and Erlang does not.  The only way
a list comprehension in Erlang can possibly associate different
values with "a variable" is if that variable is (conceptually)
many *different* variables, one for each iteration, which means that
you can't ask for its value after the loop, because there is no "it"
to ask about.  (And the last time I looked at how Erlang compiled
list comprehensions, this was really true.  No variables were harmed
in the making of this comprehension.)

> especially considering that using unassigned list comprehensions
> as a shorthand for lists:foreach/2 specifically to get side-effects is now
> actually supported as a an optimization.

But those effects do NOT include mutating variables.  Each iteration
gets its own set of variables because that's the only way that the
variables *can* have different values in different iterations.

There are plenty of things that are technically legal in Erlang but
probably not a good idea.  For example,

    f(X) -> X,-1.

is legal.  But is it sensible?  When I made my Smalltalk compiler
report about 'statements with no effect' (which is perfectly legal),
it promptly told me about actual errors in my code I hadn't previously
noticed.

PS: the Erlang system I tried the example above in did not compile
at all.  I haven't installed R18 yet.  Does R18 catch this?