Re: routine_id evaluation

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu