Re: Forward Definitions
- Posted by "Boehme, Gabriel" <gboehme at MUSICLAND.COM> Feb 23, 1999
- 453 views
"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