Path: utzoo!attcan!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.misc
Subject: Call by string (was: B&D)
Message-ID: <4261@enea.se>
Date: 21 Jan 89 22:40:30 GMT
Organization: ENEA DATA AB, Sweden
Lines: 64

Some while ago I asked the following:
>But to throw some new wood on the fire, consider the following: Assume
>you have routine you want to call but whose name you don't know until
>run-time, thus you have the name in a string. Now in which langauges
>can you easily do this? Interpreting langauges like Lisp and Basic,
>support this I guess. But compiled langauges?

Since then several people have answered in various waays.
  First, some posters have corrected me and pointed out that Lisp 
could be compiled too. Of course, there is no particular problem with
implementing this in a compiled langauge; the problem lies in that 
the compiler can't perform the validation we often expect it to. 
Whether parameter profiles will match or not it can't tell. (Well, 
if we are using some 3rd class language we are not expecting this 
validation anyway.) Just finding the procedure to call it's simply 
a matter of having suffcient symbol information around.
  Someone said that this was just like a CASE statement in language
in Ada or Pascal. Most emphatically: IT'S NOT! I'll present you later
with a problem which isn't solveable with a simple CASE.
  Someone told us about $entry in PRIMOS(?). And VMS has 
LIB$Find_image_symbol for finding the address to a name, and then 
LIB$CallG for calling it. Unix surely have something similar. Yes,
this seems like the way to go. Rely on what the OS gives you. Not 
very portable though.
  Peter da Silva (peter@ficc.uu.net) said:
>I do this all the time in 'C', for one reason or another. 
>...
>} funtab[] = {
>	"fname1", func1,
>	"fname2", func2,
>...
This is of course no better no solution than the CASE proposal. Maybe
a litlte more convenient, but still have one serious problem: the names
of the routines to call must be known at coding time.

The problem I talked of: A general reusable menu handler. When the 
end-user starts the program he gets the main menu. He types a code
which the menu handler looks up in the database. The code may refer 
to another menu which in this case is displayed. It may also refer
to a specific function. In this case the menu handler calls the 
routine whose *name* it found in the database.
  The menu handler here is a reusable module which you link into
your system, probably as the main program. This is where the CASE
solution is totally unsatisfactory. For every new function we add, 
we have to modify the menu handler. Not talking of the case of moving 
to another application with new names and function codes.
  But Peter's function tables? Could one not require that every
function loads a table entry at startup with itself? The global access
cannot be a problem. Unfortunately, there is a little obstacle.
To do the loading the module has to be activated. But by whom? The
menu handler does at this stage not know about it. So you have to
have some other code that knows about all functions in the system,
and this is exactly what we want to avoid.
  (The self-loading approach could maybe work in a language with 
parallell processes, but I fail to find something workable for Ada. 
And if there is something it is a big overkill anyway.)

So in what langauge can you implement the calling-part of this menu 
handler without calling some OS function? (It will be interesting to 
see what ideas that turn up this time.)
-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se