Re: problems with the scoping in eu4

new topic     » goto parent     » topic index » view thread      » older message » newer message
bill said...

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

bill said...


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.

bill said...


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 
bill said...


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).

bill said...


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?

bill said...

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.

bill said...

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.

bill said...

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.

bill said...

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.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu