Re: problems with the scoping in eu4
- Posted by mattlewis (admin) Jan 07, 2011
- 1975 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.
I don't know where you got this idea. You can reuse for loop variables as much as you want.
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.
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.
Well, you may think that's how it should work, but I disagree.
[quote bill]
3. While with entry:
Starting at the bottom of a loop to avoid initialisation problems is bad design. Performing a sequence of statements out of order is *unstructured*. In the context of variable declaration it is a *jump into scope*.
It will break things.
And it is picked up by the compiler.
Starting at the bottom could mean starting 200+ lines away from the head of the loop (really bad stuff - but possible).
It's a choice of evils I suppose. Allow coders to avoid repeating themselves, or adhere to super strict structured programming paradigms. A 200+ line loop is bad stuff no matter what structured or unstructured programming is involved.
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.
They may have, but I didn't. You either change the flow of the code, or move the condition to the bottom, which for me at least, makes the loop more difficult to read. Sorry, I really can't figure out what this has to do with the additional, smaller scopes.
4. Switch:
No one seems to have commented on this.
Switches tend to be long as they enumerate the values the switch variable can take.
Declaring variables in a switch means they will be in scope over a large piece of terrain and multiple case labels. Jumping into scope will certainly happen. Fall through will allow other ways of coming into scope.
If variable declaration is outlawed in switch it would be no loss. However it raises an issue which is what to do if you want a local variable in a switch.
It is possible that no one has commented because they could not figure out what you were talking about. Again, it's certainly not euphoria 4.0. For example:
-- bug.ex integer c = getc(0) switch c do case 'a' then integer x = 1 ? x case 'b' then ? x end switch
$ eui bug
bug.ex:8
<0074>:: Errors resolving the following references:
bug.ex (8): x
? x
^
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.
I recall talking about doing this, though we settled on using the blocks defined by existing euphoria flow control. The then/do...end blocks define our scoped blocks. I might be worth revisiting adding an explicit block. I don't recall why we decided against it.
Conclusion:
But first scope needs to be fixed.
While I admit that there are additional ways in which euphoria scopes could be enhanced or refined, I really don't see any existing bugs that need fixing. In fact, in several cases, euphoria already does what you said it should, and trying to do what you think it does will result in an error.
Matt
