Re: A question about certain language features
On Sat, 16 Feb 2002 16:52:48 -0300, you wrote:
>By splitting the declaration from the
>assignment:
>
> integer foo
> ...
> foo = 123 -- default value
>
>you increase the chances that the code will encounter an uninitialized
>variable.
Finally I just understood:
integer foo foo=123
integer bar bar=7
procedure f(integer k, sequence s)
is fine, but
procedure f(integer k, sequence s)
integer foo foo=123
integer bar bar=7
gives an error. It's all about scoping rules. Eg a for loop introduces
a new scope, so in
for i=1 to 10 do
...
integer k
end for
what the hell would be k's scope? (not that anyone is asking for
integer declarations in the middle of a for loop, but it's all part &
parcel of the same thing.) Above, the scope of bar clearly would not
include the code foo=123 but the only scope bar can legally have is
all of procedure k. And the semantic problems. Rob, if you're
listening, please please NEVER put that in!
>And when that happens, the Euphoria interpreter stops, and
>anything the user was doing is permanantly lost.
OH GOD! Now I hadn't really thought of that but it is a MAJOR omission
- which hopefully should be relatively easy to rectify. Any serious
programming environment should have an application-defined recovery
point [defined/set with routine-id()?]. When a fatal error occurs, the
interpreter should take a copy of the recovery routine (if defined),
clear it, then invoke it via the copy. Rob, forget scoping or multiple
or nested recovery routines, just one at top level. It is up to the
programmer to ensure any data they need is available (global) & if
they are stupid enough to reset the recovery pointer making the thing
loop it's the programmers problem not the interpreters. It would be
very nice, but not necessary, to supply the recovery point with (the
stuff you have just written to) the ex.err file. On the other hand it
may be easier/better to throw it away to ensure it is safe to invoke
the top-level routine.
Pete
|
Not Categorized, Please Help
|
|
