Re: Euphoria Interpreter design
jiri babor <jbabor at PARADISE.NET.NZ> wrote:
>>Euphoria declare-before-use is one of it strong points. It enhances
>>redability & conceptual organization.
>
>Just like the Pavlov's dogs: totally predictable. Sorry, Daniel, but
>you and your fellow travellers cannot trot out the same unjustifiable
>cliches every time someone asks for a bit of programming freedom, and
>get away with it. 'Declare-before-use' principle enhances your
>programming roughly the same way a straight-jacket enhances your
>mental health. And how running backwards or standing on my head
>improves readability of anything is also a bit of a mystery, to me
>anyway. And when you finally trap that strange and elusive beast you
>call conceptual organization, enhanced or not, please let me know, I
>sure want to see it. jiri
First of all, you don't get "freedom" by declaring routines anywhere you
want, in much the same way you don't get "freedom" from allowing
uninitialized variables, invalid subscripts, and invalid parameters. Instead
of allowing us the "freedom" to do all of these things, Euphoria "forces" us
to do things in such a way that we have freedom *from* many of the mistakes
that would result from allowing these things. So there's more to "freedom"
than simply doing whatever the heck you want. The only straight-jackets I
see are the bad habits we programmers have learned from other programming
languages. Pavlov's dogs, indeed.
So, leaving aside the emotional appeals and verbal attacks, let's try and
clarify the issues here -- examining why declare-before-use is so attractive
to begin with, and looking at how Euphoria works now.
When I first discovered Euphoria, I found that its declare-before-use method
of routine declaration was an invaluable aid to learning how this new
language worked. Whenever I was looking at the source code for a Euphoria
program, I *always* knew I could find a routine's declaration *before* it
was used. I could always find the main routine (whatever it was) at the very
bottom of the source code. I always knew that, if a routine was being called
from somewhere, that I should look backwards from that location to find the
routine's declaration, either within the file or within one of the include
files. And I always knew that each succeeding routine was building on the
routines declared before it, which certainly seemed intuitive to me -- far
more so than the willy-nilly way programmers can do things in QB, C or
Cobol.
Of course, nowadays in Euphoria you won't *always* find a routine's
declaration before it's called -- routine_id() has seen to that. While
routine_id() is certainly a necessity for Windows event-based programming,
it has also introduced a great amount of confusion into the language where
before there was only simplicity. Extensive use of routine_id() can result
in some very weird problems that can be extremely difficult to track down,
even with trace(). (And I'm speaking from experience here...)
Before routine_id() came along, Euphoria's declare-before-use routine
declaration made perfect sense with the way everything else in the language
worked. Now, with routine_id() blurring the lines, it's more difficult to
see the benefits or necessity of declare-before-use. This is most likely why
declare-before-use has come under so much attack recently.
So perhaps, now that we have routine_id(), we should allow routines to be
declared anywhere in the source code, completely doing away with
declare-before-use. However, if we allow this, then we must change some
other things that Euphoria currently does. An example:
------------------------
procedure some_proc(sequence s)
puts(2, s)
end procedure
procedure Puts(integer fn, sequence s)
puts(fn, s & '\n')
end procedure
procedure puts(integer fn, sequence s)
Puts(fn, s)
end procedure
procedure some_other_proc(sequence s)
puts(2, s)
end procedure
------------------------
Now, ignoring the impractical nature of this example, we can see that
Euphoria's current way of doing things makes sense here -- some_proc() calls
the built-in puts() while some_other_proc() calls the redefined puts(). This
*only* works because of Euphoria's declare-before-use nature; routine
redefinition would be *impossible* otherwise -- some_proc() and
some_other_proc() would have no idea which puts() they should be calling,
and calling the redefined puts() would result in an infinite, mutual
recursion between puts() and Puts().
So, if we're going to do away with declare-before-use, we've got to do away
with built-in redefinitions. I don't know how much this will impact other
Euphoria programmers, but it would force me to completely change what I'm
doing with some of my custom include files I've been tinkering with (far
more practical uses than the above example). Maybe I'm the only Euphoria
programmer making extensive use of this built-in redefinition ability, but I
don't think so.
This, by the way, is also part of the basis for the "weird" behavior of
routine_id() -- since the built-in routines can be redefined, routine_id()
must be called *after* the routine in question has been defined, to avoid
the potential ambiguity shown above. So, elimination of declare-before-use
would eliminate built-in redefinitions, but allow routine_id() to function a
bit more intuitively, perhaps a bit less strangely.
So the argument isn't so much a question of which side is right and which
side is wrong. It's more a question of weighing the pros and the cons of
each side, looking at how Euphoria has changed with routine_id(), and trying
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. Not quite
as much fun as emotional appeals and verbal attacks, but far more useful if
we actually want to arrive at a solution.
Gabriel Boehme
|
Not Categorized, Please Help
|
|
