Re: Major Bug in Interpreter [Attn: Robert Craig]
Robert Craig wrote:
> 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.
Okay, all of this I can understand. However, this now just added a new
level of complexity to my code for a OOP library I'm currently developing.
The reason why I brought this up, is cause I'm using a similar routine to
create Nested Objects based apon a decloration of a class.
EG:
Class("MyClassB")
Member("MyVar1",INTEGER)
EndClass()
Class("MyClassA")
Member("MyVar2",ATOM)
Member("ClassB","MyClassB")
EndClass()
constant NewClass = new("MyClassA",{})
Since the new design of Euphoria, makes it impossible for me to correctly
do recursive creation of Sub-Classes, I now have to find a way to create
the sub-class effectivly, cause it seems to me, that anyway I go, according
to the new rules, as soon as I exit a call, the sequence I just added to
the variable, Now dis-appears on me.
About the only way I can make this work, is if I have some kind of construct
routine to create all the nested sequences, and when they are all created,
return it to the caller, and have the caller store the entire sequence into
the variable, in order for the changes to remain constant.
This equals more instructions for the interpreter to execute, and parse,
which will equal slower speeds. Not that I was developing this library for
speed.
Oh well, Back to the drawing board. Maybe I'll come up with something to
make the changes STAY in the variable.
Mario Steele
|
Not Categorized, Please Help
|
|
