Re: Major Bug in Interpreter [Attn: Robert Craig]
- Posted by Derek Parnell <ddparnell at bigpond.com> Feb 13, 2005
- 499 views
Mario Steele wrote: > > Hello All, > > 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 should be pretty self explainitory, but incase your wondering, stack > is a top-level variable, not a temporary variable. when running through > recursion calls, the last sequence to be added to the list, get's free'd, > voided, or whatever, then it drops off the sequence list after the recursion > call is completed. This shouldn't be happening, cause... again, stack is > a top-level variable. > > I have confirmed that 2.5 Beta is the one I'm using when this happens, if > anyone else wants to test, feel free to. > > The way the sequence SHOULD look after the exit of all recursion calls: > stack = { {2,0,1,0}, {0,3,1,0}, {0,0,1,0} } > > The way the sequence DOES look with 2.5 Beta: > stack = { {2,0,1,0} } Technically speaking its not a bug, in the sense that it is not failing to meet specifications. I will defend Robert's right to implement Euphoria with this behaviour, namely that from v2.5, Euphoria evaluates the left hand side (LHS) of an assignment before it evaluates the RHS. Even though no major language does this (they evaluate the RHS first then the LHS), Robert has the right to have Euphoria do what he likes. The reasons for him doing this aren't even relevant, because regardless of why he has choosen to change the behaviour of Euphoria, he has every right to do it. If any mistakes have been made, it could be that RDS has not documented this behaviour (i.e. specified it), and that RDS has not explicitly brought to our attention this change in behaviour. These are oversights that I'm positive will be rectified before the final release. It is not unreasonable for people to assume that RHS-before-LHS evaluation would be done, as this is the normal or common approach used in major languages such as C, C++, C#, Java, VB, COBOL, Pascal, Fortran, etc... It just needs to be clearly documented, with examples of how to make it work like we all expect, for us to move forward. I think we all agree that Euphoria is not a conventional language, in that it does do a few things that other languages do not do. For example the notable "if seq = seq then ..." syntax. Other languages regard this as a comparision operation, but Euphoria treats it as a sequence creation operation. So the precedent has been set for Euphoria to do things in a different manner from what we are accustomed to in other languages. The "work around" is to ensure that the LHS has no evaluations to be done that could be influenced by the RHS. So in your example code above, you could write ... if stack[ib][i] = 0 then lLocalTemp = recursive_call(i+1) stack[ib][i] = lLocalTemp end if However, now that this new behaviour has been brought to light, I will need to inspect Win32lib to make sure I'm not doing the undocumented thing. -- Derek Parnell Melbourne, Australia irc://irc.sorcery.net:9000/euphoria