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

[zxq9]

On Friday 02 October 2015 15:24:04 you wrote:
> 
> On 2/10/2015, at 1:38 am, zxq9 <zxq9@REDACTED> wrote:
> 
> > On 2015年10月1日 木曜日 22:35:09 you wrote:
> Pascal
> 
> (a) Used the wrong operators for sets.
>     Union and intersection behave like OR and AND.
>     The Booleans *do* form a ring (isomorphic to Z/2) but the
>     operation that is analogous to addition is EXCLUSIVE OR,
>     not inclusive or.

I did not realize this.

...snip...

(I *thoroughly* enjoyed the response there. Thank you! I imagine if I keep going with that line I'll annoy people who don't really care much about language design and its bizarre history, but that was really interesting! The Algol/Pascal comparison leads me, once again, to ponder why Algol never took off yet Go is buzzed as though it is some revolutionary thing. Meh. I think I would have enjoyed a chance to actually go to school.)
 
> >>> 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.
> > 
> > True. Though we do have plenty of opportunities to effectively violate this whenever we want --
> 
> I'm not sure I understand you.  Enlighten me.
> 
> - The file system is a global shared mutable variable.
> - The pid registry is a global shared mutable variable.
> - DETS and ETS are mutable data structures.
> - Other data bases ditto.
> - "The" process dictionary is a process-scope mutable variable
>   which could in principle be eliminated by threading a state
>   through all calls.

I'm sorry, I wasn't clear with how/where I wrote that. I meant "True: that funs and list comprehensions do not include mutating variables" but that we could write a fun or list comprehension that accesses or mutates some global state in its body, leaving us with mysterious side-effects. We could enclose a file descriptor or a port, or a db connection, for example, and get up to all sorts of madness while other processes are accessing the same things concurrently. It is very nice that I never encounter cases of this in the wild.

That's just another example of where you can't protect people from themselves, though. Your example of provably meaningless function definitions like `f(X) -> X, -1.` comes to mind. As you noted earlier, patronizing the programmer is not the solution.

Come to think of it "global" means different things in Erlang depending on the nature of the thing being discussed. "Global" within: the cluster, the node, the network, the filesystem, the process. I suppose that's just part of distributed computing, though, whenever you can create labels relative to different levels of the cluster.

-Craig