Re: Forward Definitions
"Cuny, David" <David.Cuny at DSS.CA.GOV> wrote:
>> 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?
You misunderstood the point of my post. I wasn't specifically "attacking"
anyone. I was merely attempting to point out what forward-declarations might
do to some of Euphoria's other capabilities. And, if you'll read my post
more carefully, you will notice that I don't really come out in favor of one
side or the other.
That being said, I admit that I completely and utterly *goofed* on my
comments regarding routine_id(). After I made my post, I did some tests and
discovered -- much to my chagrin and embarrassment -- that built-in routines
don't return valid routine_id() values. Somehow, in the past, I'd never
bumped into a situation where I was trying to take the routine_id() of a
built-in. Especially embarrassing since my earlier post including my
struct.e idea for structures featured examples using the routine_id() of the
built-in integer type! Apparently, when I had run my actual tests with
struct.e, I had failed to make use of any built-in types, and instead made
use of nothing but my own user-written types. Hence, my confusion and lack
of knowledge of the facts in this regard. (I always seem to learn these
things the hard way -- next time, I'll be darn sure to check *before* I
post!)
So, because the basis of my comments on routine_id() was totally unfounded,
I can see why you would characterize these arguments against
forward-declarations as "straw-men arguments". Again, this was totally my
mistake, and my earlier comments on routine_id() should be completely
disregarded.
However, built-in redefinitions are one aspect of Euphoria which *I* have
extensive made use of, and which perhaps other programmers have made use of
as well (for example, I have extended the functionality of open(), getc(),
and many other built-in file-handling routines by redefining them -- to open
a file with one of my custom formats, I use a code such as "re" to open a
file for read in EuCode format). This feature of Euphoria would conceivably
disappear if forward-declarations are implemented. I was merely pointing
this out to alert other programmers who may also have made use of built-in
redefinitions. It is, at least, a potential concern.
And there may be other concerns as well, ones that I haven't thought of. The
point is, again, to look at both sides of the argument to find which
approach makes the most sense -- based on the way things are now, and on the
way other things in Euphoria would have to change. Regardless of our
personal feelings on the matter. Well, mostly regardless, anyway. :)
>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.
All of these are very good points. I have always felt that the way Euphoria
allows function redefinition was ridiculous. Euphoria should be *consistent*
one way or the other -- able to redefine *any* global routine globally as
many times as you want, or *unable* to redefine any global routines
globally. Built-in or user-defined should be irrelevant. Whichever side is
eventually decided on makes little difference to me -- I can always rewrite
my include libraries and the programs that use them, if necessary. I would
simply like some consistency.
>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.
Point #1 would eliminate ambiguity -- which is good -- and open the door for
forward-declarations -- which may actually make more sense in a language
containing a function like routine_id(). Then again, the benefits of
define-before-use -- being able to find a routine's declaration before it's
used, forcing programmers to logically organize their routines -- cannot be
denied. In any event, the door would be open, should such a change be made.
Allowing routines in *different* scopes to be redefined could be very
useful. The primary example which comes to my mind is the problems which
result from RDS including a separate, local lower() function in ed.ex. When
you try to enhance the editor, and you just *happen* to include wildcard.e
along the way, you get a redefinition error. Allowing ed.ex to access its
own *local* lower() function, while allowing the other include files to make
use of the *global* lower() function from wildcard.e, may be an acceptable
solution to this problem.
Of course, what happens to the ed.ex routines defined *before* the local
lower() function? Would they be allowed to access the global lower()
function? If so, then we're back to redefining global routines again...hmm,
perhaps this requires more thought...
Point #2 would also be very nice, especially for the expression evaluator
I've just started trying to write... :)
>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.
I agree with Point #4 -- the whole business of allowing zero as a valid
routine_id() seems like a backwards step from the "intuitive" way Euphoria
does things (sequence indexes start at 1 not 0, for example). However, since
much program logic has already been written to expect -1 as the failure
value, I don't see this one changing anytime soon. (BTW, I've always felt
the same way about the built-in open() function -- why allow 0 for a valid
file number? Why not start at 1? Again, a moot point.)
However, Point #3 seems a bit strange to me, since I thought the scope of
routine_id() *was* the run time scope. Could you elaborate what you mean by
this please? I've already made it quite clear that I'm *not* an expert on
routine_id(), so perhaps you could enlighten me. :)
Gabriel Boehme
|
Not Categorized, Please Help
|
|
