OpenEuphoria

2. Re: a Question on routine_id()

• Posted by Robert Craig <rds at EMAIL.MSN.COM> Mar 31, 1998
• 686 views

Kasey asks:
> Does routine_id() have to follow the routine it's getting the
> id for? I thought it could come before (for mutual recursion).

Yes, routine_id() must follow the routine that it's searching for.
In fact routine_id() will find exactly the same routines that
you would otherwise be able to *call* at the same point in
the code. (Be careful to make routines "global" if they are in
other source files.)

So, how does this solve the "mutual recursion" problem?
Actually it solves the mutual recursion problem and the more
general "calling a routine that comes later" problem.

To call a routine that comes later in the source
you can have:

integer bar_id

procedure foo()
    call_proc(bar_id,{})
end procedure

procedure bar()
end procedure

bar_id = routine_id("bar")

foo()

i.e. you can get all the routine id's that you need *after*
the definition of the routines, and then you can store the ids
in variables that come early in your program. Then they will
all be accessible (you might declare the id variables as "global"
so you can use them in other source files too.)

You can also pass the routine id of one routine as an argument
to an earlier routine - it doesn't have to be a global variable.
something like:  foo(routine_id("bar"))

I could have defined routine_id() so it would search forwards
and backwards to find routines *anywhere* in the program
(assuming they have been defined at the time routine_id
is called.)

I chose the current behavior for routine_id for the following reasons:

    * It matches the way routines are looked-up in the symbol table
      when a normal call is performed. This makes the language
      definition simpler.

    * I could imagine a lot of very weird bugs happening if a
       library .e file used routine_id *internally* and you included this
       .e file in your program, and you accidentally had a routine
       with the same name as routine_id() in the .e file was looking
       for. You might have no idea why your routine was getting called
       since you wouldn't necessarily understand the workings
       of the .e file. I felt it would be safer if it was your job to get
       the routine id of your own routine and pass it to any library that
       wants to call your routine. There would be no surprises.

    * I am still clinging to the somewhat controversial belief, that
      there is maintenance and readability value in having the
      language force everyone to order variables
      and routines such that they are defined before they are used.
      (It also opens some possibilities for optimization that I have
       already taken advantage of.)

      routine_id gives you a mechanism for breaking that order,
      but it's much less convenient than a normal call (especially
      to call a "later" routine), and the reader of your code can
      plainly see that you are doing something
      unusual when he sees the routine_id() calls and the explicit
      call_proc() and call_func() calls.


Regards,
     Rob Craig
     Rapid Deployment Software