1. Re: Forward Definitions
"Cuny, David" <David.Cuny at DSS.CA.GOV> wrote:
>> As far as I can tell, routine_id DOES look up and return
>> IDs at run-time...
>
>You misunderstand my complaint here. While the code executes at run time,
>the scope of routines that it sees is limited to that which it could see at
>complile time. For example:
>
> procedure foo()
> ? routine_id("bar")
> end procedure
>
> procedure bar()
> end procedure
>
> foo()
>
>will produce:
>
> -1
>
>even though 'bar' is defined before the point which foo is called. That's
>because the scope of the routines that foo can see is defined by where it
>was coded (before bar) and not where is run (after bar).
Ahh, I see what you mean now. However, I don't think it's a case of Euphoria
"seeing" it at compile time -- "bar" could instead be a sequence variable,
dynamically containing the names of completely different routines:
procedure boo()
end procedure
procedure far()
end procedure
procedure foo(sequence s)
? routine_id(s)
end procedure
procedure bar()
end procedure
foo("bar")
foo("boo")
foo("far")
will produce:
-1
0
1
So I don't think it's necessarily an issue with the Euphoria compiler. I
think it's more a case of routine_id() being programmed to only look
*backwards* for the requested routine, to dynamically emulate Euphoria's
current define-before-use rules. In some ways, it makes sense to do it this
way -- routine_id() doesn't have to look at *every* routine in the program,
only the ones defined *before* the place where routine_id() is called.
However, this behavior does result in some rather confusing and
counterintuitive results, as you have pointed out here.
Gabriel Boehme
