1. Integer skip....
Hy,
Question :
Is this a bug....
[File]
integer TEST
procedure testing()
integer TEST <-- Here doesn't come an error
TEST=1 <-- Here comes an error
end procedure
[EOF]
Is this normal ?
Bye,
PQ
QC
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
2. Re: Integer skip....
Patrick Quist writes:
> Is this a bug....
> [File]
> integer TEST
> procedure testing()
> integer TEST <-- Here doesn't come an error
> TEST=1 <-- Here comes an error
> end procedure
> [EOF]
On my machine this example gives a warning, not an error:
Warning: local variable TEST in junk.ex is not used
(where junk.ex is the name of the file)
It's referring to the fact that the *local* (file-level) variable
TEST, which is different from the *private* variable TEST
declared inside testing(), is declared but not used for any purpose.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: Integer skip....
>From: Robert Craig <rds at ATTCANADA.NET>
>Subject: Re: Integer skip....
>To: EUPHORIA at LISTSERV.MUOHIO.EDU
>
>Patrick Quist writes:
>> Is this a bug....
>
>> [File]
>> integer TEST
>
>> procedure testing()
>> integer TEST <-- Here doesn't come an error
>> TEST=1 <-- Here comes an error
>> end procedure
>
>> [EOF]
>
>On my machine this example gives a warning, not an error:
>
> Warning: local variable TEST in junk.ex is not used
>
>(where junk.ex is the name of the file)
>
>It's referring to the fact that the *local* (file-level) variable
>TEST, which is different from the *private* variable TEST
>declared inside testing(), is declared but not used for any purpose.
>
You're right!
I checked it my self and it didn't cause an error,
so I looked again, and what did I saw....
[File]
integer TEST
TEST=1
procedure TESTING()
integer TEST
if TEST=1 then --<-- This causes the Error
end if
end procedure
[EOF]
Don't tell me, let me guess...
In the procedure, TEST was not linked to a integer,
so TEST=[NOTHING].
If the 'IF' statement (or whatever you call it)
was outside the procedure, it worked, or
in the procedure was written TEST=1 (or something like that).
Am I Right?
(This is again proof that I always forget something....)
Sorry,
Bye,
PQ
QC
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
4. Re: Integer skip....
Patrick Quist writes:
> Am I Right?
Yes.
> integer TEST
> TEST=1
> procedure TESTING()
> integer TEST
> if TEST=1 then --<-- This causes the Error
> end if
> end procedure
Inside the procedure, the private variable TEST has not
been assigned any value, so if TEST=1 then ... will fail.
Outside the procedure, TEST is a different (local) variable that
has a value of 1, so if TEST=1 then ... would work outside.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
5. Re: Integer skip....
- Posted by Daniel Berstein <daber at PAIR.COM>
Feb 09, 1999
-
Last edited Feb 10, 1999
At 05:42 p.m. 09-02-99 -0500, you wrote:
>Patrick Quist writes:
>> Am I Right?
>
>Yes.
>
>> integer TEST
>> TEST=1
>
>> procedure TESTING()
>> integer TEST
>> if TEST=1 then --<-- This causes the Error
>> end if
>> end procedure
>
>Inside the procedure, the private variable TEST has not
>been assigned any value, so if TEST=1 then ... will fail.
>Outside the procedure, TEST is a different (local) variable that
>has a value of 1, so if TEST=1 then ... would work outside.
Even the "mysterious" bug has been revealed, Patrick's small
example showed me how desperatly we need a scope operator
Rob. It would be very nice to be able to access the "outer"
TEST variable from inside the procedure.
Regards,
Daniel Berstein
daber at pair.com
6. Re: Integer skip....
- Posted by Lucius Hilley III <lhilley at CDC.NET>
Feb 09, 1999
-
Last edited Feb 10, 1999
>Rob. It would be very nice to be able to access the "outer"
>TEST variable from inside the procedure.
You are silly.
integer TEST
TEST = 1
procedure TESTING()
integer LOCAL_TEST
LOCAL_TEST = 2
? TEST
? LOCAL_TEST
end procedure
TESTING()
Why do we need to access the outer variable TEST using something Dumb like
file.TEST when we can simply rename the inner variable.
IE: LOCAL_TEST vs the outer variables TEST.
Or you could rename the outer variable. I suggest the inner because
the outer variable has a broader scope.
Please deposit your $0.02 worth to continue this discussion.
Lucius L. Hilley III
On Tue, 9 Feb 1999 20:10:38 -0400, Daniel Berstein <daber at PAIR.COM> wrote:
>At 05:42 p.m. 09-02-99 -0500, you wrote:
>>Patrick Quist writes:
>>> Am I Right?
>>
>>Yes.
>>
>>> integer TEST
>>> TEST=1
>>
>>> procedure TESTING()
>>> integer TEST
>>> if TEST=1 then --<-- This causes the Error
>>> end if
>>> end procedure
>>
>>Inside the procedure, the private variable TEST has not
>>been assigned any value, so if TEST=1 then ... will fail.
>>Outside the procedure, TEST is a different (local) variable that
>>has a value of 1, so if TEST=1 then ... would work outside.
>
>Even the "mysterious" bug has been revealed, Patrick's small
>example showed me how desperatly we need a scope operator
>Rob. It would be very nice to be able to access the "outer"
>TEST variable from inside the procedure.
>
>
>Regards,
> Daniel Berstein
> daber at pair.com
7. Re: Integer skip....
- Posted by Daniel Berstein <daber at PAIR.COM>
Feb 09, 1999
-
Last edited Feb 10, 1999
At 07:22 p.m. 09-02-99 -0500, you wrote:
>>Rob. It would be very nice to be able to access the "outer"
>>TEST variable from inside the procedure.
>
>You are silly.
>
>integer TEST
>TEST = 1
>
>procedure TESTING()
> integer LOCAL_TEST
> LOCAL_TEST = 2
> ? TEST
> ? LOCAL_TEST
>end procedure
>
>TESTING()
>
>Why do we need to access the outer variable TEST using something Dumb like
>file.TEST when we can simply rename the inner variable.
>IE: LOCAL_TEST vs the outer variables TEST.
>Or you could rename the outer variable. I suggest the inner because
>the outer variable has a broader scope.
You can rename everything Lucius. But try to make that on a 2000+ lines of
code
project (and that ain't a BIG project). If you want it worst: in a
multi-developer
enviorment. Since Euphoria ain't OO (and probably won't be ever), large
projects
unevitably relay on global (more exactly: wide scope) variables and
routines. Even
if you want to write highly readable code (one of Euphoria strong points),
you are
oblied to use LOCAL_TEST... what happens when you have testing1(), testing2(),
... testingN()? Should you use identifiers like LOCAL_TEST1... LOCALTESTN?
A way to address a specific scope (or namespace) is a way to "strength" the
language, make it more powerful. I do love Euphoria, and with all things
that I love
I'm willing to make constructive criticism. (excuse my english, I suppose
it's bad
spelled)
>Please deposit your $0.02 worth to continue this discussion.
Ok ;)
Regards,
Daniel Berstein
daber at pair.com
8. Re: Integer skip....
On Tue, 9 Feb 1999 23:03:55 -0400, Daniel Berstein <daber at PAIR.COM> wrote:
>At 07:22 p.m. 09-02-99 -0500, you wrote:
>>>Rob. It would be very nice to be able to access the "outer"
>>>TEST variable from inside the procedure.
>>
>>You are silly.
>>
>>>integer TEST
>>TEST = 1
>>
>>procedure TESTING()
>> integer LOCAL_TEST
>> LOCAL_TEST = 2
>> ? TEST
>> ? LOCAL_TEST
>>end procedure
>>
>>TESTING()
>
<SNIP>
>if you want to write highly readable code (one of Euphoria strong points),
>you are
>oblied to use LOCAL_TEST... what happens when you have testing1(), testing2(),
>... testingN()? Should you use identifiers like LOCAL_TEST1... LOCALTESTN?
<Giggle>That's funny. NO, LOCAL_TEST is ({[LOCAL]}) so you could simply use
LOCAL_TEST. TEST for the file or global and LOCAL_TEST for all those
procedures that have a LOCAL TEST variable. Is that really so hard?
I expect and want my LOCAL variable to be the one used when I define it.
I feel that it should generate an error when you haven't set a value for
TEST inside the procedure when you have decalared TEST in the procedure.
And it does. Thank you Rob. I was actually wondering and worrying about
that about a month ago. Never tested it. Just assumed and avoided it.
>
>A way to address a specific scope (or namespace) is a way to "strength" the
>language, make it more powerful. I do love Euphoria, and with all things
>that I love
>I'm willing to make constructive criticism. (excuse my english, I suppose
>it's bad
>spelled)
>
>>Please deposit your $0.02 worth to continue this discussion.
>
>Ok ;)
>
>
>Regards,
> Daniel Berstein
> daber at pair.com
Lucius L. Hilley III
9. Re: Integer skip....
> <Giggle>That's funny. NO, LOCAL_TEST is ({[LOCAL]}) so you could
simply use LOCAL_TEST. TEST for the file or global and LOCAL_TEST for all
those
>procedures that have a LOCAL TEST variable. Is that really so hard?
Glup!! err... mmmhhh.... oops! your right, really silly from me ;)
But anyways a scope operator is a powerful tool.
Regards,
Daniel Berstein
daber at pair.com
10. Re: Integer skip....
Okay, forgive my ignorance but... I still don't see why the current =
scope rules are a problem here.
Sure, if you're changing a large program so that all private uses of a =
variable name are preceeded by "PRIVATE_", it will take a while; but =
then again, so would changing that same program so that all *local* uses =
of a variable name fit Euphoria's new local-scope-specific syntax. =
There's no guarantee that the particular syntax would be the same--and =
carry the exact same meaning--as in another language, even if it were =
introduced.
In each scope case, the routine (and writer of the routine) is expected =
to know all variable names in the higher scopes; or if he doesn't, then =
he can't access them anyway. So what's the problem with simply not =
naming variables in a particular scope to conflict with anything higher?
Rod Jackson
----------
From: Daniel Berstein[SMTP:daber at PAIR.COM]
Sent: Tuesday, February 09, 1999 9:03 PM
Subject: Re: Integer skip....
At 07:22 p.m. 09-02-99 -0500, you wrote:
>>Rob. It would be very nice to be able to access the "outer"
>>TEST variable from inside the procedure.
>
>You are silly.
>
>integer TEST
>TEST =3D 1
>
>procedure TESTING()
> integer LOCAL_TEST
> LOCAL_TEST =3D 2
> ? TEST
> ? LOCAL_TEST
>end procedure
>
>TESTING()
>
>Why do we need to access the outer variable TEST using something Dumb =
like
>file.TEST when we can simply rename the inner variable.
>IE: LOCAL_TEST vs the outer variables TEST.
>Or you could rename the outer variable. I suggest the inner because
>the outer variable has a broader scope.
You can rename everything Lucius. But try to make that on a 2000+ lines =
of
code
project (and that ain't a BIG project). If you want it worst: in a
multi-developer
enviorment. Since Euphoria ain't OO (and probably won't be ever), large
projects
unevitably relay on global (more exactly: wide scope) variables and
routines. Even
if you want to write highly readable code (one of Euphoria strong =
points),
you are
oblied to use LOCAL_TEST... what happens when you have testing1(), =
testing2(),
.. testingN()? Should you use identifiers like LOCAL_TEST1... =
LOCALTESTN?
A way to address a specific scope (or namespace) is a way to "strength" =
the
language, make it more powerful. I do love Euphoria, and with all things
that I love
I'm willing to make constructive criticism. (excuse my english, I =
suppose
it's bad
spelled)
>Please deposit your $0.02 worth to continue this discussion.
Ok ;)
Regards,
Daniel Berstein
daber at pair.com
11. Re: Integer skip....
>Okay, forgive my ignorance but... I still don't see why the current scope
rules are a problem here.
>
>Sure, if you're changing a large program so that all private uses of a
variable name are preceeded by "PRIVATE_", it will take a while; but then
again, so would changing that same program so that all *local* uses of a
variable name fit Euphoria's new local-scope-specific syntax. There's no
guarantee that the particular syntax would be the same--and carry the exact
same meaning--as in another language, even if it were introduced.
>
>In each scope case, the routine (and writer of the routine) is expected to
know all variable names in the higher scopes; or if he doesn't, then he
can't access them anyway. So what's the problem with simply not naming
variables in a particular scope to conflict with anything higher?
And you can also code it on assembler!
The fact that you can make it work the way it is doesn't mean it's the best
way.
Regards,
Daniel Berstein
daber at pair.com
12. Re: Integer skip....
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Feb 10, 1999
-
Last edited Feb 11, 1999
>Okay, forgive my ignorance but... I still don't see why the current scope
rules are a problem here.
Forgiven on forehand.
>Sure, if you're changing a large program so that all private uses of a
variable name are preceeded by "PRIVATE_", it will take a while; but then
again, so would changing that same program so that all *local* uses of a
variable name fit Euphoria's new local-scope-specific syntax. There's no
guarantee that the particular syntax would be the same--and carry the exact
same meaning--as in another language, even if it were introduced.
Im asuming Robert will at least add some 'auto-detection' as to what
variable is referred to, besides possible new syntaxes. Esspecially since
the namespace issue is more a 'bug'/'feature' than a bad chosensyntax. There
is nothing wrong wiht the syntax. If only there wasnt one huge global
namespace.
If file A does *not* include file B, then the identifers in file B should
not be available in file A, it sounds logical and it is. Currently its all
in one huge global namespace. Meaning if file C includes file B and file A
(in that order) the identifers from file B are avaiable in file A. Which
nobody asked for, or stated. File C has got nothing todo with the contents
and identifer uses of file B. In other words, one include file should not be
able to alter the namespace for other include files. Which is logical, since
you use those files to *seperate* different parts of your code, so when a
part works, it can not be influenced by or influence some other part.
>In each scope case, the routine (and writer of the routine) is expected to
know all variable names in the higher scopes; or if he doesn't, then he
can't access them anyway. So what's the problem with simply not naming
variables in a particular scope to conflict with anything higher?
"for local_file_first_loop_index = local_file_begincounter to
do"
I rest my case. And what if two include files both use the name FONT_ then
there would still be an issue, as to for all difference we care about, we
could have just renamed the file.
Ralf
