OpenEuphoria

Re: Forward Definitions

• Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Feb 24, 1999
• 501 views

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