[erlang-questions] variable exported from case in OTP 18
Thu Oct 1 11:35:09 CEST 2015
> On Thursday 01 October 2015 19:28:23 zxq9 <> 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]
There is much to like about Python, but it has its share of
stupidities. This is one of them.
>>> [x for x in ]
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.
> more weird:
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.
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
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?
More information about the erlang-questions