Re: routine_id evaluation
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM> Dec 02, 2000
- 576 views
Derek Parnell writes: > Robert, did you get out of the wrong side of bed this morning. > Please don't play semantic games. You know that > I already know how it works now, and you > know perfectly well what it is that I'm asking for! 1. I'm not playing games. 2. Apparently you don't understand how it works. 3. I'm really not sure what you are asking for. I was simply trying to explain how routine_id() works as simply and clearly as I can. > Of course its currently done at run-time > because its an interpreted language. > With an interpreted language, everything is run-time! No. I really and truely mean it's evaluated at run-time, while your program is executing statements. Try this piece of code to convince yourself: procedure foo1() puts(1, "foo1 called\n") end procedure procedure foo2() puts(1, "foo2 called\n") end procedure integer r for i = 1 to 5 do r = rand(2) call_proc(routine_id(sprintf("foo%d", r)), {}) end for > However, it seems to me that *if* Euphoria > internally stores the location and names of all its routines > during the initial syntax pass, then at the time that > routine_id() actually executes, it could look up > the internal table That's what it does - even with the Translator where you can actually see the table (if one is necessary) in init_.c. But it won't search for routines that are defined after the point of the call to routine id. This was a deliberate, albeit somewhat strange and controversial design decision made in the interests of avoiding ambiguity, and promoting the "define-it-before-you-use-it" philosophy. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com