OpenEuphoria

1. scope of variables

• Posted by coconut Dec 29, 2010
• 2960 views

enum a,b 
while 1 do 
   integer b -- the scope of this variable should be limited to the while 
   b=1 
   ?b 
   exit 
end while 

trying to run that code report an arror saying that b is already defined. It's not what I would have expected. In other languages that permit variable declaration inside code block the scope is limited to the block.

I opened a ticket for this. It is a bug.

Jacques

3. Re: scope of variables

• Posted by coconut Dec 30, 2010
• 2855 views

I desagree with you on this. The rules of lexical scoping are so that you can define a variable of the same name inside narrower scope and this new variable will shadow the outer one.

integer a 
procedure foo() 
   integer a -- this is accepted and this new 'a' shadow the outer one. 
   ... 
end procedure 
-- the same should be true with this 
while 1 do 
  integer a -- this should be accepted and shadow the 'a' at top level. 
  ...  
end while 

look at others languages that implement scoping at block level (at think lua does) and you'll see that it is done as I says.

Jacques

5. Re: scope of variables

• Posted by DerekParnell (admin) Dec 30, 2010
• 2872 views

I also think that Euphoria should be consistent with many other languages. Namely that 'if', 'else', 'while', 'loop', and 'for' statements begin a new block and that blocks have their own scope.

However this type of lexical scoping is not one of Nature's Axioms and instead is left up to the language designer. So it is perfectly reasonable to leave Euphoria as is, unless we, as a community, decide that it should change.

7. Re: scope of variables

• Posted by jaygade Dec 30, 2010
• 2871 views

I think that it should be changed. The current behavior is inconsistent with other languages and unintuitive. One would expect a block started by a loop or an decision block to work the same as a block defined by a procedure or function.

9. Re: scope of variables

• Posted by jeremy (admin) Dec 30, 2010
• 2840 views

Changed in what way? There are two possible options here:

integer a = 10 
 
procedure abc() 
    integer a = 20 -- INVALID, a already exists in a containing scope 
end procedure 

and the other change is to make all scopes work like this

integer a = 10 
 
procedure abc() 
    integer a = 20 
    ? a 
end procedure 
 
-- procedure output is 20 

We have to think carefully about this. I'll ask my question again since it seems to be ignored, what is a valid use of redefining a variable in a more narrow scope? In the directly above synario you have now cut off all possibility of accessing the file wide a. Why would you want to do that? Bearing in mind that in a real application there would not be a file wide variable named a, it would be something useful such with a useful name.

For me it seems much more prudent that if there were to be a change the change to be never to allow a variable inside the same namespace to be redeclared. One may say it's heresy, but please tell me why and give valid examples as to why it is necessary to redefine a variable in a more narrow scope to mean something totally different than what it means in a file wide scope.

Jeremy

11. Re: scope of variables

• Posted by jimcbrown (admin) Dec 30, 2010
• 2829 views

integer a = 10 
 
procedure abc() 
    integer a = 20 -- INVALID, a already exists in a containing scope 
end procedure 

integer a = 10 
 
procedure abc() 
    integer a = 20 
    ? a 
end procedure 
 
-- procedure output is 20 

I'm going to go against the grain here. I'm fine with this breaking:

for .. 
	integer b 
end for 
integer b 

That should cause a redefinition error IMVHO. That'd make the behavior consistent and also keep things simple.

The only exception to this rule should be the one that was inherited from pre-4.0 - so locally defining a variable in a file and then redefining it inside a routine is ok.

13. Re: scope of variables

• Posted by jeremy (admin) Dec 30, 2010
• 2830 views

This is the main reason why if a change occurs I think it should be the first. Do not allow re-definition of a variable in a child scope, whether that be a procedure, if, for or whatever.

The first solution is making it consistent.

I do not think features were added by mere request. They had to have valid uses. Everything added in 4.0 has a valid use. Everything in programming including a procedure, an if statement and goto can be misused but all have very valid purposes. Re-defining a variable of a different type, cutting off access to higher scope leveled variables I personally do not see a valid reason for. Nor do you it appears. Add it because we can? I don't think that's wise and it has not been the practice thus far w/Euphoria. It shouldn't start to be either.

Obviously quite a few people have not chimed in yet, so I'm sure a lot more discussion to follow!

Jeremy

15. Re: scope of variables

• Posted by jeremy (admin) Dec 30, 2010
• 2826 views

Maybe my original example was unclear. Here is another of what I consider to be the proper solution

integer file_log_level = log:WARNING 
 
procedure abc() 
    integer abc = 20 -- VALID 
    integer file_log_level = log:ERROR -- INVALID 
    if 10 then 
        integer def -- VALID 
        integer abc -- INVALID 
    end if 
end procedure 

i.e. redefinition of any variable in any child scope is invalid. This is consistent and good practice. There is no reason to redefine file_log_level inside of a procedure or any child scope.

Jeremy

17. Re: scope of variables

• Posted by jaygade Dec 30, 2010
• 2819 views

integer file_log_level = log:WARNING 
 
procedure abc() 
    integer abc = 20 -- VALID 
    integer file_log_level = log:ERROR -- INVALID 
    if 10 then 
        integer def -- VALID 
        integer abc -- INVALID 
    end if 
end procedure 

Then Euphoria should be changed to work that way I guess. I see it as less optimal but acceptable, as long as name clashes were limited to the same file and not across includes. Which I guess it wouldn't with all the different include scopes that euphoria now has.

19. Re: scope of variables

• Posted by jimcbrown (admin) Dec 30, 2010
• 2828 views

integer file_log_level = log:WARNING 
 
procedure abc() 
    integer abc = 20 -- VALID 
    integer file_log_level = log:ERROR -- INVALID 
    if 10 then 
        integer def -- VALID 
        integer abc -- INVALID 
    end if 
end procedure 

The problem with that is that it could break a lot of pre-existing code. All the way back from the 1.x days.

Since we're post-4.0, we absolutely can not make this change. We can not break existing code.

21. Re: scope of variables

• Posted by jeremy (admin) Dec 30, 2010
• 2815 views

Maybe provide a with/without option that is on by default because it is a pretty bad practice. i.e.

without strict_naming 
 
integer abc = 20 
 
procedure def() 
    sequence abc = "John" 
    ? abc 
end procedure 

Valid since without strict_naming, but by default strict_naming is on.

Jeremy

23. Re: scope of variables

• Posted by coconut Dec 30, 2010
• 2822 views

without strict_naming 
 
integer abc = 20 
 
procedure def() 
    sequence abc = "John" 
    ? abc 
end procedure 

Why do you want to change a rule that is accepted in all languages: >>One can redeclare a variable inside a function and shadow an outer one.<<

There is nothing wrong with that rule. If you do that, one will have to constantly use name space qualifier, horrible!

It's better to leave it as it is now than make things even worse.

Jacques

25. Re: scope of variables

• Posted by DerekParnell (admin) Dec 30, 2010
• 2830 views

BTW, how does one refer to the encompassing var that has been shadowed in other languages?

27. Re: scope of variables

• Posted by jeremy (admin) Dec 30, 2010
• 2819 views

In the languages that allow it (not all, and not common) you don't. You're cut off from it. There may be an obscure langauge out there that allows parent access, but I don't know of it. Any one else?

I'll research this topic in a bit with some other common languages. I'm not closed to the idea of causing a variable to shadow another, I just think it's a bad language design, bad coding design and has not a single thing going for it. One mentioned not being able to remember a previously defined variable and accidentially creating the same variable name after a few months. That's a pretty poor reason I think. At first run of your program, it will immediately say "Cannot redeclare variable..." and then you'll remember. Thus, we are still down to no valid reasons.

