Rob: Q: Re: Major Bug in Interpreter [Attn: Robert Craig]
Robert Craig wrote:
>
> 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
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Couldnt you just have made foo[$] translate to foo[length(foo)] in the
Euphoria IL?
-------------------------------------------
Euphoria v2.5 Rocks!!!
|
Not Categorized, Please Help
|
|
