OpenEuphoria

2. Re: Variable Scope

• Posted by don cole <doncole at pacbell.net> Feb 02, 2007
• 618 views
• Last edited Feb 03, 2007

Rich Klender wrote:
> 
> Hey everybody, surprise!!!  Another question!!
> 
> I read over the part of the manual about variable scope and just want to
> bounce this off everybody to make sure I'm comprehending it correctly.
> 
> Let's say I have the following:
> 
> function somefunc(integer C)
>   integer a,b,c
> 
>   a=1
>   b=2
>   c=3
> return c
> end function
> 
> Ok, now in my main program, because c was returned, I'll be able to "see" that
> c=3.  However, because a and b are "local" to the function, I cannot, for
> instance, in my main program do:
> 
> a=a+1
> 
> and expect to get a=2 as a result.  I think I already know this cause Euphoria
> already told me that a is not defined.
> 
> However, if I do this:
> 

  I'm not saying you can't but I don't like this:

> function somefunc(integer C)
>   global integer a,b,c
> 
>   a=1
>   b=2
>   c=3
> return c
> end function
> 
The globals should be put in your main program.
 They could be put in your include like this":
 -------------------include file----------------
 global integer a,b,c
 
  function somefunc(integer C)
   a=1
   b=2
   c=3
  return c
  end function

 also you could:
   function somefunc(integer C)
   a=1
   b=2
   c=3
  return {a,b,c}
  end function

Note that the capital C is not being used in your function therefore serves no
purpose.

I'm not sure what you're trying to do here.  Capital C and lowercase c are
different but for the sake of clairity using a k would be better.

  
> When I return from to my main program, I should be able to "see" that
> a=1, b=2, etc. even though those variables weren't returned?
> 
> Thanks for the patience!!
> Rich


Don Cole

4. Re: Variable Scope

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 03, 2007
• 591 views

Rich Klender wrote:
> 
> Let's say I have the following:
> 
> function somefunc(integer C)
>   integer a,b,c
> 
>   a=1
>   b=2
>   c=3
> return c
> end function
> 
> Ok, now in my main program, because c was returned, I'll be able to "see" 
> that c=3.
Wrong. You'll have the /value/ 3, wherever you put it, but on return from the
function the /variable/ c *NO LONGER EXISTS*. You might, for instance code:

z=somefunc(x)

Then z would have the value 3 from c, and ?z would display 3, but if you wrote
?c then it would complain that c has not been defined.

Effectively, to deal with recursion, when you call a routine it creates space to
hold the locals and on return it frees that space. (See PS)

> However, if I do this:
> 
> function somefunc(integer C)
>   global integer a,b,c
> 
>   a=1
>   b=2
>   c=3
> return c
> end function

What I think you mean is:

integer a,b,c
procedure someproc()
   a=1
   b=2
   c=3
end procedure

 

Because a,b,c are defined outside the routine, they persist when it exits.

The real point of scope is:

integer a,b
procedure p()
integer b
    a=1
    b=2
end procedure

Now because there is no "a" defined within p(), the first line updates the
variable outside, but in the second line the local "b" is said to take precedence
and on exit you will find the outer "b" was not modified.

You never actually want to give two variables the same name, but when you start
writing thousands of lines of code, it becomes almost inevitable.
The best example I can give you is "for i=", which you will see many times
in any reasonably-sized program. Hundreds of different "i" may thus exist, but
thanks to scope it uses the one you meant.

Regards,
Pete
PS Technically, the actual implementation always has a space somewhere for
locals to speed things up a bit on the first call, but all programs would run the
same if that space were created at the point of the call and trashed on return,
they would just be a fraction slower.