When working with PHP, the only thing I have found when this type of functionality exists is bugs that are hard to track down and it's not a bug here or there. It's a very common bug. Why do we want to open Euphoria up to this possibility w/zero benefit? Some may say "look at goto..." #1. Goto has valid uses and #2. Goto cannot be accidentally used and cause bugs. I could easily (as anyone) accidentally reuse a variable, then a month later see the top level variable and in side of a function begin working and wonder why my top level is not being changed.

If we decide to go this method, at bare minimum a stark warning that is on by default needs to be issued if a variable gets shadowed. This is a poor comprimise because in the end the warning will just make everyone code the right way as an error would have or it will cause all sorts of eu.cfg files to start having warning flags disabled and then one person deploying code thinking all is OK, and another (with out ignoring warnings) complaining the code is buggy. Over all, a poor decision for Euphoria users all around: Let's change the language to allow buggy code for no reason. We might as well insert random gotos in the IL Ok, a bit extreme but not too far

Jeremy

29. Re: scope of variables

• Posted by coconut Dec 30, 2010
• 2785 views

Do I understand you well Jeremy? Do you say that inside the same file I should not declare a variable inside un procedure with a name already used at top level. It's permitted right now and I do it sometimes. Bad coding? why? It didn't gave me any headache up to now. If the design of a project is correct a source file is rarely over 5000 lines and it is relatively easy to remember global variables for that particular file and if I need to access a particular top level variable inside a procedure I won't name a local one of the same. The problem of naming is more one of project wide and libraries use than one of a particular file.

// when I compile this with Watcom there is no error not even a warning. 
// test 
#include <stdio.h> 
#include <windows.h> 
 
int i=1; 
 
void main(){ 
  int i=2; 
  printf("%d\n",i); 
} 
 

Jacques

31. Re: scope of variables

• Posted by jeremy (admin) Dec 30, 2010
• 2755 views

Yes.

Can you give a few examples?

Yes. You mask a variable of a higher scope level that is there for a reason. If it does not need to be a higher level then it should not be. If it is a higher level, then it should be respected.

It's giving you a problem now? Nothing has changed on this front, it should work as it always has. The only difference is that block statements now create their own scope, if you want to use it, i.e. declare new variables inside of it.

Top level variables should never have names that conflict with procedure level variables. What's the purpose? When names conflict with that from another include, the same rules apply except that it becomes only public members of the included file, which further reduces the possibility of a conflict.

The issue has come up, so we are discussing it. Many people need to chime in, I'm just one. When one was fighting for goto, one argument was giving that language a, b and c all support it so Euphoria should. That was quickly dismissed as an invalid argument. goto had to stand on the merits of its own usefulness. Something as fundamental as scoping needs to stand on its own two feet as well.

Jeremy

33. Re: scope of variables

• Posted by jimcbrown (admin) Dec 30, 2010
• 2781 views

namespace test 
 
integer i=1 
procedure test1() 
   integer i=2 
   ? test:i 
   ? i  
end procedure 
test1() 

I think, for this case, it makes more sense. You can use a shadowed variable, meaning that one is more likely to use it.

integer abc = 10 
if abc > 5 then 
    sequence abc = "John" 
    if equal(abc, "John") then 
        atom abc = 12.3 
        return abc * 5.8 
    end if 
end if 

I am seeing a lot of reasons to treat this case differently than the above one, at least. In spite of being the same conceptually, it seems that in practice there are big differences.

35. Re: scope of variables

• Posted by jeremy (admin) Dec 30, 2010
• 2749 views

Yes, that is one proposal. It should be clear that I am not the person to persuade. It is a group effort and I bear no more vote than anyone else. Now, I wouldn't describe it as an opportunity but rather a deep dark trap waiting to snare Euphoria programmers everywhere in due time. Not all, of course, many will be able to weild it just fine and never have issue, others will not be so lucky. I still wonder why we would wish it on anyone for no benefit. Can you provide code that it would break and why it is necessary (or prudent) to have such constructs in your code? It would nice to see some good examples. Maybe it would bring about a different proposal.

Jeremy

37. Re: scope of variables

• Posted by mattlewis (admin) Dec 31, 2010
• 2696 views

This!

