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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Pete E wrote:
> So how about for the cases where the $ operator is not used, revert to 
> the previous method of subscripting (as in 2.4) so that programs that 
> require backwards compatibility will not break?
> 
> If the subscripting does use $, then use the efficient method that 
> refcounts (protects) the LHS variable.  We don't care about backwards 
> compatibility in this case, since the $ operator is new to version 2.5.

That would assist in getting over the current
compatibility glitch, but what happens when someone in the future 
changes from using length() to using $ or vice versa, and 
mysteriously the order of expression evaluation changes? 

It also means more maintenance cost, as I would have two sets of 
subscripting ops to maintain. I'd also have to document two 
sets of rules in the manual, causing groans from future Euphorians.

I know that you and anyone else who actually encounters this glitch
will favour changing the interpreter (and translator) to make
things backwards compatible, but if you step back and think about
what you are doing, you'll realize it's pretty weird (and rare).
In one Euphoria statement you are modifying a variable via 
multiply-subscripted assignment, while at the same time you are also 
modifying the same variable via a function call with side effects. 
While the manual is silent on what should happen in this case, 
there is a general expectation of left to right evaluation, 
which would tend to make you think the lhs subscripting would be 
evaluated first, based on the original value of the lhs variable. 

The fix is simple - just split the statement into two statements
and let your readers clearly see what operation happens first.
I think that most code that uses this "technique" will break
pretty quickly under 2.5. I don't think you'll 
have a "ticking time bomb".

The extra ref count also protects against code that calls a function 
with side-effects, modifying the variable I'm in the process of 
subscripting, from inside one of the lhs subscript expressions, 
not just on the rhs.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu