1. Eu's poor design
Lets face it, at its current state, Euphoria is rather useless for
programming real applications, for several reasons:
It lacks:
- Call by reference (the most important feature I want to add!):
Some say, it isn't needed in Eu, because you can simply return
a sequence. Yes, that's true. But apart from being tedious to type,
it makes the code much less efficient.
example:
seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
So for real applications I would use global variables all over the place
(like the other Eu programmers do). (Great improvement over call by
reference!)
(The reason why call by reference is missing is probably because Rob
didn't understand functional programming properly. Hey Rob, Euphoria is
no functional language! If you wanted to make a functional programming
language, why did you implement variables and loops? Recursion &
constants would do.)
- Block comments: While they are not essential, it is really dump
to put "--" before any line if I just want to comment out some code for
a short period time. Apart from that, line comments (though being very
useful!) are really inconsequent: If line endings are not important for
the Eu interpreter why are comments/include statements different? And
why use -- for line comments when # would do (#! is allowed in the first
line for linux compability anyway!)?
By the way, the scanner should not be line-based for Euphoria (although
Rob probably did it this way - nobody knows why, it doesn't make much
sense), so block comments are NOT harder to scan than line comments!
But there are other drawbacks:
allocate() and free() ??? I thought Euphoria had a garbage collector!
If Euphoria is intended for programming newbies, why is Euphoria case
sensitive? (Why are so many languages case sensitive by the way? That
way I have to remember exactly how the identifier was being written!)
I used to use hashing a lot. Guess what, in Euphoria most hash functions
can't be implemented (or only with poor performance!), because integers
don't wrap around but are converted to floating point when they get to
big!
This is really annoying because Euphoria is a great language full of
good ideas. I like it for small scripting tasks, but it is simply not
suited well for bigger programming tasks.
2. Re: Eu's poor design
- Posted by eugtk at yahoo.com
Aug 16, 2003
--- Andreas Rumpf <pfropfen at gmx.net> wrote:
> Lets face it, at its current state, Euphoria is
> rather useless for
> programming real applications, for several reasons:
Clearly, it's been useless for you. I don't see your
name in
a search of the user-contributions page. There are
lots
of others there, however.
Just one example: take a look at Judith's IDE. That,
with the Win32Lib, is easier to use, and more stable,
than my $100 copy of Delphi. I'd say that Delphi is
a real application - so I guess Judith's is also.
> It lacks:
> - Call by reference (the most important feature I
> want to add!):
Last time this subject came up, I took a look (with
grep) thru the million or so lines of code I have
written in the past 20 years - in only half a dozen
places have I used call-by-reference. And in those,
only one would I call "essential" - meaning that
without it, the code would have been really ugly.
Would I like to have cbr? Sure.
Is it essential? No way.
It ranks just above goto on my wish list (sorry, Kat)
As for case sensitivity -
What you learned in QBasic doesn't apply to the real
world. (Hint: there's a reason why those 'other'
languages are also case sensitive.)
Besides, anyone who can't remember how he spelled a
variable is going to find the more complex programming
tasks even more frustrating.
Irv
3. Re: Eu's poor design
Hi Andreas,
You wrote:
> If you wanted to make a functional programming
> language, why did you implement variables and loops? Recursion &
> constants would do.
...but then you wrote...
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive? (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
You seem to be criticizing the use of loops and variables (as opposed to
recursion), yet you also seem to complain that Eu's case sensitivity is not
good for programming newbies. Recursion is a much more difficult concept
to anyone, including newbie programmers. It is also much more difficult to
make changes to, and just not intuitive for most people. My point is that
you seem to be making arguments from two opposing views here.
By the way, I am not crazy about case sensitivity, either, be it in Unix,
Linux, etc., or Euphoria or Perl. It's just something I don't like but
have just accepted as something I have to deal with until I write my own
OS/language. :)
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time.
I completely agree that block comments would be a great addition. They
should already be available in Eu, and should be added. I disagree about
the '--' as a comment indicator. Basically, who cares? This is a really
minor point of Eu syntax and is not worth arguing about. As in, is "for
i=1 to 10 do" better than "for (i=1;i+=1;i<11) {"? I'd say no, they're
just different. You might as well argue over who is better, King Kong or
Godzilla. (Though Kong obviously is.)
Ted
--On Saturday, August 16, 2003 11:47 AM +0000 Andreas Rumpf
<pfropfen at gmx.net> wrote:
>
>
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
> It lacks:
> - Call by reference (the most important feature I want to add!):
> Some say, it isn't needed in Eu, because you can simply return
> a sequence. Yes, that's true. But apart from being tedious to type,
> it makes the code much less efficient.
> example:
> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
>
> So for real applications I would use global variables all over the place
> (like the other Eu programmers do). (Great improvement over call by
> reference!)
>
> (The reason why call by reference is missing is probably because Rob
> didn't understand functional programming properly. Hey Rob, Euphoria is
> no functional language! If you wanted to make a functional programming
> language, why did you implement variables and loops? Recursion &
> constants would do.)
>
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time. Apart from that, line comments (though being very
> useful!) are really inconsequent: If line endings are not important for
> the Eu interpreter why are comments/include statements different? And
> why use -- for line comments when # would do (#! is allowed in the first
> line for linux compability anyway!)?
> By the way, the scanner should not be line-based for Euphoria (although
> Rob probably did it this way - nobody knows why, it doesn't make much
> sense), so block comments are NOT harder to scan than line comments!
>
> But there are other drawbacks:
> allocate() and free() ??? I thought Euphoria had a garbage collector!
>
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive? (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
>
> I used to use hashing a lot. Guess what, in Euphoria most hash functions
> can't be implemented (or only with poor performance!), because integers
> don't wrap around but are converted to floating point when they get to
> big!
>
>
> This is really annoying because Euphoria is a great language full of
> good ideas. I like it for small scripting tasks, but it is simply not
> suited well for bigger programming tasks.
>
> --^----------------------------------------------------------------
> This email was sent to: fines at macalester.edu
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
4. Re: Eu's poor design
Peter Willems wrote:
> Hello Andreas,
>
> Although I have decided against Euphoria (currently) as a viable
> option for professional development, I have some remarks to make
> here.....
>
> Andreas Rumpf wrote:
>>
>> Lets face it, at its current state, Euphoria is rather useless for
>> programming real applications, for several reasons:
>
> I do agree that it is not there yet, but for different reasons.
>
>> It lacks:
>> - Call by reference (the most important feature I want to add!):
>> Some say, it isn't needed in Eu, because you can simply return
>> a sequence. Yes, that's true. But apart from being tedious to type,
>> it makes the code much less efficient.
>> example:
>> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
>
> OK, but.....
>
>> So for real applications I would use global variables all over the place
>>
>> (like the other Eu programmers do). (Great improvement over call by
>> reference!)
>
> If that is a great aprovement over "call by reference" then why
> do you need "call by reference. Your stament is confusing.
I suppose, he meant it ironically. 
<snip>
Best regards,
Juergen
--
/"\ ASCII ribbon campain | "Everything should be made as simple
\ / against HTML in | as possible, but not simpler."
X e-mail and news, |
/ \ and unneeded MIME | [Albert Einstein]
5. Re: Eu's poor design
Andreas Rumpf wrote:
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
> It lacks:
> - Call by reference (the most important feature I want to add!):
> Some say, it isn't needed in Eu, because you can simply return
> a sequence. Yes, that's true. But apart from being tedious to type,
> it makes the code much less efficient.
> example:
> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
>
> So for real applications I would use global variables all over the place
> (like the other Eu programmers do). (Great improvement over call by
> reference!)
>
> (The reason why call by reference is missing is probably because Rob
> didn't understand functional programming properly. Hey Rob, Euphoria is
> no functional language! If you wanted to make a functional programming
> language, why did you implement variables and loops? Recursion &
> constants would do.)
I also would like to have Call by Reference, but the lack of it doesn't
mean, that "Euphoria is rather useless for programming real applications".
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time. Apart from that, line comments (though being very
> useful!) are really inconsequent: If line endings are not important for
> the Eu interpreter why are comments/include statements different? And
> why use -- for line comments when # would do (#! is allowed in the first
> line for linux compability anyway!)?
> By the way, the scanner should not be line-based for Euphoria (although
> Rob probably did it this way - nobody knows why, it doesn't make much
> sense), so block comments are NOT harder to scan than line comments!
Because of the lack of Block Comments, "Euphoria is rather useless for
programming real applications"??? Maybe you should look for a good
editor, that can handle line comments comfortable.
> But there are other drawbacks:
> allocate() and free() ??? I thought Euphoria had a garbage collector!
Maybe this wouldn't be necessary theoretically, I don't know.
But where is the problem using it?
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive?
Is there an unwritten law, that case sensitivity isn't good for
programming newbies?
> (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
Case sensitivity increases the number of possibilities we have, for
creating names of routines, constants and variables. I like that.
<snip>
Sorry, but nothing that you wrote, is an argument, why "Euphoria is
rather useless for programming real applications".
Regards,
Juergen
--
/"\ ASCII ribbon campain | "Everything should be made as simple
\ / against HTML in | as possible, but not simpler."
X e-mail and news, |
/ \ and unneeded MIME | [Albert Einstein]
6. Re: Eu's poor design
On Sat, Aug 16, 2003 at 11:47:14AM +0000, Andreas Rumpf wrote:
>
>
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
> It lacks:
> - Call by reference (the most important feature I want to add!):
> Some say, it isn't needed in Eu, because you can simply return
> a sequence. Yes, that's true. But apart from being tedious to type,
> it makes the code much less efficient.
> example:
> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
We have call by reference, of sorts. Via routine_id().
Also, for emulation of pass by reference:
global sequence x
...initialize x here...
procudure g(integer i, object v)
? x[i]
x[i] = v
end procedure
integer z
z = 5
x[z] = "hi"
g(z, "bye")
? x[z]
which is ugly, but still possible.
>
> So for real applications I would use global variables all over the place
> (like the other Eu programmers do). (Great improvement over call by
> reference!)
>
> (The reason why call by reference is missing is probably because Rob
> didn't understand functional programming properly. Hey Rob, Euphoria is
> no functional language! If you wanted to make a functional programming
> language, why did you implement variables and loops? Recursion &
> constants would do.)
>
Are you against variables and loops then?
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time. Apart from that, line comments (though being very
> useful!) are really inconsequent: If line endings are not important for
> the Eu interpreter why are comments/include statements different? And
> why use -- for line comments when # would do (#! is allowed in the first
> line for linux compability anyway!)?
What is used as the comment character is a minor detail.
Also, # is used for hexidecimal in Euphoria.
> By the way, the scanner should not be line-based for Euphoria (although
> Rob probably did it this way - nobody knows why, it doesn't make much
> sense), so block comments are NOT harder to scan than line comments!
>
> But there are other drawbacks:
> allocate() and free() ??? I thought Euphoria had a garbage collector!
These are for low level programming (i.e. interfacing with the OS
or with C routines in .dll or .so files). They aren't meant for use in
pure Eu programming but when mixing with elements outside of your program
(such as a third party dll file written in C).
>
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive? (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
>
If a person cant be case sensitive that person will have big problems
being a programmer, period.
> I used to use hashing a lot. Guess what, in Euphoria most hash functions
> can't be implemented (or only with poor performance!), because integers
> don't wrap around but are converted to floating point when they get to
> big!
>
>
Yes, that is annoying. But, that is actually a newbie friendly function!
Also, doesnt use of the 'integer' type prevent this? Since its
never a floating point number...
> This is really annoying because Euphoria is a great language full of
> good ideas. I like it for small scripting tasks, but it is simply not
> suited well for bigger programming tasks.
Well, it can be, but it would be cumbersome to use in many cases due to a
lot of missing pieces.
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
7. Re: Eu's poor design
Andreas Rumpf wrote:
> eugtk at yahoo.com wrote:
<snip>
>>> It lacks:
>>> - Call by reference (the most important feature I
>>> want to add!):
>>
>> Last time this subject came up, I took a look (with
>> grep) thru the million or so lines of code I have
>> written in the past 20 years - in only half a dozen
>> places have I used call-by-reference. And in those,
>> only one would I call "essential" - meaning that
>> without it, the code would have been really ugly.
>
> I don't believe you. That would mean you have written
> millions of lines in Eu (because all the other languages
> have it). I doubt it.
Someone who is able to read, and is able to think logically,
has clearly got an advantage ...
<rest graciously snipped>
Regards,
Juergen
--
Q: So would you say you've learned from your mistakes?
A: Oh yes, I'm sure that I could repeat them exactly.
8. Re: Eu's poor design
- Posted by kbochert at copper.net
Aug 16, 2003
On 16 Aug 2003 at 11:47, Andreas Rumpf wrote:
>
>
> Lets face it, at its current state, Euphoria is rather useless for
> programming real applications, for several reasons:
> It lacks:
> - Call by reference (the most important feature I want to add!):
> Some say, it isn't needed in Eu, because you can simply return
> a sequence. Yes, that's true. But apart from being tedious to type,
> it makes the code much less efficient.
> example:
> seq[2][3][5] = func(seq[2][3][5]) -- this is just stupid
>
I think passing arguments by value is simpler and sometimes less
surprising.
Bach takes a middle road -- variables are still passed by value, but classes
(structures) are passed by reference. So you get lines like:
sub_payment (cust.acct.balance, pay.amount)
I can't really see how anyone puts up with not having this kind of thing!
>
> - Block comments: While they are not essential, it is really dump
> to put "--" before any line if I just want to comment out some code for
> a short period time.
Block comments are not necessary!! while loops are purely superfluous!
and whats with 'exit' ?? a needless frill (and non-structured)
And don't get me started about '+=', '-=' etc.
My experience teaches me that block comments are very important.
They allow the programmer to enter comments which have a
different emphasis, allowing cleaner documentation (of little concern
to the Eu community, I admit )
An editor can colorize them differently to enhance the difference.
They tell the reader that a block of comments is what is intended,
as opposed to individual comments that just happen to be adjacent.
Documentation is the hardest part of programming. The more tools
to help the better.
Apart from that, line comments (though being very
> useful!) are really inconsequent: If line endings are not important for
> the Eu interpreter why are comments/include statements different? And
> why use -- for line comments when # would do (#! is allowed in the first
> line for linux compability anyway!)?
> By the way, the scanner should not be line-based for Euphoria (although
> Rob probably did it this way - nobody knows why, it doesn't make much
> sense), so block comments are NOT harder to scan than line comments!
>
Adding block comments is extremely easy, line-orientation or no.
> But there are other drawbacks:
> allocate() and free() ??? I thought Euphoria had a garbage collector!
>
> If Euphoria is intended for programming newbies, why is Euphoria case
> sensitive? (Why are so many languages case sensitive by the way? That
> way I have to remember exactly how the identifier was being written!)
>
Because "count" and "COUNT" are different symbols (They look different
don't they?)
>
> This is really annoying because Euphoria is a great language full of
> good ideas. I like it for small scripting tasks, but it is simply not
> suited well for bigger programming tasks.
>
I think of Bach as being for small to medium sized tasks, and it has
features designed to handle bigger tasks.
Karl Bochert
9. Re: Eu's poor design
Andreas Rumpf wrote:
> Peter Willems wrote:
[Call by Reference]
>> And the lack of such an option doesn't mean you can't write
>> serious or professional applications with it.
> Well, agreed, you CAN, but you probably won't.
Regardless whether you can imagine that or not --
it already _has_ been done.
<snip>
Regards,
Juergen
--
/"\ ASCII ribbon campain | "Everything should be made as simple
\ / against HTML in | as possible, but not simpler."
X e-mail and news, |
/ \ and unneeded MIME | [Albert Einstein]
10. Re: Eu's poor design
Andreas Rumpf wrote:
> Juergen Luethje wrote:
>>
>>
>> Andreas Rumpf wrote:
>>
>>> Peter Willems wrote:
>>
>> [Call by Reference]
>>
>>>> And the lack of such an option doesn't mean you can't write
>>>> serious or professional applications with it.
>>> Well, agreed, you CAN, but you probably won't.
>>
>> Regardless whether you can imagine that or not --
>> it already _has_ been done.
> Well once there was written plenty of asm, and believe it or not, it
> _has_ been done and it worked. So what? Should we program in asm any
> longer? Certainly not.
ASM is not the topic at the moment. Anyway, who are "we"? And why do you
think that it's your job to decide, what programming language "we"
should use? Actually there _are_ programmers, who use ASM nowadays, to
write professional Windows applications.
> So where is your point? I already said that it
> can be done without cbr, it is just much harder.
Yes, you wrote so, but you also wrote something else. And that's what
I referred to. You wrote (as quoted above):
"you CAN, but you probably won't"
[write serious or professional applications without an option for Call
by Reference]
My point was, that I wanted to say: "This statement is false."
Regards,
Juergen
--
Get your facts first, and then
you can distort 'em as you please.
[Mark Twain]
11. Re: Eu's poor design
- Posted by eugtk at yahoo.com
Aug 17, 2003
--- Juergen Luethje <j.lue at gmx.de> wrote:
> Andreas Rumpf wrote:
> > Juergen Luethje wrote:
> >> Andreas Rumpf wrote:
> >> [Call by Reference]
OK, we've had our fun with our computer science
expert - who might just need to hit the books a bit
more.
1. What you have been complaining about is NOT
"Call by Reference" - it is Pass by Reference. Look it
up.
2. If you think case sensitivity is a problem, then
you
clearly have never written a large program. If you
had,
you would know that it's an aid, not a hindrance.
3. You totally missed the fact that Euphoria does
indeed have a major design flaw. One which causes
problems both for beginners and for experienced Eu
programmers, and which may limit Euphoria's future
growth. An analysis of this would make a good
term paper.
Irv
12. Re: Eu's poor design
I'm very curious what this design flaw might be as well?
-Deric Wechter
eugtk at yahoo.com wrote:
>
>
>--- Juergen Luethje <j.lue at gmx.de> wrote:
>
>> Andreas Rumpf wrote:
>> > Juergen Luethje wrote:
>> >> Andreas Rumpf wrote:
>
>> >> [Call by Reference]
>
>OK, we've had our fun with our computer science
>expert - who might just need to hit the books a bit
>more.
>
>1. What you have been complaining about is NOT
>"Call by Reference" - it is Pass by Reference. Look it
>up.
>
>2. If you think case sensitivity is a problem, then
>you=20
>clearly have never written a large program. If you
>had,=20
>you would know that it's an aid, not a hindrance.
>
>3. You totally missed the fact that Euphoria does
>indeed have a major design flaw. =A0One which causes=20
>problems both for beginners and for experienced Eu
>programmers, and which may limit Euphoria's future=20
>growth. =A0An analysis of this would make a good=20
>term paper.=20
>
>Irv
>
>
>
>TOPICA - Start your own email discussion group. FREE!
>
>
y!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=3D393397
Get AOL Instant Messenger 5.1 free of charge. Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=3D380455
13. Re: Eu's poor design
On Sun, Aug 17, 2003 at 04:20:43PM +0000, Andreas Rumpf wrote:
>
>
> eugtk at yahoo.com wrote:
> >
> >
> > --- Juergen Luethje <j.lue at gmx.de> wrote:
> >
> > > Andreas Rumpf wrote:
> > > > Juergen Luethje wrote:
> > > >> Andreas Rumpf wrote:
> >
> > > >> [Call by Reference]
> >
> > OK, we've had our fun with our computer science
> > expert - who might just need to hit the books a bit
> > more.
> Are you another guy who has looked at 500.000 loc of your code and found
> out that call by reference (or "pass by reference" where is the
> difference, arrogant boy?) isn't needed (or at least not practical)?
> That's so ridiculous. I don't believe you.
That depends on what your first programming language is, believe it or not.
If you learned programming with pass-by-ref, then you might find it hard
to code w/o it (as you haven't learned how to think w/o it) while if
you learned with pass-by-val then you prolly wont use it a lot on a language
with pass-by-ref (as you think and plan w/o it when you code).
Same for goto etc.
>
> > 1. What you have been complaining about is NOT
> > "Call by Reference" - it is Pass by Reference. Look it
> > up.
> Our great business man used "call by reference" too, so I guess it is
> correct.
First of all, pass by reference is passing a variable into a routine and
having the routine be able to manipulate it (as opposed to it manipulating
a copy that will be forgotten as soon as the routine returns, aka pass by
value).
Call by reference, I have not heard before, but at first glance it looks like
it is about function pointers (which Eu has in a limited sense: routine_id() ).
At a second glance, it looks like some sort of strange OOP concept. Only at a
third glance did I realize you might have meant pass-by-ref.
And, since when are business men experts on hacker lingo? ;p
>
> > 2. If you think case sensitivity is a problem, then
> > you
> > clearly have never written a large program. If you
> > had,
> > you would know that it's an aid, not a hindrance.
> I've written large programs. And lack of "call by reference" is a
> hindrance, believe it or not.
So what was your first programming language?
Also, what syntax do you plan to use for PBR in Prophoria? Jw.
<snip>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
14. Re: Eu's poor design
On Sun, Aug 17, 2003 at 05:29:00PM +0000, Andreas Rumpf wrote:
>
>
> My first language was Pascal/Delphi which has both. (I admit, "pass by
> reference" (I can learn!) is preferred in Pascal.)
Ok.
>
> Apart from that, now another reason (of course for YOU these are only MY
> shortcomings why Euphoria isn't as useful as it could be:
> Have you ever tried to implement a binary tree in Euphoria?
No, but I'll try...
> I first tried it this way:
>
> constant
> LEFT = 1,
> RIGHT = 2,
> DATA = 3
>
> sequence root -- a tree is {lefttree, righttree, data}
> root = {}
>
> function put(sequence root, object data)
> -- overwrites exisiting data in the tree
> -- this is just a little example. Note that you can't implement
> -- insert/delete (iterative) either
> integer cmp_result
> sequence node
> node = root
> while not equal(node, {}) do
> cmp_result = compare(node[DATA], data)
> if cmp_result = -1 then
> node = node[LEFT]
> elsif cmp_result = 1 then
> node = node[RIGHT]
> else -- overwrite data
> node[DATA] = data -- creates a copy of the node 
> -- we can't modify the tree!!!
> end if
> end while
> return root
> end function
You could also do this:
function set_slice(sequence x, sequence list, object data)
if length(list) = 1 then
--easy part, just set it
x[list[1]] = data
return x
else
--recursively go thru the slices
x[list[1]] = set_slice(x[list[1]], list[2..length(list)], data)
end if
end function
function put(sequence root, object data)
-- overwrites exisiting data in the tree
-- this is just a little example. Note that you can't implement
-- insert/delete (iterative) either
integer cmp_result
sequence node, stores
node = root
stores = {}
while not equal(node, {}) do
cmp_result = compare(node[DATA], data)
if cmp_result = -1 then
node = node[LEFT]
stores &= LEFT
elsif cmp_result = 1 then
node = node[RIGHT]
stores &= RIGHT
else -- overwrite data
root = set_slice(root, stores&DATA, data)
end if
end while
return root
end function
Not that intuitive unfortuantly.
>
> How make it iterative? I think the only way to do it iterative (more
> efficient if you don't have tail-recursion-optimizations, which Eu
> probably doesn't have) is like this:
>
> sequence tree -- here all the nodes are stored!
> -- a node is now { index to left subtree, index to right subtree,
> -- data }
> -- index = 0 if there is no subtree
>
> -- so put becomes:
> integer root
> root = 0
>
> function put(integer root, object data)
> -- overwrites exisiting data in the tree
> integer cmp_result
> integer node
> node = root
> while node != 0 do
> cmp_result = compare(tree[node][DATA], data)
> if cmp_result = -1 then
> node = tree[node][LEFT]
> elsif cmp_result = 1 then
> node = tree[node][RIGHT]
> else -- overwrite data
> tree[node][DATA] = data -- creates a copy of the sequence
> -- which stores all our nodes
> end if
> end while
> return tree
> end function
>
> This works, but it is more difficult. Note also, that inserting requires
> the tree to append a new node which has a worst efficiency of O(N), so
> forget about inserting with O(log N)! (Though I must admit that in
> practice it will probably work fine...)
>
Yes, so PBR would be really useful here ... but your use of a global sequence
and indexes basicly IS pbr.
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
15. Re: Eu's poor design
On Sun, Aug 17, 2003 at 06:55:50PM +0000, Andreas Rumpf wrote:
> I am tired of argumenting about this.
Ok.
> Still nobody showed me how to do
> seq[1][2][3] = some_func(seq[1][2][3])
> easier in Eu.
x = some_func(x)
> Still nobody showed me an elegant tables.e implementation
> without pbr.
What does tables.e do again?
jbrown
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
16. Re: Eu's poor design
On Sun, Aug 17, 2003 at 07:41:01PM +0000, Andreas Rumpf wrote:
>
>
> > (making a stack in Eu is easy)
> Let's see the stack in Eu:
>
> sequence stack
> stack = {}
>
> function push(sequence stack, object item)
> return stack = append(stack, item)
this is wrong, btw. should be:
stack = append(stack, item)
return stack
> end function
>
> function pop(sequence stack) -- returns stack without top
No, the pop removes the top of the stack, and then returns the part it
removed.
> return stack[1..length(stack)-1]
> end function
>
> function topOfStack(sequence stack)
> return stack[length(stack)]
> end function
>
> Yes, quite easy. But what if I want to make it easier and more
> efficient? (Using push()/pop() that modify the stack directly!) Guess
> what, it can't be done in Eu.
Wrong.
sequence stack
stack = {}
procedure push(object item)
stack = append(stack, item)
end procedure
function pop()
object item
item = stack[length(stack)]
stack = stack[1..length(stack)-1]
return item
end function
or with your version of pop() and topOfStack() (which is wrong btw)
function pop()
return stack[1..length(stack)-1]
end function
function topOfStack()
return stack[length(stack)]
end function
> Again, in Pascal/C/etc. I have choice how to implement certain things!
> You can't even write a swap() routine, because of lack of pbr!
Well C has no pbr. It has simulated pbr via pointers.
Yes, the inability to have a swap() routine is annoying. Very much so.
Of course this could also be solved via macros ...
object tmp
macro swap(a,b) tmp = a a = b b = tmp
...
swap(var_one, var_two)
but only because the macro is rewritten as
tmp = var_one var_one = var_two var_two = tmp
so even the macro simulates pass-by-reference!
jbrown
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
17. Re: Eu's poor design
On Sun, Aug 17, 2003 at 07:47:01PM +0000, Andreas Rumpf wrote:
>
>
> jbrown105 at speedymail.org wrote:
> >
> >
> > On Sun, Aug 17, 2003 at 06:55:50PM +0000, Andreas Rumpf wrote:
> > > I am tired of argumenting about this.
> >
> > Ok.
> >
> > > Still nobody showed me how to do
> > > seq[1][2][3] = some_func(seq[1][2][3])
> > > easier in Eu.
> >
> > x = some_func(x)
> Yes, but you left out some assignments:
> x = seq[1][2][3]
> x = some_func(x)
> seq[1][2][3] = x
> -- This isn't easier.
Ok, tell me this.
Why do you have the 'seq[1][2][3]' in the first place? Why not just use
x throughout?
>
> >
> > > Still nobody showed me an elegant tables.e implementation
> > > without pbr.
> >
> > What does tables.e do again?
> Give me some time, I look for the code...
>
Ok
> >
> > jbrown
> >
> > >
> > > TOPICA - Start your own email discussion group. FREE!
> > >
> >
> > --
> > /"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
> > \ / campain against | Linux User:190064
> > X HTML in e-mail and | Linux Machine:84163
> > /*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
> >
> >
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
18. Re: Eu's poor design
On Sun, Aug 17, 2003 at 08:12:51PM +0000, Andreas Rumpf wrote:
>
>
> jbrown105 at speedymail.org wrote:
> >
> >
> > On Sun, Aug 17, 2003 at 07:47:01PM +0000, Andreas Rumpf wrote:
> > >
> > >
> > > jbrown105 at speedymail.org wrote:
> > > >
> > > >
> > > > On Sun, Aug 17, 2003 at 06:55:50PM +0000, Andreas Rumpf wrote:
> > > > > I am tired of argumenting about this.
> > > >
> > > > Ok.
> > > >
> > > > > Still nobody showed me how to do
> > > > > seq[1][2][3] = some_func(seq[1][2][3])
> > > > > easier in Eu.
> > > >
> > > > x = some_func(x)
> > > Yes, but you left out some assignments:
> > > x = seq[1][2][3]
> > > x = some_func(x)
> > > seq[1][2][3] = x
> > > -- This isn't easier.
> >
> > Ok, tell me this.
> >
> > Why do you have the 'seq[1][2][3]' in the first place? Why not just use
> > x throughout?
> Because often you need sequences in sequences! And seq[1][2] is the way
> to address the inner sequence.
In that case, my way is easier!
x = seq[1][2][3]
x = some_func(x)
x = some_other_func(x)
for i = 1 to length(x) do
x[i] = ....some stuff here....
end for
seq[1][2][3] = x
jbrown
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
19. Re: Eu's poor design
On Sun, Aug 17, 2003 at 08:19:29PM +0000, Andreas Rumpf wrote:
>
>
> jbrown105 at speedymail.org wrote:
> >
> >
> > On Sun, Aug 17, 2003 at 07:41:01PM +0000, Andreas Rumpf wrote:
> > >
> > >
> > > > (making a stack in Eu is easy)
> > > Let's see the stack in Eu:
> > >
> > > sequence stack
> > > stack = {}
> > >
> > > function push(sequence stack, object item)
> > > return stack = append(stack, item)
> >
> > this is wrong, btw. should be:
> >
> > stack = append(stack, item)
> > return stack
> Yes, as I said I should stop coding in topica windows.
LOL.
> >
> > > end function
> > >
> > > function pop(sequence stack) -- returns stack without top
> >
> > No, the pop removes the top of the stack, and then returns the part it
> > removed.
> Not necessarily.
> >
> > > return stack[1..length(stack)-1]
> > > end function
> > >
> > > function topOfStack(sequence stack)
> > > return stack[length(stack)]
> > > end function
> > >
> > > Yes, quite easy. But what if I want to make it easier and more
> > > efficient? (Using push()/pop() that modify the stack directly!) Guess
> > > what, it can't be done in Eu.
> >
> > Wrong.
> >
> > sequence stack
> > stack = {}
> >
> > procedure push(object item)
> > stack = append(stack, item)
> > end procedure
> > function pop()
> > object item
> > item = stack[length(stack)]
> > stack = stack[1..length(stack)-1]
> > return item
> > end function
> >
> > or with your version of pop() and topOfStack() (which is wrong btw)
> >
> > function pop()
> > return stack[1..length(stack)-1]
> > end function
> > function topOfStack()
> > return stack[length(stack)]
> > end function
>
> So, you used a global variable... (And proved one of my earlier
> posts...) What if I want to have 2 different stacks? - Use a sequence of
> stacks and pass the routines the index of the stack to work with. This
> is a solution. But it simulates pbr! So why not have it directly?
Ask Rob why not to have PBR directly. But the point: if you really need
pbr in Eu, you can simulate it. (You can even make a library and have
set_ptr() and get_ptr() to make it look nice if you want.)
Hence, lack of PBR might hurt the beauty of the code. But it doesnt make it
harder to use Euphoria!
>
> > > Again, in Pascal/C/etc. I have choice how to implement certain things!
> > > You can't even write a swap() routine, because of lack of pbr!
> >
> > Well C has no pbr. It has simulated pbr via pointers.
> Ok, forget about C. What about Basic/Ada/C++?
<sidebar>
Did the original version of BASIC have pbr?
I wonder if anyone even has a copy of the original BASIC heh.
</sidebar>
I should point out that a variable_id() would give Eu pointers, which in
turn would let us simulate pbr far better than a sequence.
> >
> > Yes, the inability to have a swap() routine is annoying. Very much so.
> > Of course this could also be solved via macros ...
> >
> > object tmp
> > macro swap(a,b) tmp = a a = b b = tmp
> > ...
> > swap(var_one, var_two)
> >
> > but only because the macro is rewritten as
> >
> > tmp = var_one var_one = var_two var_two = tmp
> >
> > so even the macro simulates pass-by-reference!
> Let's implement a macro facility instead of pbr! (Irony)
Seriously, I think we need macros. We really do.
jbrown
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
20. Re: Eu's poor design
- Posted by euman at bellsouth.net
Aug 17, 2003
You guys ever heard of mIRC or ICQ......
over 25 post on Eu's poor design [shent]
21. Re: Eu's poor design
On Sun, Aug 17, 2003 at 08:37:53PM +0000, Andreas Rumpf wrote:
> > In that case, my way is easier!
> >
> > x = seq[1][2][3]
> > x = some_func(x)
> > x = some_other_func(x)
> > for i = 1 to length(x) do
> > x[i] = ....some stuff here....
> > end for
> > seq[1][2][3] = x
> >
> > jbrown
>
> Yes, that's the way to go in Euphoria. But I think, the
> seq[1][2][3] = x
> command is often forgotten.
Perhaps. An understandable mistake from a newbie programmer, to be sure.
It would be better to do this:
alias x as seq[1][2][3]
x = some_func(x)
x = some_other_func(x)
for i = 1 to length(x) do
x[i] = ....some stuff here....
end for
--no need for a 'seq[1][2][3] = x' as the alias automaticly causes the original
--slice to be updated.
This alias technique can be considered close to pbr, tho depending on its
implementation it might be considered closer to that of a "#define" or a macro
(but as I have already shown the 2 arent really that far apart anyways).
> And if you look at Rob's hash.e and
> translate it to a program that uses pbr (assuming Eu would have it)you
> will find out that pbr is less error-prone, easier to understand and
> more efficient.
>
Concurred. I'm not against PBR in the language. What I am saying is that the
lack of PBR is not a difficult workaround (worst case senario: you have to use
a global sequence and sequence indexes to simulate pbr).
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
22. Re: Eu's poor design
On Sun, Aug 17, 2003 at 09:16:00PM +0000, Andreas Rumpf wrote:
>
>
> But think about it: Some languages are too complex because they offer
> features that would better have been implemented via a library.
> Euphoria's the other way round. It is too simple, so a lot of features
> have been implemented via strange libraries (a library for pass by
> reference is ridiculous). Look at those funny call_func()/call_proc()
> functions patching over a serious problem: The lack of function
> pointers! And the lack of forward references!
>
Guess this means you are against a variable_id()/set_var()/get_var() concept
for pbr eh?
Also, I wonder what you would think about the OE planned implementation of
OOP. The idea, is to support fully the OO syntax (so foo.method(bar.member)
works) but to have the OO engine in a library. The parser would simply
convert foo.method(..) into call_method(foo, method, ...) (which is what
most Eu OO librarys look like btw). So, the syntax would be builtin but
the actual code which did OO would be external. Your thougths?
jbrown
>
>
> TOPICA - Start your own email discussion group. FREE!
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
23. Re: Eu's poor design
On Sun, 17 Aug 2003 19:53:25 +0000, Andy Serpa <ac at onehorseshy.com>
wrote:
>I suggest this for reading:
>
>http://www.haskell.org/complex/why_does_haskell_matter.html
>
Thanks for the link, you reacquainted me with Simon L Peyton Jones, I
first purchased one of his books back in 1987...
I think it's quite amusing to note that Haskell (which I hope most
people will agree is a fairly advanced language) does not have pass by
reference!
Pete
24. Re: Eu's poor design
On Sun, Aug 17, 2003 at 10:32:45PM +0000, Andreas Rumpf wrote:
> > > > > Still nobody showed me how to do
> > > > > seq[1][2][3] = some_func(seq[1][2][3])
> > > > > easier in Eu. Still nobody showed me an elegant tables.e
> > > > > implementation
> > > > > without pbr.
> > > > >
> > > >
> > > > I believe you are letting your thinking be too much influenced by the
> > > > languages you are used to. You don't have pbr, so you think, "My god,
> > > > how in the world can I solve this problem in Euphoria?"
> > > Oh boy, I know how to solve it in Euphoria. It is just that the solution
> > >
> > >
> > > is neither elegant or efficient.
> > >
> >
> > I don't think you know the best way to do it Euphoria, because you are
> > forcing un-Euphorian concepts onto it.
> Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian
> concept? I don't think so.
Loops are not. PBR is, considering the hacks one has to go thru to emulate it.
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
25. Re: Eu's poor design
On Sun, 17 Aug 2003 22:32:45 +0000 (08/18/03 08:32:45)
, Andreas Rumpf <pfropfen at gmx.net> wrote:
[snip]
>> I don't think you know the best way to do it Euphoria, because you are
>> forcing un-Euphorian concepts onto it.
> Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian
> concept? I don't think so.
PBR is not a Euphoria concept because Euphoria tries to minimise side-
effects. In Euphoria, a routine is a code construct that is used to do a
unit of work, possibly utilizing the data passed to it. If the routine
returns any data, that returned data is independant of the data passed to
it.
By having this restriction, the interpreter can make some optimisations
(assumptions) about the variables in scope. If PBR were allowed, then the
interpreter must not assume that the routine has left its variables
untouched. Which means that subsequent references to the variables must be
re-read by the interpreter IN CASE they have been modified.
integer a,b
a = 1
b = someFunc(a)
someProc(&a, &b) -- I'm using the '&' to indicate PBR
-- At this point, 'a', or 'b' or both may or may not have been changed.
-- The interpreter cannot cache the value of 'a' or 'b' but is forced
-- to fetch them again.
if b = a then
...
end if
PBR always increases the probability of side-effects. To counteract those,
extra code is required, adding to the maintenance effort and further
increasing the probability of bugs.
So, why does PBR exist as a concept and why do we need it?
PBR came about as a practical solution to a physical problem. Before we had
compilers, parameters were passed to routines by placing their values into
a CPU register. The routine would also pass back values in CPU registers.
This gave rise to 'calling conventions' - a protocol about which registers
to use for what. It soon transpired that some data was too big to place
into registers. Sometimes multiple registers were used, and other times the
data was placed into RAM and a register was loaded with the RAM address of
the data value. In other words, a reference to the parameter was passed
instead of the parameter itself.
Later, when compilers were devised and espectially the concept of a stack
frame reference, passing large data values by value was made easier. But
all that copying to RAM and back could slow things down. So, in general,
when it came to passing a large dataitem, coders would tend to pass its RAM
address (because that was small). This was also helpful for dataitems of
arbitary sizes, as the address length is always the same size, regardless
of the actual dataitem's size.
So, in general, PBR is used to avoid copying large dataitems, and/or to
make using arbitary sized dataitems easier. Another use is when the
decision to update a dataitem is not known by the routine until runtime. A
fourth reason is because its easier to code it that way.
In Euphoria, large dataitems are repesented by sequences. When Euphoria
passes a sequence to a routine, it actually does pass a reference to the
sequence - there is no big copying going on. The first time that the
sequence is updated by the routine, a copy is made of the sequence. This
means that routines that do not update sequences are not penalized by
receiving sequences.
Now comes the Euphoria philosophy - who owns the data; the caller or the
callee? Euphoria believes that the caller owns the data. That it is the
caller who is responsible for a dataitem being consistent and correct. As
such, it assumes that the callee knows nothing about the dataitem other
than its current contents. Thus if the callee needs to change the data, it
must tell the caller what the new values should be. It is then the caller
that decides how to apply these changes.
PBR would break this philosophy.
However, what we find over and over again in Euphoria programs is a coding
idiom along the lines of ...
x = func(x, ...)
There maybe a case for adding some syntactic sugar to Euphoria that makes
coding this commonly used idiom easier.
func( &x, ... )
for example. This idiom is particularly irksome when 'x' is really a rather
long name reference. If this syntax were allowed in Euphoria, then
append( &stack_space[lThisStack], pData )
would be interpreted as if I had actually written ...
stack_space[lThisStack] = append( stack_space[lThisStack], pData )
Back to the PBR usages...
Again, sequences nicely implement arbitary-length dataitems. Passing these
to 'read-only' routines incurs no penalty in terms of copying data. And
again, the data ownership philosophy would apply to changing the dataitems.
When it comes to the run-time decisions about whether or not elements need
updating, Euphoria's data ownership philosophy means that the caller may
know that a dataitem might need updating but not what nor how the new
values are to be derived. So it would need to pass the dataitem to the
routine that does know how to determine if updating is required, etc...
That routine could either pass back an updated dataitem or a list of
changed elements to the caller. The caller would then apply the new data
values to the real dataitem.
I'm not supporting either PBR or Euphoria's philosophy in this message.
Just stating what I think the situation is. I could be wrong and I'd be
happy to be 'upgraded' too.
>> > > > I am learning > > Haskell, but am used to Euphoria, so I have
>> similar thoughts along the > > way. That doesn't mean there is anything
>> wrong with Haskell, however, > > which is even higher-level than
>> Euphoria. It just means I need to > > adjust my thinking a bit.
>> > > > > I suggest this for reading:
>> > > > > http://www.haskell.org/complex/why_does_haskell_matter.html
>> > > > > Scroll to the bottom and read the "Epilogue". It seems to me
>> you are > > exhibiting this syndrome...
>> > > > Thank you for analysing my psyche. (As I said earlier I know
>> functional > programming. But Eu isn't functional (it has side-effects!)
>> .)
>> >
>>
>> I didn't say it was functional (it does have a few functional elements,
>> though).
> Yeah, one or two.
>
>> You missed the point.
> No. As I said, Eu has side-effects. Pbr would not break Eu's concepts.
Euphoria makes no claim to be a Functional Programming language. It tries
to minimise side-effects. And PBR would break Eu's concepts (philosophy),
just like goto and forward referencing would.
These concepts are not excluded from Euphoria because they can't be
implemented, but because the designer has chosen not to implement them due
to a philosophical position. It is valid to hold such a position too, just
as all of us hold one or more ourselves.
In the end we have three choices...
a) Change the designer's philosophy -- next to impossible.
b) Work with what we've got and improve that within the designer's
boundaries.
c) Use something else when Euphoria can't do it the way we want it done.
--
cheers,
Derek Parnell
26. Re: Eu's poor design
On Sun, 17 Aug 2003 22:38:39 +0000 (08/18/03 08:38:39)
, Andreas Rumpf <pfropfen at gmx.net> wrote:
>
>
> jbrown105 at speedymail.org wrote:
>>
>>
>> On Sun, Aug 17, 2003 at 09:16:00PM +0000, Andreas Rumpf wrote:
>>> > > But think about it: Some languages are too complex because they
>> offer > features that would better have been implemented via a library.
>> > Euphoria's the other way round. It is too simple, so a lot of features
>> > have been implemented via strange libraries (a library for pass by >
>> reference is ridiculous). Look at those funny call_func()/call_proc() >
>> functions patching over a serious problem: The lack of function >
>> pointers! And the lack of forward references!
But routine_id() is Euphoria's implementation of function pointers. You may
not like the syntax, but the concept is still there.
Forward referencing is not allowed because the designers of Euphoria
believe that it is a 'wrong thing' to implement - like goto and pass-by-
reference. It is a philosophical position. The designer of any language is
allowed to implement their biases and pedalogical ideas. Your job, if you
don't like it, is to *prove and thus demonstrate* that change can bring
about improvement.
>>
>> Guess this means you are against a variable_id()/set_var()/get_var()
>> concept
>> for pbr eh?
> Yes.
It's only syntax.
>>
>> Also, I wonder what you would think about the OE planned implementation
>> of
>> OOP. The idea, is to support fully the OO syntax (so
>> foo.method(bar.member)
>> works) but to have the OO engine in a library. The parser would simply
>> convert foo.method(..) into call_method(foo, method, ...) (which is what
>> most Eu OO librarys look like btw). So, the syntax would be builtin but
>> the actual code which did OO would be external. Your thougths?
>
> Well, a parser knowing an external library is a strange concept.
That is not what was said. What was said was a statement in the form ...
foo.method(...)
would be interpreted as syntactical shorthand for ...
OO:call_method(foo,"method", { ... } )
This allows the implementation of OO to be customized. The coder is not
limited to whatever was supplied with their copy of OpenEU.
The OpenEU parser does NOT know the external library. All it knows is the
shorthand syntax - not it semantics.
> Eu is a procedural language. If I wanted to use OO then I would use
> Eiffel, for example.
And by this reasoning, if we wanted PBR we'd use COBOL etc... and if we
wanted to use GOTO we'd use Assember etc...., and if we wanted forward
references we'd use VB etc...
--
cheers,
Derek Parnell
27. Re: Eu's poor design
On Mon, 18 Aug 2003 07:22:33 +0000 (08/18/03 17:22:33)
, Andreas Rumpf <pfropfen at gmx.net> wrote:
>
>
> Derek Parnell wrote:
[snip]
>> Forward referencing is not allowed because the designers of Euphoria
>> believe that it is a 'wrong thing' to implement - like goto and pass-by-
>>
>> reference. It is a philosophical position. The designer of any language
>> is allowed to implement their biases and pedalogical ideas. Your job, if
>> you don't like it, is to *prove and thus demonstrate* that change can
>> bring about improvement.
> I showed you. I can also show you 'forward', if you like:
Yes, I remember. But firstly, its not *me* you have to convince. Secondly,
showing this proposal is different from proving that it is better than what
currently exists. For example, I can show stuff that is obviously worse.
Showing is not proving. To prove something you would need hard, empirical
evidence that could be substantiated with independant tests by other
people.
>
> forward function b()
>
> function a()
> return b() + 1
> end function
>
> function b()
> return a() + 2
> end function
My 'version' is even simpler...
function a()
return b() + 1
end function
function b()
return ...
end function
I don't even see the need for a 'forward' keyword.
[snip]
> Yes, but pbr is a procedural concept just like 'forward'.
Try telling Haskell that!
--
cheers,
Derek Parnell
28. Re: Eu's poor design
On Mon, 18 Aug 2003 06:54:02 +0000 (08/18/03 16:54:02)
, Andreas Rumpf <pfropfen at gmx.net> wrote:
>
>
> Derek Parnell wrote:
>>
>>
>> On Sun, 17 Aug 2003 22:32:45 +0000 (08/18/03 08:32:45)
>> , Andreas Rumpf <pfropfen at gmx.net> wrote:
>> [snip]
>>
>> >> I don't think you know the best way to do it Euphoria, because you
>> are >> forcing un-Euphorian concepts onto it.
>> > Using loops is an un-Euphorian concept? Using pbr is an un-Euphorian >
>> concept? I don't think so.
>>
>> PBR is not a Euphoria concept because Euphoria tries to minimise side-
>> effects.
> Yes, but this design is not practical. It forces the programmer to use
> global variables all over the place which have their own problems (think
> of gargabe collection...)
I agree with the idea that using global variables is minefield - bugs just
waiting to happen. However, the lack of PBR does NOT force globals and
implementing PBR does not FORCE globals either. The use of globals is a
choice that the implementer may use. They are not forced into it. Remember
that shared variables can be restricted in scope to a source file. Thus a
source file that implements stacks can use shared variables that are not
global.
> So it seems to me, Eu is a language that wants to be functional but
> isn't.
Can't see this myself. I don't believe the designers of Euphoria wanted it
to be a functional language.
> I don't see why using global variables is a better solution.
Neither do I. And I can also see that globals are not the only solution.
I'll send you an implementation of stacks, if you like that demonstrates my
assertion.
>> In Euphoria, a routine is a code construct that is used to do a unit of
>> work, possibly utilizing the data passed to it. If the routine returns
>> any data, that returned data is independant of the data passed to it.
>>
>> By having this restriction, the interpreter can make some optimisations
>> (assumptions) about the variables in scope. If PBR were allowed, then
>> the interpreter must not assume that the routine has left its variables
>> untouched. Which means that subsequent references to the variables must
>> be re-read by the interpreter IN CASE they have been modified.
> Hm. The compiler knows when a parameter is passed in by reference. So we
> can optimize all variables which aren't passed by reference (at least).
Which is the same as saying that we can optimise all variables if none are
ever passed by reference.
>>
>> integer a,b
>> a = 1
>> b = someFunc(a)
>> someProc(&a, &b) -- I'm using the '&' to indicate PBR
>> -- At this point, 'a', or 'b' or both may or may not have been changed.
>> -- The interpreter cannot cache the value of 'a' or 'b' but is forced
>> -- to fetch them again.
>> if b = a then
>> ...
>> end if
>>
>> PBR always increases the probability of side-effects. To counteract
>> those, extra code is required, adding to the maintenance effort and
>> further increasing the probability of bugs.
> I've never had a bug because of pbr. (I've had lots of bugs via pointers
> & lack of garbage collection!)
Probability! I'm talking about probability not certainty. I'm sure you are
not extrapolating your statement to suggest that because you have never
detected a bug caused by PBR in your code that it means that you will never
find one in your code, or that no-one ever has bugs caused by PBR. I know
they exist because I have found them in my code and in other people's code.
I recently read somebody saying that garbage collection is a waste of time
and effort because they have always "deleted" everything they "new'd". The
implication was that it was for lazy or incompetent coders only.
--
cheers,
Derek Parnell
29. Re: Eu's poor design
On Mon, 18 Aug 2003 07:22:33 +0000, Andreas Rumpf <pfropfen at gmx.net>
wrote:
>I showed you. I can also show you 'forward', if you like:
>
>forward function b()
>
>function a()
> return b() + 1
>end function
>
>function b()
> return a() + 2
>end function
>
LOL show that to your tutor, I dare you.
Whatever, it is not hard:
integer brid
function a()
return call_func(brid,{})+1
end function
function b()
return a()+2
end function
brid=3Droutine_id("b")
30. Re: Eu's poor design
Hi Andreas,
You wrote:
[snip]
> By the way, there is only one designer - Rob.
[snip]
Visit please:
http://www.RapidEuphoria.com/hotnew.htm
and
http://www.RapidEuphoria.com/relnotes.htm
and you'll see is Rob "only one designer"
or no, he is not.
Take a look how many people have the thanks
from Rob for their suggestions and bug reports.
To say about "Eu's poor design" you have to
know and point some more concrete thing than
just some language feature, I think.
Regards,
Igor Kachan
kinz at peterlink.ru
31. Eu's poor design
Igor Kachan wrote:
>
>
> Hi Andreas,
>
> You wrote:
>
> [snip]
>
> > By the way, there is only one designer - Rob.
>
> [snip]
>
> Visit please:
>
> http://www.RapidEuphoria.com/hotnew.htm
>
> and
>
> http://www.RapidEuphoria.com/relnotes.htm
>
> and you'll see is Rob "only one designer"
> or no, he is not.
>
> Take a look how many people have the thanks
> from Rob for their suggestions and bug reports.
And you take a look how often Rob says: "I thank xxx for suggesting that
nice/important language feature".
>
> To say about "Eu's poor design" you have to
> know and point some more concrete thing than
> just some language feature, I think.
I wish I hadn't written "Eu's poor design" as subject.
32. Re: Eu's poor design
Andreas Rumpf wrote:
>
>
> Pete Lomax wrote:
>
>>
>>On Mon, 18 Aug 2003 07:22:33 +0000, Andreas Rumpf <pfropfen at gmx.net>
>>wrote:
>>
>>
>>>I showed you. I can also show you 'forward', if you like:
>>>
>>>forward function b()
>>>
>>>function a()
>>> return b() + 1
>>>end function
>>>
>>>function b()
>>> return a() + 2
>>>end function
>>>
>>
>>LOL show that to your tutor, I dare you.
>>Whatever, it is not hard:
>>
>>integer brid
>
> And again, Eu's type system is confusing! brid is not an integer really,
> it is a pointer to a function!
More like an alias for a pointer to a function. It is an integer that
references a table of references to functions.
You could always use deliberate conventions and a sneaky type declaration:
--------
type predeclare(object id) if integer(id) and
id >= 0
then return 1 end if return 0 end type
--------
predeclare is_odd_ -- looks almost like part of Euphoria syntax...
function is_even(integer x)
if x < 0 then return is_even(-x)
elsif x = 0 then return 1
end if return call_func(is_odd_, {x-1})
end function
function is_odd(integer x)
if x = 0 then return 0
end if return is_even(x-1)
end function is_odd_ = routine_id("is_odd")
--------
This isn't a great way to determine whether a number is odd or even, but
it's great as a dual recursion example. :)
--
[ Carl R White == aka () = The Domain of Cyrek = ]
[ Cyrek the Illogical /\ www.cyreksoft.yorks.com ]