My take is that we should probably allow the new, smaller scopes to have variables shadowed, as it makes scopes more consistent (i.e., some scopes would no longer be more equal than others).

There is zero probability, I think, for removing any shadowing by routine level vars of file level symbols. Using a configuration option (with/without) is slightly less bad, but an awful idea, I think. It would make coding more difficult to need to check / set this option.

Matt

39. Re: scope of variables

• Posted by coconut Dec 31, 2010
• 2682 views

here an example, an editor as a text buffer with cursor position referenced by 2 top level variables bcol and bline and there is a procedure that modify the content of that buffer but must leave cursor position unchanged at exit. all the code elsewhere use bcol and bline to access character in buffer. It make sense to use local variables of same name inside that procedure

sequence buffer -- text buffer 
sequence bcol -- cursor column 
sequence bline -- cursro line 
 
--insert text at current cursor position and leave cursor where it is. 
procedure insert_text(sequence text) 
integer bcol=bcol -- local copy 
integer bline=bline -- local copy 
--- code here 
    
end procedure 
-- at exit bcol and bline are preserved without need to restore from a temporary storage 

Jacques

41. Re: scope of variables

• Posted by jimcbrown (admin) Dec 31, 2010
• 2695 views

This was a design decision made way back when it was decided to allow one to declare a variable anywhere inside a routine.

Jeremy has proposed that this be linked to the concept of shadowing a variable in the local file vs a private variable in a routine.

E.g., that this be made illegal:

integer i 
 
function s() 
integer i = 1 
return i 
end function 

He's all-or-nothing on this point (well, AFAICS and IMVHO, with statement option aside).

This is what would break existing code (all the way back to 1.x).

This actually raises a counter argument. Euphoria already had this feature. We've had shadowing all the way back since the 1.0 days of Euphoria, yet never had a problem before. Jeremy is saying that allowing shadowing in the new scopes can cause all sorts of bugs - but is there an Euphoria example from the past that demonstrates this?

If not, then why assume that it would cause a problem with the new scopes?

I think comparision with PHP (which does things like scoping quite differently than Euphoria, or C for that matter) is less valid than an Euphoric example.

43. Re: scope of variables

• Posted by ChrisB (moderator) Dec 31, 2010
• 2607 views

integer i 
 
function s() 
integer i = 1 
return i 
end function 

Ah, I see. Well obviously that's absurd. You can't change something that fundamental without expecting a huge backlash. But I still think that 'microscoping' within loops inside a function/procedure is wrong, and would lead to great confusion.

PS - I'm not a language designer, just a simple user.

Chris

45. Re: scope of variables

• Posted by Fernando Dec 31, 2010
• 2646 views

IMHO, that would break modularity (Modular Programming) (and consequently difficult maintainability), one of the best concepts of programming, designing,... . For example, a function with no side-effects should work without modification independently where it is placed.

Example: suppose someone has developed a library (lib.e). Many people start to use it. One of them implements the following code:

--file: prg.ex 
include lib.e 
... 
procedure xyz() 
sequence table 
... 
end procedure 
... 

Then, some time later, the library developer decides to improve the library, ADDING a public variable:

--file: lib.e 
... 
public sequence table  
... 

I think it is desirable that prg.ex still works without any modification. But with the Jeremy's first proposal this would not occur. In general, since the "as" in "include" is optional, many more clashes could occur if namespace is not used and that proposal is implemented.

- Fernando

47. Re: scope of variables

• Posted by jeremy (admin) Dec 31, 2010
• 2578 views

integer i 
 
function s() 
integer i = 1 
return i 
end function 

This is a very poor example which does not state reality, well maybe reality in a very poorly coded program. Why would there be a top level i variable? A more meaningful example would be something such as:

sequence current_filename = "john.txt" 
 
function get_token() 
    sequence current_filename = "jim.txt" 
    abc_xyz() 
end function 

This goes back to proper variable naming. However, I can see I'm fighting a loosing battle. People want the ability to shadow poorly named variables. To me, it's very unfortunate that we allow such bad practices for no benefit.

