OpenEuphoria

1. Rob: Q: Re: Major Bug in Interpreter [Attn: Robert Craig]

• Posted by Vincent <darkvincentdude at yahoo.com> Feb 13, 2005
• 486 views
• Last edited Feb 14, 2005

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!!!

3. Re: Rob: Q: Re: Major Bug in Interpreter [Attn: Robert Craig]

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 14, 2005
• 484 views

On Sun, 13 Feb 2005 14:17:34 -0800, Robert Craig
<guest at RapidEuphoria.com> wrote:

>I've implemented $ efficiently, so it takes advantage of
>the subscripting that has occurred so far (moving left to right),
>rather than recalculating it. 

I see. I would normally expect the subscript values to be evaluated
first of all (before the RHS), so yes, I can see a performance gain

I previously came up with (to my mind) a slightly clearer case:

sequence stack
function fn()
	stack={0}
	return 1
end function

stack[1]=fn()
?stack

In 2.4 this would display {1}, in 2.5 this somewhat more correctly
causes the error "variable stack has not been assigned a value".
Of course stack[length(stack)]=fn() gives the same error in both 2.4
and 2.5.

I only mention this for documentation purposes,
Pete

5. Re: Rob: Q: Re: Major Bug in Interpreter [Attn: Robert Craig]

• Posted by Al Getz <Xaxo at aol.com> Feb 14, 2005
• 460 views

Hi there Rob and others,

I take the code:

sequence s
s[1]=12345

{GENERATES AN ERROR}
to be the 'rule' here, where it's quite logical that you wont be
able to assign anything to a sequence element that simply isnt
there yet!  I've taken this to be the rule since day 1, and im 
quite sure none of my programs have violated this rule because i've
always respected that one rule outlined by those two simple lines
of code.  It doesnt matter to me if you can call a function under
v2.4 and be able to assign to elements that arent there before
the call because i considered it bad practice all along and so avoided
doing this.  It is interesting that you can do this under 2.4
and not 2.5 though, so now i guess the 'rule' will get written in
stone?

In the future perhaps it's better to keep default behaviours though, so as to
give previous users nothing to complain about.  It's a real bother when
you've taken the time to come up with a clever coding solution that takes
advantage of the language to it's fullest extent only to find that several
months down the road it's changed so you cant use your well thought-out
coding scheme anymore.

When i created my dollar sign remover program i assumed $ would
replace 'length()' exactly too.  I made sure i replaced EVERY occurance
of $ with length().  Perhaps this is one program that doesnt work
'exactly' as '$' would under 2.5 ?


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"