1. Euphoria Interpreter design
Hello again,
I guess this email is for Rob Craig ...
The single pass design of the Euphoria Interpreter has the draw back that
all procedures / functions have to be defined before usage. I find that
it results in my source code to be poorly organised.
I know you can use "routine_id" but I was wondering ...
How difficult would it be for the Euphoria Interpreter to read the entire
source file and create an "entry point" table before execution begins ...
then procedures and functions could be executed from anywhere.
I imagine this would also force all lines of code to be checked for syntax
errors as well. An added bonus.
Thanks for your time.
Ray Smith
2. Re: Euphoria Interpreter design
- Posted by Daniel Berstein <daber at PAIR.COM>
Feb 22, 1999
-
Last edited Feb 23, 1999
At 08:50 PM 22-02-1999 , you wrote:
>Hello again,
>
>I guess this email is for Rob Craig ...
>
>The single pass design of the Euphoria Interpreter has the draw back that
>all procedures / functions have to be defined before usage. I find that
>it results in my source code to be poorly organised.
Poorly organized? A poorly organized code is what you get when you are free
to declare things wherever you like (VB comes to mind). Euphoria
declare-before-use is one of it strong points. It enhances redability &
conceptual organization.
Regards,
Daniel Berstein
[daber at pair.com]
3. Re: Euphoria Interpreter design
- Posted by Don Groves <groves at ACM.ORG>
Feb 22, 1999
-
Last edited Feb 23, 1999
At 11:50 2/23/99 +1100, Smith Ray wrote:
>Hello again,
>
>I guess this email is for Rob Craig ...
>
>The single pass design of the Euphoria Interpreter has the draw back that
>all procedures / functions have to be defined before usage. I find that
>it results in my source code to be poorly organised.
>
>I know you can use "routine_id" but I was wondering ...
>
>How difficult would it be for the Euphoria Interpreter to read the entire
>source file and create an "entry point" table before execution begins ...
>then procedures and functions could be executed from anywhere.
>
>I imagine this would also force all lines of code to be checked for syntax
>errors as well. An added bonus.
I find that not having forward references *enhances* code
organization, not the reverse. You just have to learn to
read your files from the bottom up 
--
Don Groves
4. Re: Euphoria Interpreter design
>Poorly organized? A poorly organized code is what you get when you are free
>to declare things wherever you like (VB comes to mind). Euphoria
>declare-before-use is one of it strong points. It enhances redability &
>conceptual organization.
I completely disagree. I will give you an example of a program im working on
now.
It has a special 'register' function that registers the routine id of a type
function, its name and an error message.
It would be most clean if these registrations could be done *after* each type
check statement (that makes most sense)
However, Euphoria forces you to order your code differently, because the
registration routine uses those types in its
declaration as well.
type byte (object x)
return integer (x) and x >= 0 and x < 256 -
-- btw this doesnt work, see Robert response/explenation for this
failure in some previous mail.
-- I mean come on Robert, this is obviously a (if not *the*) case where
short-ciruiting makes sence, much more
-- than in while and if-statements. Oh and I will lookup that quote that
you said didnt exist.
end type
global function register (byte x)
-- code
end function
register (routine_id ("byte"), "byte", "An integer value between 0 and 255
is expected.")
But like this, I know off zillions of other examples where linear is not the
cleanest way to code your program.
However, there is an argument that linear programming is by definition more
elegant. (it isnt more powerfull, we'll agree)
That its better to be forced to program 'clean'. But I have seen no prove that
linear programming is the best and most clean
choice for all programs.
And dare I say it, I could order my code *much* better, than how Euphoria forces
me to order my code.
This is why agree (if you want to enforce something), that within an include
file declerations should be linear, but on the
global 'scope' (that is calling routines from *other* include files) there
should be no real order. WHy ? Because often we
havent written and shouldnt be forced to mess with the include files. If two
include files include each other, than both should
be able to call each other. This however is not currently true, what is true, is
that it is very possible that we accidently
calling other global identifers that we did not include. Also do to the linear
programming order. (where *every global
identifer* is accesable from *all* code that follows, including the code that
specified it did not want anything to do with
those identifers.
Ralf
5. Re: Euphoria Interpreter design
Daniel Berstein 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
6. Re: Euphoria Interpreter design
If E works like Pascal or QuickBASIC's
prototype declaration, it would be easier
to program.
7. Re: Euphoria Interpreter design
At 07:09 AM 23-02-1999 , you wrote:
>Daniel Berstein 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
Before studying Computer&Informatic Engineering (that's the best I can
transalate my carrer name), I studyied *5* years of Architecture, and I
*do* know how important analisys and planification is. Before I write a
single line of code I have a master plan (a blueprint)... a conceptual
organization rendered on paper, brought from the untangible world of ideas
to a physical medium. Perhaps some genius programmer espontaneously don't
need any methology... but the rest of us do. Declaring before using oblies
you to think twice before coding. There might be exceptions where this
aproach can lead to some "confusion", but the world is built of rules not
exception.
Regards,
Daniel Berstein
[daber at pair.com]
8. 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
9. Re: Euphoria Interpreter design
[Daniel Berstein]
>Before studying Computer&Informatic Engineering (that's the best I can
>transalate my carrer name), I studyied *5* years of Architecture, and I
>*do* know how important analisys and planification is. Before I write a
>single line of code I have a master plan (a blueprint)... a conceptual
>organization rendered on paper, brought from the untangible world of ideas
>to a physical medium. Perhaps some genius programmer espontaneously don't
>need any methology... but the rest of us do. Declaring before using oblies
>you to think twice before coding. There might be exceptions where this
>aproach can lead to some "confusion", but the world is built of rules not
>exception.
Impressive credentials, but I am not really sure what I am supposed to
do with them (I'll look up 'planification' later on in the privacy of
my own bedroom). If it really helps you to scribble on a piece of
paper before you hit the keyboard, that's ok with me too, we are all
different. Unfortunately, you have not answered my question: how
'declare-before-use' enhances readability & conceptual organization.
But, on the other hand, you introduced me to so many big words, I
should be truly thankful. They might come handy one of those days,
when I run out of real arguments.
[Gabriel Boehme]
Sorry, Gabriel, I'll not quote you in full. It is too long, not enough
substance. But I'll deal with some of the points.
First, if I were in a less charitable mood, I would suggest you tried
to muddy the waters with unrelated garbage: uninitialized variables,
invalid subscripts, invalid parameters and the bad habits we
programmers have learned from other programming languages. But I shall
skip that today...
You also mentioned 'emotional appeals and verbal attacks' a couple of
times. I am not sure what you meant by 'verbal attacks', but I could
recognize the other one when I read, and I quote: "the willy-nilly way
programmers can do things in QB, C or Cobol." All three prohibited
words in a single sentence - it makes me cry.
And to be quite brutal, your pontifications about Euphoria before and
after routine_id() do not help. Your impractical (your word!) example
is even less useful. (BTW, infinite mutual recursion is not such a big
deal - you blow the stack before you blink. Simple infinite loops are
much worse - unbreakable in pure DOS - and they happen far too often
to me...)
I am glad you have not made up your mind, obviously, which way to
jump. But I am confident you will let us know if you ever do.
jiri
10. Re: Euphoria Interpreter design
- Posted by "Boehme, Gabriel" <gboehme at MUSICLAND.COM>
Feb 23, 1999
-
Last edited Feb 24, 1999
Jiri Babor <J.Babor at GNS.CRI.NZ> wrote:
>Sorry, Gabriel, I'll not quote you in full. It is too long, not enough
>substance. But I'll deal with some of the points.
>
>First, if I were in a less charitable mood, I would suggest you tried
>to muddy the waters with unrelated garbage: uninitialized variables,
>invalid subscripts, invalid parameters and the bad habits we
>programmers have learned from other programming languages. But I shall
>skip that today...
Actually, the main point of that first paragraph was to clarify the meaning
of the word "freedom" within the context of a programming language. However,
it probably didn't relate well enough to the rest of my post to justify its
inclusion. Hindsight is usually 20/20. Eventually.
>You also mentioned 'emotional appeals and verbal attacks' a couple of
>times. I am not sure what you meant by 'verbal attacks', but I could
>recognize the other one when I read, and I quote: "the willy-nilly way
>programmers can do things in QB, C or Cobol." All three prohibited
>words in a single sentence - it makes me cry.
Ouch. I hadn't noticed that. I meant the statement as more of a comparison
for reference, but it does indeed come across as an emotional appeal,
doesn't it? "All three prohibited words in a single sentence" -- that's
actually quite a funny observation. :)
As for the phrase "verbal attacks", some of your earlier statements inspired
my use of this phrase. The phrase "verbal attacks" is intended to describe
statements which do not necessarily advance a particular reason or
explanation for a particular viewpoint, but rather make strong, sometimes
angry, emotional statements which may or may not be entirely related to the
issue at hand. These "verbal attacks" usually tend to:
1) attack the person(s) espousing the opposite viewpoint, instead of the
viewpoint itself (i.e. your statement "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.")
2) attack the viewpoint by means of unrelated comparisons, or at least
comparisons which do not make sense in and of themselves, and require
further explanation to make them clear (i.e. "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.")
3) bait the other person(s) by making provocative statements which have
little or nothing to do with the issue (i.e. "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.")
I apologize for being so pedantic, but you did mention that you were not
sure what was meant by the phrase "verbal attacks", and I wanted to make
sure you were clear on what I meant. :)
>And to be quite brutal, your pontifications about Euphoria before and
>after routine_id() do not help.
OHH!! How brutal!!! :)
Seriously, though, I don't know if "pontifications" is necessarily the
correct word. I was simply relating my initial experience with Euphoria, and
how the declare-before-use nature of routine definitions was a definite aid
to my learning experience. I also attempted to state how the introduction of
routine_id() has changed this simplicity, and ultimately how Euphoria *may*
need to be changed to allow forward-declarations in order to reconcile the
existence of routine_id(). I then attempted to detail an example of Euphoria
code which currently works just fine, but which would not work if
forward-declarations were allowed.
>Your impractical (your word!) example
>is even less useful.
It was "impractical" in the sense that it was not something one would
actually use in a real program. But then, many such examples are
"impractical" in this sense, while still being "useful" in the sense of
illustrating the point being made.
>(BTW, infinite mutual recursion is not such a big
>deal - you blow the stack before you blink. Simple infinite loops are
>much worse - unbreakable in pure DOS - and they happen far too often
>to me...)
I never said that infinite mutual recursion was a "big deal" -- again, it
was merely intended to illustrate how code that works perfectly fine in
Euphoria *now*, would have to be rewritten in the event that
forward-declarations are allowed.
>I am glad you have not made up your mind, obviously, which way to
>jump. But I am confident you will let us know if you ever do.
I promise, you'll be the first to know. :)
Gabriel Boehme
11. Re: Euphoria Interpreter design
- Posted by Daniel Berstein <daber at PAIR.COM>
Feb 23, 1999
-
Last edited Feb 24, 1999
At 08:28 PM 23-02-1999 , you wrote:
>Impressive credentials, but I am not really sure what I am supposed to
>do with them (I'll look up 'planification' later on in the privacy of
>my own bedroom). If it really helps you to scribble on a piece of
>paper before you hit the keyboard, that's ok with me too, we are all
>different. Unfortunately, you have not answered my question: how
>'declare-before-use' enhances readability & conceptual organization.
>But, on the other hand, you introduced me to so many big words, I
>should be truly thankful. They might come handy one of those days,
>when I run out of real arguments.
I know you're not flaming me Jiri, this is your style ;)
I'm sorry if my English isn't perfect, I'm a native spanish speaker.
Anyways, I still think declare-before-use improves code redability and
promotes conceptual clarity (think-before-code). And as someone else said:
it's easier to understand (and modify) other developers code when
declarations are before their use.
BTW Why don't you prove 'declare-before-use' doesn't enhance readability &
conceptual organization?
Regards,
Daniel Berstein
[daber at pair.com]
12. Re: Euphoria Interpreter design
Gabriel,
I take your points about 'verbal attacks', but in fairness to me (who
else? - since I was already called 'plain silly', 'out of my mind',
'senile old man' etc right here, in the last few months) I must say
you lack the historical perspective, so to speak. We have a group of
people on the list, I call them 'the defenders of the faith', who jump
up and protest vehemently every time anybody is brave enough to
suggest anything new or unusual. As a rule, they are not to be
bothered by the real issues, all they are interested in is the comfort
of the status quo. And their catch-cry is, almost invariably, yes, you
guess it, readability...
Btw, I do not think, Daniel quite fits into that category, he just
exhibits one or two alarming symptoms... Sorry, Daniel, I was too
harsh. jiri
13. Re: Euphoria Interpreter design
>Before studying Computer&Informatic Engineering (that's the best I can
>transalate my carrer name), I studyied *5* years of Architecture, and I
>*do* know how important analisys and planification is. Before I write a
>single line of code I have a master plan (a blueprint)... a conceptual
>organization rendered on paper, brought from the untangible world of ideas
>to a physical medium. Perhaps some genius programmer espontaneously don't
>need any methology... but the rest of us do. Declaring before using oblies
>you to think twice before coding. There might be exceptions where this
>aproach can lead to some "confusion", but the world is built of rules not
>exception.
Daniel, daniel. What you say would be true *if* a declare-before-you-use kind of
order (a linear order) would be proven to be
better readable.
But many cases it is much more readable and handable in my own order. How do I
know this ? Because I also think about it, david.
I just dont need a leech to stop me from crossing the street withouth looking. I
will look for myself, but might cross the
street at another point that the guy at the leech would.
Ralf
14. 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
15. Re: Euphoria Interpreter design
>I'm sorry if my English isn't perfect, I'm a native spanish speaker.
>Anyways, I still think declare-before-use improves code redability and
>promotes conceptual clarity (think-before-code). And as someone else said:
>it's easier to understand (and modify) other developers code when
>declarations are before their use.
I disagree, very simple mutal recursive algoritms (not to mention code and
routine management) generate much simplier and more
readable code, that the mess we make trying to 'fit' such a thing into a linear
order.
>BTW Why don't you prove 'declare-before-use' doesn't enhance readability &
>conceptual organization?
Daniel, why dont you tell me: did I not give an example in a previous mail ?
Plus, I think I can send you about 2 or 3 old projects that have such issues.
But any one programming any complex system, will
have had its own experience with this restriction. I know I have.
However, btw, theoretically your quesiton above is also irrelevant. I have to
disprove the readability of linear ordening ?
No, you would mean I have to disprove the readablity of linear ordening in some
case, while you have to prove that its *always*
the most readable choice.
Ralf
16. Re: Euphoria Interpreter design
>And dare I say it, again, I can order a program much better (much more
>logical) that Euphoria could ever force me (or you).
Ok, how would that be? Here's the way I try to order my programs:
includes
constants
types WOULD go here... :)
globals
lowest-level routines
low-level routines
mid-level routines
high-level routines
highest-level routines
main routine
Sometimes some constants come after globals (ie a sin and cos lookup table
is faster as a constant, but I need a temp variable to store it until I
assign it to the consant), but overall this works. If I want a low-level
routine, like drawing the status bar, I look near the top of my code.
(Actually, I should look in an include file... oh well.) I know that the
low-level routines can't call the main routine, etc. Euphoria's way of doing
things currently has not hindered me at all, but hasn't particularly helped
me, either.
Now, I'm not saying your way is bad, I just want to see it so I can want to
use it, too.
17. Re: Euphoria Interpreter design
At 02:59 AM 24-02-1999 , you wrote:
>>BTW Why don't you prove 'declare-before-use' doesn't enhance readability &
>>conceptual organization?
>Daniel, why dont you tell me: did I not give an example in a previous mail ?
>Plus, I think I can send you about 2 or 3 old projects that have such
issues. But any one programming any complex system, will
>have had its own experience with this restriction. I know I have.
>
>However, btw, theoretically your quesiton above is also irrelevant. I have
to disprove the readability of linear ordening ?
>No, you would mean I have to disprove the readablity of linear ordening in
some case, while you have to prove that its *always*
>the most readable choice.
Hi Ralf.
The question was supposed to be answered by Jiri. Sorry, but a couple of
particular examples ain't a proof. I want Jiri to proof (logicaly,
mathematically) that declare-before-use is bad for your eyes and your brain ;)
BTW Thanks for not completly including me in the 'the defenders of the
faith' category, mr. Obiwan Kenobi :)
Regards,
Daniel Berstein
[daber at pair.com]
18. Re: Euphoria Interpreter design
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Feb 24, 1999
-
Last edited Feb 25, 1999
>>And dare I say it, again, I can order a program much better (much more
>>logical) that Euphoria could ever force me (or you).
>
>Ok, how would that be? Here's the way I try to order my programs:
Well, Ive attached a couple of projects to a person mail.
Try to consider such projects in your order scheme and feel free to respond on
the list-sever.
(I just didnt want to puke my attachments all over the list-server..)
But sometimes 'subject' is an order as well.
Say, File IO - constants, routines, and other declerations packed together.
String manipulation routines packed together,
key-association routines packed together.
In such an order, its order, not in *how* it is implemented
(type/constant/routine) but *what* it relates to and *what* it does.
How the interpreter handles and orders it.. that its own case.
>Sometimes some constants come after globals (ie a sin and cos lookup table
>is faster as a constant, but I need a temp variable to store it until I
>assign it to the consant), but overall this works. If I want a low-level
>routine, like drawing the status bar, I look near the top of my code.
>(Actually, I should look in an include file... oh well.) I know that the
>low-level routines can't call the main routine, etc. Euphoria's way of doing
>things currently has not hindered me at all, but hasn't particularly helped
>me, either.
I havent even began to give some serieus examples of things that just dont work,
without modifying external libraries.
I once tried to make a sort of 'basic' api / say standard for general purpose
graphics library, in such way you would only have
to write a modeX specific library contain some declerations and a few routines,
but the end-program wouldnt know the difference.
Palettes, virtual screens manager, graphical output, etc. were all different
include files. That all followed a certain standard
(and use one general library that manages all the registrations of routines and
machine code). The whole thing had to be OO.
There was simply no 'elegant' way, to have the parts interact this way. Since,
there had to be some logical order. What comes
first, the graphical output ? the palette ? the dos-font ? etc.
Actually the order would be different for each configuration. Never found a
clean way.
Then Pete came out wiht his magic library, that simply supported all modes and
types, and handled all that. It had no point for
me to continue. Im suprised though, that I never seen many games and demos use
Neil.
>Now, I'm not saying your way is bad, I just want to see it so I can want to
>use it, too.
Order is not fixed. Its depends on what you do. But why, could some one, tell me
why, linear order is the best choice for *all*
situations. If its not, the restriction has to go. So you could choose to force
linear, rather than being forced to.
Oh, and for all those that didnt get me, when I used the word 'leech' .. eh.. I
meant leash. (thank you David).
Ralf
19. Re: Euphoria Interpreter design
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Feb 24, 1999
-
Last edited Feb 25, 1999
>>Daniel, why dont you tell me: did I not give an example in a previous mail ?
>>Plus, I think I can send you about 2 or 3 old projects that have such
>issues. But any one programming any complex system, will
>>have had its own experience with this restriction. I know I have.
>>
>>However, btw, theoretically your quesiton above is also irrelevant. I have
>to disprove the readability of linear ordening ?
>>No, you would mean I have to disprove the readablity of linear ordening in
>some case, while you have to prove that its *always*
>>the most readable choice.
>
>The question was supposed to be answered by Jiri. Sorry, but a couple of
>particular examples ain't a proof. I want Jiri to proof (logicaly,
>mathematically) that declare-before-use is bad for your eyes and your brain ;)
He doesnt have to proof it is bad. He (or any one else, persons should not
be association to opinions in a discussion) has
to prove that there is at least *one* case, where not linear order would be
slightly better, and it is proven we're better
without than with the restriction.
>BTW Thanks for not completly including me in the 'the defenders of the
>faith' category, mr. Obiwan Kenobi :)
Huh ? Did I miss that ?
Ralf
20. Re: Euphoria Interpreter design
Ralf writes (regarding "define-it-before-you-use-it")
> He doesnt have to proof it is bad. He (or any one else, persons
> should not be association to opinions in a discussion) has
> to prove that there is at least *one* case, where not linear order
> would be slightly better, and it is proven we're better without
> than with the restriction.
I hate to sound like a lawyer Ralf, but I think the burden of proof
is much higher than what you propose.
I'm *sure* there are many cases where some programmer-defined
order will be "better". The point is that Euphoria's
define-it-before-you-use-it order is *machine-verified*.
A arbitrary order invented for each program by an artistic
programmer is *not* verifiable, and therefore can't be trusted
to have any consistency, by others, or (eventually) even by
the programmer himself.
Knowing that define-it-before-you-use-it is *enforced* for all
Euphoria programs, makes it easier to understand and maintain
other people's code, and probably your own as well.
The routine_id mechanism lets you call things that come later,
but you can clearly see in the code that a special call
(call_proc, call_func) is being made, so you are alerted to
what is going on. A user-defined symbol can never appear
in the source code before it is declared.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
21. Re: Euphoria Interpreter design
>I'm *sure* there are many cases where some programmer-defined
>order will be "better". The point is that Euphoria's
>define-it-before-you-use-it order is *machine-verified*.
>A arbitrary order invented for each program by an artistic
>programmer is *not* verifiable, and therefore can't be trusted
>to have any consistency, by others, or (eventually) even by
>the programmer himself.
I agree, that often the define-it-before-you-use-it order is the nicest. Im just
questioning the need for a full and consistent
restriction.
Like I said before, within in include file, it would often be the cleanest to
maintain such a linear order (I would), but
considering include file A and include file B, which include each other. I think
they should be able to use each other's code.
First of all, the programmers is not certain of the order anymore, since its in
seperate files, secondly: an include file is an
'individual' part of your program. You seperate such parts so they can work
independently. So you can debug them independently.
As long as the interface through global identifers remains the same, the rest of
the program is able to use it as intented,
while internally much can be changed. The whole idea behind an include file. But
linear order removes part of that 'independent'
freedom of an include file. What an other include file has already included and
in which order, can have an influence on which
routines are called and used and possible conflicting as well. I dont think we
should be able to change *anything* for an
include file, except when it *lets us* by using its global identifers.
If you want to maintain the restriction, and I do understand the arguments to
that choice, at least looses it up *somewhere*.
Like considering multiple include files. I can give examples of projects were I
had different parts that had to mutally call/use
each other. I could get them to work, using routine-id's, but then I would need
to modify both parts seperately for this special
exception. And when both libraries are meant as api's, its just much more
elegant if you would be able to acces them (and their
constants and other identfers) the way it was intented withouth some weird hack
that (your words) alerts us.
>Knowing that define-it-before-you-use-it is *enforced* for all
>Euphoria programs, makes it easier to understand and maintain
>other people's code, and probably your own as well.
>The routine_id mechanism lets you call things that come later,
>but you can clearly see in the code that a special call
>(call_proc, call_func) is being made, so you are alerted to
>what is going on. A user-defined symbol can never appear
>in the source code before it is declared.
Btw, Robert, considering this, wouldnt it be able to routine_id () a global or
local variable and/or constant and have it work
like a function (with zero arguments) ?
Nevertheless, im not convinced. I still want mutally callable include files. I
dont mind a forced linear order *within* the
include file. (local scope only thus).
Ralf
22. Re: Euphoria Interpreter design
First. Off the subject and out of the way. I like the online listserv's
Cute buttons but I wish that they also had text to let you know what button
does what. Not everyone knows to look at the status bar.
NOW: My on subject message is simple. THANK YOU ROB.
I agree. There are many cases where define-it-before-you-use-it
is a problem, a burden, a real annoyance, a trouble maker, a pain
in the tush. But, It makes it much easier to read SOMEBODY ELSES
CODE, AND your own code many months or years down the road.
I also agree that routine_id() is a very dirty way to get around
the burden of define-it-before-you-use-it. But, I again agree with
Rob, It alerts later code readers that they are dealing with code
that doesn't fully fall under the define-it-before-you-use-it law.
Better design: I know that it would break some code. (IE: probably
Neil.) But, I hate the ability to redifine built_ins. I just hate
the idea of being able to redefine functions/procedures all together.
I feel that it (muddies the water) makes the code difficult to follow.
Code Example:
without warning--HIDE the fact that I'm screwing with someones mind.
function getc(object faked)
faked = faked--Pretend to use the input
return rand(257) - 2
end function
with warning
Now you have completely destroyed what getc() is suppose to do.
What is expected to happen, doesn't happen. I realize that the
idea is to allow programmers to do some behind the scenes magic
so that the code runs ENHANCED (faster, cleaner, and/or more flexible).
I also feel that routine_id() should be able to used on built-ins.
As of right now the only way to do that is by doing the NO-NO above
(redefining the built-in).
Code Example:
without warning--HIDE the fact that I'm screwing with someones mind.
function getc(object temp)
return getc(temp)
end function
with warning
--getc() is now redefined so that routine_id() will work.
I see this nonsense as a (Kludge, foobar, NO-NO, bad design).
Lucius L. Hilley III
Just my $0.04 worth. Sorry I overpaid 8^)
On Wed, 24 Feb 1999 15:28:21 -0500, Robert Craig <rds at ATTCANADA.NET> wrote:
>Ralf writes (regarding "define-it-before-you-use-it")
>> He doesnt have to proof it is bad. He (or any one else, persons
>> should not be association to opinions in a discussion) has
>> to prove that there is at least *one* case, where not linear order
>> would be slightly better, and it is proven we're better without
>> than with the restriction.
>
>I hate to sound like a lawyer Ralf, but I think the burden of proof
>is much higher than what you propose.
>
>I'm *sure* there are many cases where some programmer-defined
>order will be "better". The point is that Euphoria's
>define-it-before-you-use-it order is *machine-verified*.
>A arbitrary order invented for each program by an artistic
>programmer is *not* verifiable, and therefore can't be trusted
>to have any consistency, by others, or (eventually) even by
>the programmer himself.
>
>Knowing that define-it-before-you-use-it is *enforced* for all
>Euphoria programs, makes it easier to understand and maintain
>other people's code, and probably your own as well.
>
>The routine_id mechanism lets you call things that come later,
>but you can clearly see in the code that a special call
>(call_proc, call_func) is being made, so you are alerted to
>what is going on. A user-defined symbol can never appear
>in the source code before it is declared.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://members.aol.com/FilesEu/
23. Re: Euphoria Interpreter design
On Thu, 25 Feb 1999 07:35:28 +0100, Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
wrote:
>
>Btw, Robert, considering this, wouldnt it be able to routine_id () a
global or local variable and/or constant and have it work
>like a function (with zero arguments) ?
>
>Nevertheless, im not convinced. I still want mutally callable include
files. I dont mind a forced linear order *within* the
>include file. (local scope only thus).
>
>Ralf
I agree here. I don't feel this is an issue of define-it-before-you-use-it.
I feel this is a scope issue that should have been cleared up long ago.
IE:
-- image.e --
include graphics.e
--CODE
-- MyProgram --
include custom.e
include image.e
--image.e has access to custom.e global routines, variables and constants.
--ALSO
-- MyProgram has access to all of graphics.e global routines and variables.
I feel that image.e should not have access to custom.e globals
I also feel that I MyProgram should not have access to graphics.e globals.
This is clearly and issue of scope. I feel that access to globals of an
include file should only be available to the code that implicitly included
the file.
Lucius L. Hilley
24. Re: Euphoria Interpreter design
While I see the validity of the argument, I've got a couple of minor =
concerns...
How about adding a new scope level entirely, "inclusive"? An inclusive =
constant/variable/routine would be available:
-- within the file, similar to local
-- within any other file that *specifically* chooses to include the =
file
-- NOT within any other files that do not *specifically* include the =
file
It seems to match the kind of modified-global scope that's most wanted.
I suggest this only because I'm not quite sure that the global scope =
should be tossed out completely, and the identifier "global" bests suits =
the declaration of that scope. (However, I admit that once an =
"inclusive" scope were introduced, it would seriously diminish the role =
of the global scope; I suppose the global scope would then not even =
*really* be needed. But even if it were eliminated, I would prefer the =
new scope to have a name change. "global" should mean global.)
As to the mutually-callable include files... I've run into problems =
there myself; I don't see how a scope change addresses it though. Even =
if it fit the example below, the new scope wouldn't necessarily have to =
allow mutual inclusion--if that were the case, the global scope should =
be able to do it. I would think that mutual inclusion isn't allowed =
soley to enforce declare-before-use, not as a side effect of the current =
global scope rules.
I haven't decided yet if I want to see a break in the declare-before-use =
design in order to allow mutual inclusion, or for any other reason... =
both positions have strong points.
Rod Jackson
----------
From: Lucius Hilley III[SMTP:lhilley at CDC.NET]
Sent: Thursday, February 25, 1999 2:18 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Euphoria Interpreter design
On Thu, 25 Feb 1999 07:35:28 +0100, Ralf Nieuwenhuijsen =
<nieuwen at XS4ALL.NL>
wrote:
>
>Btw, Robert, considering this, wouldnt it be able to routine_id () a
global or local variable and/or constant and have it work
>like a function (with zero arguments) ?
>
>Nevertheless, im not convinced. I still want mutally callable include
files. I dont mind a forced linear order *within* the
>include file. (local scope only thus).
>
>Ralf
I agree here. I don't feel this is an issue of =
define-it-before-you-use-it.
I feel this is a scope issue that should have been cleared up long ago.
IE:
-- image.e --
include graphics.e
--CODE
-- MyProgram --
include custom.e
include image.e
--image.e has access to custom.e global routines, variables and =
constants.
--ALSO
-- MyProgram has access to all of graphics.e global routines and =
variables.
I feel that image.e should not have access to custom.e globals
I also feel that I MyProgram should not have access to graphics.e =
globals.
This is clearly and issue of scope. I feel that access to globals of an
include file should only be available to the code that implicitly =
included
the file.
Lucius L. Hilley
25. Re: Euphoria Interpreter design
You wrote
<<<First. Off the subject and out of the way. I like the online listserv's
<<<Cute buttons but I wish that they also had text to let you know what
<<<button
<<<does what. Not everyone knows to look at the status bar.
If you hold your mouse cursor over abutton a text message will appear.
just like window hints
Bernie
26. Re: Euphoria Interpreter design
On Thu, 25 Feb 1999 16:17:43 -0500, Bernie Ryan <bwryan at PCOM.NET> wrote:
>You wrote
><<<First. Off the subject and out of the way. I like the online
listserv's
><<<Cute buttons but I wish that they also had text to let you know what
><<<button
><<<does what. Not everyone knows to look at the status bar.
>
>If you hold your mouse cursor over abutton a text message will appear.
>just like window hints
>
>Bernie
I now have the understanding that you are running Internet Explorer.
Otherwise you would realize that Netscape QUICKLY hides Alt text with
the intended image. As of Navigator 3.04 Netscape did not display the
ALT text when hovered over. If Communicator changed that, GOOD. But
if not then. TEXT under or on the Button images would be NICE. 8^)
Lucius L. Hilley III
27. Re: Euphoria Interpreter design
>As to the mutually-callable include files... I've run into problems there
>myself; I don't see how a scope change addresses it
though. Even if it fit the >example below, the new scope wouldn't necessarily
have to allow mutual inclusion--if that were the
case, the global scope should be able to do it. I >would think that mutual
inclusion isn't allowed soley to enforce
declare-before-use, not as a side effect of the current global scope rules.
Mutual inclusion wouldnt be able with the current scope or it would mean, that
when you define something 'globally' in your
file, its also mutually accesable from within that file. Something it appears
almost nobody wants. But I do want mutual
inclusion is such way its routines can mutually call the routines of the files
it includes. If you include it, it should appear
as if the code was included at that point. Without that, include files are not
more than an illusion of seperate parts of your
program. You should simply not be able to modify what the include file sees,
unless by modifying things it actually included.
Thats the real and whole concept behind 'seperate' part of code, the idealogy
behind an include file, I hope.
> haven't decided yet if I want to see a break in the declare-before-use design
> in order to allow mutual inclusion, or for any
other reason... both >positions have strong points.
Surely, I understand the points of linear order *within* an include file, but Im
extremely curious how many of those points hold
up when include files are the issue.. eh.. none.
Rod Jackson
----------
From: Lucius Hilley III[SMTP:lhilley at CDC.NET]
Sent: Thursday, February 25, 1999 2:18 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Euphoria Interpreter design
On Thu, 25 Feb 1999 07:35:28 +0100, Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
wrote:
>
>Btw, Robert, considering this, wouldnt it be able to routine_id () a
global or local variable and/or constant and have it work
>like a function (with zero arguments) ?
>
>Nevertheless, im not convinced. I still want mutally callable include
files. I dont mind a forced linear order *within* the
>include file. (local scope only thus).
>
>Ralf
I agree here. I don't feel this is an issue of define-it-before-you-use-it.
I feel this is a scope issue that should have been cleared up long ago.
IE:
-- image.e --
include graphics.e
--CODE
-- MyProgram --
include custom.e
include image.e
--image.e has access to custom.e global routines, variables and constants.
--ALSO
-- MyProgram has access to all of graphics.e global routines and variables.
I feel that image.e should not have access to custom.e globals
I also feel that I MyProgram should not have access to graphics.e globals.
This is clearly and issue of scope. I feel that access to globals of an
include file should only be available to the code that implicitly included
the file.
Lucius L. Hilley