Jeremy

49. Re: scope of variables

• Posted by ChrisB (moderator) Dec 31, 2010
• 2622 views

Hi Jeremy

Surely it is the choice of the coder whether bad practices are used or not. This is the beauty of euphoria - if you want to code like me, you can, if you want to code like a professional, then you also can. You are not forced down a route. I agree that code should be easy to follow and maintain, but it is the responsibility of the coder to enforce this (or not), and IMHO not the responsibilty of the language.

Chris

51. Re: scope of variables

• Posted by jaygade Dec 31, 2010
• 2584 views

I do too. I thought that everyone did. I thought that it was required by the language.

Now if your vote is to remove the feature of declaring variables in blocks other than procedures and functions, then that's valid. I never thought that it was much of a feature anyway.

I don't know what you mean.

53. Re: scope of variables

• Posted by jimcbrown (admin) Jan 01, 2011
• 2526 views

Actually, if it has to wait for 4.1, then we need to reconsider the impact.

coconut's solution (to allow shadowing inside loops, etc) would not break anything, as it's just increasing the range of what is permissible.

Leaving it alone, as-is, would not either.

However, any other solution (not allowing variable redeclaration inside a loop, changing blocks so that one can not declare a variable inside a loop and then again outside a loop) could break 4.0.0 code.

So, either this is serious enough to make it into 4.0.1 (invalidating any program that actually relies on the bad? broken? 4.0.0 behavior) or else we should not change it in a way that could break any future 4.0 program written between now and the release of 4.1

55. Re: scope of variables

• Posted by jimcbrown (admin) Jan 01, 2011
• 2504 views

4.0 supports being "able to declare variables willy-nilly", so these sort of poor ugly hacks are no longer necessary.

57. Re: scope of variables

• Posted by jeremy (admin) Jan 01, 2011
• 2435 views

Declaring variables inside of the scope can make mainteance and readability much easier. It keeps variable definition close to variable use.

i.e.

function copy_file(sequence from_fname, sequence to_fname) 
    integer status 
 
    status = c_func(hCopyFile, { ... }) 
    if status = BAD then 
        sequence error_message = c_func(hErrMessage, { ... }) 
 
        log_error(error_message) 
 
        return { status, error_message } 
    end if 
 
    return status 
end function 

It can also prevent declaration when not necessary, i.e.

function backup_file(sequence fname) 
    sequence full_fname = absolute_filename(fname) 
 
    if not file_exists(full_fname) then 
        return { 0, "Source file not found" } 
    end if 
 
    sequence backup_fname = full_fname & ".bak" 
    if file_exists(backup_fname) then 
        return { 0, "Backup file already exists" } 
    end if 
 
    integer status = copy_file(full_fname, backup_fname) 
    if status = BAD then 
        sequence error_message = blah() 
        log_failure(error_message) 
        return { status, error_message, full_fname, backup_fname } 
    end if 
 
    return status 
end function 

Those are just two very simplistic examples. Declaring those at the top of the method declares variables that will not be used most of the time (a valid copy/backup). It also makes the point of definition futher from the point of use making it more difficult to follow when you begin to have hundreds of methods in your program. Code templates also can not be used as much if all variables are declared at the top of the procedure/function, reducing the automation gained by your editor/IDE and increasing potential for bugs. Declaring at the top instead of close to the use also encourages one to "reuse" a variable w/a slightly incorrect name. Another problem with declaring at the top is that the temp variable is not cleared until it goes out of scope, thus your program will use more memory (maybe not an issue for most routines but some it can be significant).

Much more complex examples of how declaring variables close to their use and w/in the blocks they are to be used can be found throughout the standard library, various 4.0 projects and various places in Euphoria code.

Jeremy

59. Re: scope of variables

• Posted by mattlewis (admin) Jan 02, 2011
• 2518 views

To be clear, variable can be declared inside of if-then, while, for, etc code blocks. But those cannot (currently) shadow names of variables that are in the same routine.

Matt