OpenEuphoria

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