Re: a Question on routine_id()
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Mar 31, 1998
- 801 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