Re: problems with the scoping in eu4
- Posted by jimcbrown (admin) Jan 07, 2011
- 1986 views
To summarise, clarify and re-emphasise points:
I am not particularly concerned about syntax. I am concerned about meaning.
1 Inability to reuse for-loop variables:
The issue here is that using i,j,k for loop indices is common practice. It's universal mathematical use just as a,b,c are constants and x,y,z are variables./
The problem in Euphoria is that when the variable has gone out of scope the name and it's type hasn't. That says to me broken scope.
And you see with for loops, this works correctly. The loop counter variable remains visible throughout the entire loop, and its value is persisted throughout until the loop ends. o
This is emphasised when we see that function parameters do shadowing correctly. The parameter can be of any type and it eclipses the outer declaration only while it is in scope.
Agreed. But while for loops (as the loop index variable) and procedures and functions (as function parameters) have the ability to declare variables concurrently with their own declaration, no other loop or conditional structure does. So this is not applicable to them, the normal rules apply there.
Also, the function parameters is a bit of a red herring. Their values are not persisted throughout multiple calls.
2 While loops:
This isn't about static variables. It is about continued re-declaration.
The issue of reusing variables should imply that it is illegal to create variables in a loop as the name will not be released after use.
This is incorrect.
while 1 do -- i not in scope yet -- i = 1 -- crashes puts(1, "ok") integer i -- i now declared i = 1 end while
To say that the variable doesn't persist from loop to loop (Matt) is wrong - the variable should not go out of scope until the loop is exited. Therefore either the variable creates a re-declaration error as in 1 or the the declaration line has to be skipped on subsequent loops.
What should happen is that the the declaration is treated as part of the initialisation of the loop.
The variable doesn't persist from loop to loop. That's what the implementation of Euphoria does. Matt is right. He should know, he designed it. Unless you mean that this is how it *should not* work, i.e. bad design.
This is the way it works. It was a deliberate design decision due to the lack of an explicit block..end block structure (akin to C's braces).
Initialisation to a constant should be possible if variables can be created in a loop.
This works. Why do you imply that it does not?
One *could* enclose the declaration in an if-test but that is very defensive and is an avoidance of the issue
Actually, you can't. If you do that, the declaration goes out of scope as soon as the if-test ends.
3. While with entry:
Many may have voted for while with entry as a cute idea based on a single loop which could have been coded as a loop .. exit on condition ... end loop structure. I don't think they were voting for its use with variable declaration, nesting etc.
A valid point here. entry was introduced long before the variable declaration change was made.
5 Blocks:
In order to limit the scope of variables it is necessary to be able to declare block scope. Currently that means: use a do once loop, or an if true then .. end if block or a procedure.
A block is conceptually very simple.
Example: in-line swap:
assuming two integers x, y
begin
integer t = x
x = y
y = t
end
If you like it is C's { .. } only {} means sequence.
If there were some expensive procedure to be done a block allows the space to be reclaimed immediately the block is complete.
Clearly blocks like this make more sense than declaring in loops or switches unless loop wide, switch wide scope was needed.
Having its own notation is cleaner than perverting loops or conditionals to this use.
I actually think that this is a good idea.
If we do implement blocks, then I'd also consider it a "best practices" to either declare your variables at the top, or in a block.
Conclusion:
But first scope needs to be fixed.
I'm not convinced that it's broken. Keep in mind, that this design came about and a consequence of a lack of an explicit block construct, requiring us to think about what is a logical place to start a new scope and what isn't.
