Re: question on local vs nonlocal

[Lorenzo Donati <lorenzodonatibz@...>]

On 13/05/2020 16:22, Andrea wrote:
> >
[snip]

> Now forgive me for asking this, even if I am a programmer I am not a
> Computer Science Engineer. My question is: why are new scopes created by
> "if", "for" and other statements and not only by function definitions and
> do...end statements? If one wanted a new scope one could easily type "do"
> (as in other languages we just open a curly brace). So why this is done
> implicitly? What is the advantage or the theoretical reason? Again forgive
> me for this maybe silly question - remember my background is not in
> computer science.
From a practical POV, lexical scopes help reduce the amount of 
information a programmer must hold in their mind while comprehending a 
piece of code.
Human mind has different kinds of memories (short-term, long-term, 
visual, aural, etc.) that play a role in understanding a piece of code.
If the piece of code is short, then the task of understanding it is 
easier. But even if it is short, it could be a mess because it 
references lots of stuff defined "far away".
Lexical scopes help keeping the information textually localized. Thus it 
is quite intuitive to make structured statements other than do-end also 
be lexical scope, so that whatever is visually enclosed in some textual 
block is also self-contained from a scoping POV.
Adding an extra block to introduce a scope in, say, an if branch 
increases visual clutter: you must add a block AND you typically must 
indent it. This is bad for visual memory, and another level of 
indentation makes this worse. You could write the things to avoid an 
extra level of indentation, but then the things start to become ugly
In other words, making any block a scope, keep the things tidy.

Compare:


if condition then
 for x = 1,10 do
  local y = (..stuff...)
  -- do some other stuff; y is not needed outside the loop
 end
end

Without lexical scoping of if and for statement bodies, you would end up 
with the equivalent thing:
if condition then
  do
   for x = 1,10 do
     local y = (..stuff...)
     -- do some other stuff; y is not needed outside the loop
   end
  end
end

or, to avoid extra indents:

if condition then do
 for x = 1,10 do
   local y = (..stuff...)
   -- do some other stuff; y is not needed outside the loop
 end end
end

Ok, maybe manageable. But if we have another if inside the loop body?
Or the loop is a repeat-until, which has no do-end block? And if Lua 
authors decide to introduce another statement having a block structure?
Your brain would continually struggle to separate the concept of block 
to that of lexical scope.
Moreover the "end" keyword would sometimes end a scope (if paired with 
do) and sometimes not. You would have nightmares when debugging complex 
code when trying to sort out where a scope actually ends!
Try to understand where a scope end and where a block ends when you find 
something like:
  end end
end end

or

     end
    end
  end
end

at the end of a group of statement that could have ended simply like this:

  end
end

Add to that another issue: why would you want some blocks NOT to be also 
lexical scopes? The only immediate reason that comes to mind is 
"flexibility", but do you really need to be able to define a variable in 
an inner block that could be visible outside that block? Wouldn't it be 
clearer to define that variable outside the inner block to begin with? 
The block = scope equation makes leaking information to outer scopes 
less likely.
You may have heard about the "Principle of Least Surprise" in 
engineering (also in SW engineering, then). It can be stated in various 
ways, but in this case you could spell it as "things that look similar 
should behave similarly (unless you really cannot do otherwise)".
Any deviation from this principle puts a burden on the brain of the 
reader of the code.
More effort for the brain means more chances to do mistakes (that's why 
expert programmers advise younger ones "not to be too clever" when 
writing code. If you can code something in a boring, plain, easily 
readable way, in 10 lines that's much better than write an equivalent 
masterpiece of obfuscated code in 5 lines (unless you are doing it for 
fun, of course) using every corner case or obscure feature of the language.
That obfuscated, clever code WILL bite the maintainer of that code in 
the future, and that maintainer could be an older you!
Any programmer which has some years of programming under their belt will 
tell you of the experience of having to modify some old code made by 
themselves some years before and thinking "WTF?!? Did I really write 
this crap?!?" or "What the heck was this code intended to do?!?".


[snip]

>    Andrea
>
>
>
> _______________________________________________
> lua-l mailing list -- lua-l@lists.lua.org
> To unsubscribe send an email to lua-l-leave@lists.lua.org

Cheers!

-- Lorenzo
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org