1. Re: Forward Definitions
David Cuny wrote...
Gabriel Boehme wrote against forward definitions:
> So, if we're going to do away with declare-before-use, we've got to
> do away with built-in redefinitions.
If this is your *real* complaint, why attack Jiri and set up straw-men
arguments against forward declarations?
Personally, I'm not fond of the idea that built-ins can be redefined
(overloaded). It flys in the face of simplicity, consistancy and
expectation:
1. Only built-ins can be redefined.
2. A built-in can only be redefined once.
3. Built-ins don't return valid routine id's.
4. Redefined built-ins return valid routine id's.
4. Built-in functions should remain constant in function.
Consider the following example:
include magic_1.e
include magic_2.e
if routine_id("puts") =3D -1 then
puts(1,"not redefined")
else
puts(1,"redefined")
end if
It's impossible to determine what the code will do, despite it using =
only
"built in" functions. Will it:
- print "not redefined"?
- print "redefined"?
- abort because of an error?
- abort because both include files tried to redefine 'puts'?
- abort because I didn't bother to test it? 
----------------------------
I think I'm tending to agree with the idea that the ability to redefine =
built-ins seems messy. Granted, I still see the advantages of =
declare-before-use, but redefining shouldn't be considered one of them. =
Yes, it's very useful; but then so are structures, arrays, objects, =
complex numbers, etc.
----------------------------
David continues...
I'd much rather change the behavior to:
1. Disallow routines in the same scope to be redefined.
2. Have built-ins return valid routine id's.
----------------------------
Interesting. I assume you're advocating the ability to redefine ANY =
routine? Hmm, I think it would be best to disallow redefinitions in =
general, although it would be more consistant to allow built-ins to have =
IDs (which could then be used with call_proc and call_func.) Not that it =
matters--it's probably too late to change it anyway.
----------------------------
David concludes...
and, of course, my constant complaints:
3. Change the scope of routine_id to the run time scope, not compile =
time.
4. Have routine_id return a 0 on failure, not -1.
----------------------------
As far as I can tell, routine_id DOES look up and return IDs at run-time =
(which makes the limitation all the more strange; I suspect the only =
reason the function doesn't look forward is to take into account =
redefined routines...)
And I was fairly surprised when I first found out 0 was a valid routine =
ID. I don't see it as being much of a bother, except that it doesn't =
seem to fit neatly, and removes the ability to optimize a check for an =
invalid routine via:
if (routine_id (s) =3D 0) then ...
Rod Jackson
