Rob: Q: Re: Major Bug in Interpreter [Attn: Robert Craig]
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 13, 2005
- 486 views
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!!!