Re: Euphoria Interpreter design
>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.
In other words, you are comparing the need for linear order with the need to
initialize variables
And you would be right, if so, in the real world, these are comparable. But
they are not.
The difference is, initialize a variable is good programming practise. There
is not a case in the world where you do not
want to initialize a variable before using. It therefor is *not* a restriction.
However, linear order is *not* the best choice
for every program/solution. There are many cases where this forces us to put in
a triangle in a circle. It doesnt fit right, we
need to stretch and stretch.
It forces us, I agree. But I do not agree it forces us to program better
organized. The linear organization is not, by
default, the best organization.
Thats the whole point.
>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.
In other words: linear order restriction is good because then can then
be sure where the routines are ?
And to prove it you make the a comparisement with basic, C and cobol.
Well, the uselessness (is that a word ?) of the comparisement will be
forgiven, but lets focus on your argument:
Say, you a large project and you have a main routine at the end, it
calls some other routine called 'pos', and lucky
you... you know it *somewhere* above and not below. I want more freedom, not
more restrictions, you can still program linearly
if you are incapable of finding the most *logical* order yourself. However, let
me use the order I choose, just like you get to
use the order you choose. And dare I say it, again (do, people actually here me,
or are they just immuum to arguments ?), I can
order a program much better (much more logical) that Euphoria could ever force
me (or you).
And if linear order would be the best for a certain case, or part of a program,
guess what ? Im capable of ordering it that way.
>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...)
I agree, thats why I want to mutal recursion in a normal way.
>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.
Name one program, that still isnt ordered linear, eventhough the use of
routine_id ()
No program ive seen have used it for mutal recursion is such a complex way.
Maybe one or two small routines somewhere, but
mostly its used for managing routines, nothing more. And the order is then still
linear.
>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:
Your example applies even more to namespace issues than to order issues.
>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().
Interestingly, you do have a point. But like I said, I would be happy if mutal
recursion would only be available throughout
multiple include files.
That would IMHO be the right compromize and problems such as the above would not
exist.
>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.
It doesnt work that strangely. But if it was more a solution to a symptom that
to a problem ? I dunno..
>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.
Actually, Jiri did use real arguments, that stand up when reason is applied.
David's and the arguments at the beginning of your mail, are totally illogical.
Its like saying 'it just is that way'.
And I can understand Jiri's little emotional 'color' that he put in his mail,
but such arguments are just a rendez-vous.
They come up with the goto discussion, the short-circuit discussion, the
structures discussion (c++ with sequences: another
irrelevant argument) etc.
They would always be claiming that it forces you to code better, as if I need a
leech to stop me from getting under a car, while
crossing the street. And even more annoying is my 'route' is better that that of
the guy at the other of the leech. Arrg.
Ralf
|
Not Categorized, Please Help
|
|
