1. RE: Major Bug in Interpreter [Attn: Robert Craig]
- Posted by Chris Bensler <bensler at nt.net>
Feb 13, 2005
-
Last edited Feb 14, 2005
Robert Craig wrote:
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Mario Steele wrote:
> > I just wanted report this bug before 2.5 went Final, cause this is
> > indeed
> > a major bug. I've tested this under 2.5 and 2.4, and 2.4 works
> > correctly,
> > but 2.5 does not. You can see it happening when you invoke the trace
> > like I have it written.
> >
> > }}}
<eucode>
> > with trace
> > sequence stack
> >
> > constant NewValue = {0,0,1,0}
> > stack = {}
> >
> > trace(1)
> > function recursive_call(integer i)
> > integer ib
> > stack &= 0
> > ib = length(stack)
> > stack[ib] = NewValue
> > for x = 1 to 4 do
> > if stack[ib][i] = 0 then
> > stack[ib][i] = recursive_call(i+1)
> > end if
> > end for
> > return ib
> > end function
> >
> > integer i
> > i = recursive_call(1)
> > ? stack
> > machine_proc(26,0)
> > </eucode>
{{{
>
> It's not a bug.
> It's a change in the way things work in a rare,
> ambiguous, and undocumented area.
>
> I should mention this in the 2.5 alpha release notes
> or somewhere.
>
> In order to efficiently support the new $ feature,
> I had to change the order of operations when subscripts
> are performed on the left-hand-side of an assignment. e.g.
>
> stack[ib][i] = recursive_call(i+1)
>
> In 2.4, all expressions are evaluated first, then
> the lhs subscripting is performed and the rhs value is assigned.
>
> In 2.5, I (generally) need to perform each lhs subscript as I go along,
> from left to right, before evaluating the subscript expression
> that comes after it, since I may need to know the proper value of $
> in the subsequent subscript expression.
>
> In 2.4, you obviously counted on recursive_call() being completed
> before the subscripted assignment was done, and you counted
> on stack being changed by the side-effects of that call, before
> the assignment to stack was done.
> None of this was documented in the Reference Manual.
> You just tried it, and it worked.
>
> In 2.5, the lhs var being subscripted will keep its original
> value (I just increment its ref count), and will then be
> modified by the assignment. The effect of any side-effects
> on that var (i.e. stack) will be lost
> as the assignment is completed. If I don't preserve the original
> value, I can easily have crashes due to your having
> "pulled the rug out from under me" while I'm in the middle of
> trying to subscript a now non-existent value. And, no, I don't
> want to insert checks all over the place for this bizarre situation.
>
> You only have to worry about this change if you are doing
> a subscripted assignment with multiple subscripts on the lhs,
> and in the same statement you are calling a function
> that has the side-effect of modifying the lhs var (even as it
> is being assigned-to).
>
> You can make things work the way you want, and also
> make your code more readable, by performing the function call
> in a separate statement before trying to modify the lhs variable.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
Did you ask any of your patrons if they thought that was an acceptable
sacrifice for the sake of a shorthand feature like $????
I think you have completely defeated the value of having $ at all.
For crying out loud, a shorthand is supposed to SAVE time and effort,
not create MORE work.
Once again, we have to resort to hacks to overcome Eu's stupidity.
If this is such a 'minor' issue, then why has it been reported by at
least 2 people that I know of already? 2.5 isn't even final yet.
It may be a minor issue to you, but it is not to many of us.
It boggles my mind that you will so blatantly break compatability for
something so stupid, but won't even consider doing such a thing for real
issues, like include files and scope.
Chris Bensler
Code is Alchemy
2. RE: Major Bug in Interpreter [Attn: Robert Craig]
- Posted by Robert Craig <rds at RapidEuphoria.com>
Feb 13, 2005
-
Last edited Feb 14, 2005
Chris Bensler wrote:
> Did you ask any of your patrons if they thought that was an acceptable
> sacrifice for the sake of a shorthand feature like $????
Patron, did you ever pay me for the translator I gave you 5 years ago,
that you said you would pay for "eventually"?
> I think you have completely defeated the value of having $ at all.
> For crying out loud, a shorthand is supposed to SAVE time and effort,
> not create MORE work.
I'm pretty sure 90%+ of people would like to keep the $
feature, rather than keep the freedom to permanently modify a variable
via function side-effects at the same time they are also modifying it
via doubly-subscripted assignment.
> Once again, we have to resort to hacks to overcome Eu's stupidity.
Where "hack" = split one ambiguous statement into two clear statements.
If Euphoria is "stupid", what about the person who has been using it,
and whining about it, for several years without finding a better language?
> If this is such a 'minor' issue, then why has it been reported by at
> least 2 people that I know of already? 2.5 isn't even final yet.
And both of those people understand why the change was made,
and neither is suggesting that $ was a bad idea.
> It may be a minor issue to you, but it is not to many of us.
Please don't say "us" when you have personally
never been affected by this issue. You should speak for yourself,
not for some imaginary group of unnamed people.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. RE: Major Bug in Interpreter [Attn: Robert Craig]
- Posted by Derek Parnell <ddparnell at bigpond.com>
Feb 13, 2005
-
Last edited Feb 14, 2005
Robert Craig wrote:
>
> Chris Bensler wrote:
> > Did you ask any of your patrons if they thought that was an acceptable
> > sacrifice for the sake of a shorthand feature like $????
>
> Patron, did you ever pay me for the translator I gave you 5 years ago,
> that you said you would pay for "eventually"?
Unlike myself, that has paid for Euphoria (full suite) multiple times.
> > I think you have completely defeated the value of having $ at all.
> > For crying out loud, a shorthand is supposed to SAVE time and effort,
> > not create MORE work.
>
> I'm pretty sure 90%+ of people would like to keep the $
> feature, rather than keep the freedom to permanently modify a variable
> via function side-effects at the same time they are also modifying it
> via doubly-subscripted assignment.
In that extreme minority (it seems) that would actually like both.
> > Once again, we have to resort to hacks to overcome Eu's stupidity.
>
> Where "hack" = split one ambiguous statement into two clear statements.
It is only ambiguous because it's behaviour has not been documented.
> If Euphoria is "stupid", what about the person who has been using it,
> and whining about it, for several years without finding a better language?
The act of using Euphoria does not automatically mean that Euphoria is
perfect. Euphoria is a brilliant language, but in spite of it being so
extrordinally fantastic, it still has a few blemishes.
> > If this is such a 'minor' issue, then why has it been reported by at
> > least 2 people that I know of already? 2.5 isn't even final yet.
>
> And both of those people understand why the change was made,
> and neither is suggesting that $ was a bad idea.
Of course the $ is not a bad idea. The 'bad idea' is changing the behaviour
of Euphoria *without* telling your users.
> > It may be a minor issue to you, but it is not to many of us.
>
> Please don't say "us" when you have personally
> never been affected by this issue. You should speak for yourself,
> not for some imaginary group of unnamed people.
Fair comment.
However, it does effect some of my code though. I now have to go
through it all to catch my use of an undocumented, but reasonable,
coding practice. Reasonable, because this is how it works in other languages
that I use.
--
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria
4. RE: Major Bug in Interpreter [Attn: Robert Craig]
Robert Craig wrote:
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Chris Bensler wrote:
> > Did you ask any of your patrons if they thought that was an acceptable
> > sacrifice for the sake of a shorthand feature like $????
>
> Patron, did you ever pay me for the translator I gave you 5 years ago,
> that you said you would pay for "eventually"?
You gave me more than that. And to be honest, that is the only reason I
didn't start bitching sooner.
The arrangement was not that I would pay you. I said that I would like
to pay anyways, because I wanted to support you. Things change.
You gave me the translator in gratitude for my efforts in finding and
setting up topica.
Perhaps if you didn't sluff me off like a piece of dandruff, I would
have been more inclined to keep to my intentions, and maybe I would
still be assisting, instead of pointing out your poor business
practices.
> > I think you have completely defeated the value of having $ at all.
> > For crying out loud, a shorthand is supposed to SAVE time and effort,
> > not create MORE work.
>
> I'm pretty sure 90%+ of people would like to keep the $
> feature, rather than keep the freedom to permanently modify a variable
> via function side-effects at the same time they are also modifying it
> via doubly-subscripted assignment.
How do you know 90%? Because nobody else is complaining? Perhaps that is
because they know that it's FUTILE.
Did you ever do any surveys to find out what the general concensus is?
And there was no other way to accomplish that?
I implemented that shorthand in my preprocessor in 2002 (or was it
2001), and it did not break compatability.
> > Once again, we have to resort to hacks to overcome Eu's stupidity.
>
> Where "hack" = split one ambiguous statement into two clear statements.
The hack is that we have to use unintuitive practices to overcome a
trivial thing that should never be in the first place.
> If Euphoria is "stupid", what about the person who has been using it,
> and whining about it, for several years without finding a better
> language?
I have found better languages. None that have the potential to be as
good as Euphoria, but you are quickly and systematically eliminating
that difference.
> > If this is such a 'minor' issue, then why has it been reported by at
> > least 2 people that I know of already? 2.5 isn't even final yet.
>
> And both of those people understand why the change was made,
> and neither is suggesting that $ was a bad idea.
They understand, but do they AGREE?
I understand too, but that doesn't mean I think it's a good solution.
> > It may be a minor issue to you, but it is not to many of us.
>
> Please don't say "us" when you have personally
> never been affected by this issue. You should speak for yourself,
> not for some imaginary group of unnamed people.
Unlike you, I interact with other users of Euphoria, and discuss issues
like this. I say 'us' because that's what I mean.
Chris Bensler
Code is Alchemy
5. RE: Major Bug in Interpreter [Attn: Robert Craig]
Derek Parnell wrote:
> However, it does effect some of my code though. I now have to go
> through it all to catch my use of an undocumented, but reasonable,
> coding practice. Reasonable, because this is how it works in other languages
> that I use.
FYI, there are popular languages like C and C++ which
do *not* define what will happen if you call a function with
side effects in the middle of a statement or expression.
In something as simple as:
expr_a + expr_b
C/C++ does *not* define whether expr_a or expr_b is evaluated first.
C/C++ defines expression evaluation order only partially, in terms of
precedence rules.
In a call to a C function:
myfunc(expr_a, expr_b, expr_c);
the order of evaluation of the arguments is *undefined* by the language.
x[expr_a] = expr_b;
is the same story.
In these situations, function side-effects can create portability issues
as well as readability issues. If you are going to check your Euphoria
code, you had better also check all the C/C++ code you've ever written for
this portability bug. See the "ANSI C White Book" Section A7 - Expressions.
It seems to me Ada and some others are pretty much the same.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. RE: Major Bug in Interpreter [Attn: Robert Craig]
Robert Craig wrote:
>
> Derek Parnell wrote:
> > However, it does effect some of my code though. I now have to go
> > through it all to catch my use of an undocumented, but reasonable,
> > coding practice. Reasonable, because this is how it works in other languages
> > that I use.
>
> FYI, there are popular languages like C and C++ which
> do *not* define what will happen if you call a function with
> side effects in the middle of a statement or expression.
Thank you for this. I knew this to be true of expressions, but was not
so certain about statements.
I've done some experimentation, and I agree that not all implementations
of other languages do RHS evaluation before LHS evaluation in an
assignment statement.
--
Derek Parnell
Melbourne, Australia
irc://irc.sorcery.net:9000/euphoria
7. RE: Major Bug in Interpreter [Attn: Robert Craig]
My views on this:
I always RHS evaluation since it was more intuitive.
The '$' operator is a good timesaver although I don't use it that often to keep
2.4 compatability.
I always assumed that '$' was simply the same as "length()".
Compatability with old programs should be prefered unless doing so would be a
major benefit.
Efficiency is good but if it is negligible and changes something then maybe it
shouldn't be added.
So basically if the speed increase isn't necessary maybe it's better to leave it
the way it is and use RHS evaluation and simply replace '$' with "length()".
