1. Re: Forward Definitions
David Guy wrote:
>>3. Change the scope of routine_id to the run time scope, not compile time.
> ...
> If it's not too much trouble, could you give a simple example of what you
> mean by the above statement, and how/why it would/could be a problem?
routine_id returns an identifier to a user-defined routine. It will fail
(return -1) under one of the following circumstances:
1. The routine is not defined, or local to another include file;
2. The routine is not part of the current scope; or
3. The routine is a built-in, such as gets or puts.
routine_id can only "see" routines that have been defined up to the routine
that it is embedded into. For example:
procedure foo()
end procedure
procedure test( sequence procname )
if routine_id( procname ) = -1 then
puts( 1, "can't see " & procname & "\n" )
else
puts( 1, "can see " & procname & "\n" )
end if
end procedure
procedure bar()
end procedure
test( "puts" )
test( "foo" )
test( "bar" )
if you run this code, you will get the following results:
can't see puts
can see foo
can't see bar
'puts' cannot be seen because it is a built-in function. This behavior
certainly suprised me when I first saw it, but I suspect that there are
compelling reasons for being that way. My guess is that 'routine_id' is
probably pretty gruesomely coded, and we are lucky to have *anything* like
it at all.
'foo' can be seen, because it was defined before 'test'. Since 'test' can
see 'foo', so can 'routine_id'.
'bar' cannot be seen, because it was defined after 'test'. Since 'test'
cannot see 'foo', neither can 'routine_id'.
The way I would *prefer* the code to work is:
'bar' can be seen, because it is *called* after 'bar' is defined.
There are various reasons for the preference; most of them can be worked
around by using routine_id at the point were I need the routine id.
-- David Cuny
