OpenEuphoria

Re: Declaring a Function Before it is used

• Posted by Derek Parnell <ddparnell at bigpond.com> Oct 29, 2003
• 409 views

----- Original Message ----- 
From: "Mike Nelson" <MichaelANelson at WORLDNET.ATT.NET>
To: <EUforum at topica.com>
Sent: Wednesday, October 29, 2003 6:25 PM
Subject: Re: Declaring a Function Before it is used


> 
> 
> I would like to see a C-style rule: you must declare a routine before using
> it, but can define it later (must be in the same source file--this would
> eliminate the proliferation of headers and be simpler for the interpreter).
> 
> I would suggest "declare" as a new keyword, used as below:
> 
> declare function foo(3) -- the digit is the number of parameters
> 
> declare global procedure bar(0)
> 
> declare type blech -- digit not needed, as a type must have exactly one
> parameter. But "declare type blech(1)" might be prefered for consistency.
> 
> While this is more involved than the VB approach, it would allow Eu to
> remain a one-pass interpreter, but eliminate the need for routine_id for
> this very common case.

This idea would not change the number of passes the interpreter would need to
make, because at the the time a routine call is parsed, all that would be
available to Eu is the routine's name and the number of parameters. It would
still need to parse the actual definition to know the exact signature of the
routine (assuming you are trying to catch mismatched parameter usage). For
example, it wouldn't catch this ...

   declare function foo(3)
   . . .
   x = foo(1, 2.4, "abc")
   . . .
   function foo(sequence a, integer b, integer c)
   . . .

So why bother? Either do the 'C' thing ...

   declare function foo(sequence , integer , integer)

or don't have a 'declare' but have the interpreter keep a fix-up table during
the (single) parse pass.

 
> I would also keep routine_id functioning as it does now, we need it for
> other things: indirect calls, polymorphic calls, etc.
> 

One really annoying aspect of routine_id() is that it doesn't do forward
referencing either. If it did, it would simplify libraries like Win32lib and
Diamond. We could then test for the existance of user-written routines - in
win32lib's case, I could test for routine names like "onPaint_MyWindow" etc.. so
the user of the library didn't have to do a setHandler() at runtime.

-- 
Derek