Re: $ shorthand side-effect (was Digest for EUforum at topica.com, issue 6333)
Robert Craig wrote:
>
> Chris Bensler wrote:
> > Robert Craig wrote:
> > > Chris Bensler wrote:
> > > > The point is that the problem of side-effects is now much worse,
> > >
> > > I wouldn't say it's worse, just different.
> > > And at least now it's better documented. Other languages,
> > > such as C/C++ leave the order of operations in this case
> > > deliberately undefined, and in fact there are incompatible
> > > differences between C/C++ compilers.
> >
> > Ok, I'll agree with that. It's not much worse, just much more prevalent.
>
> Why do you say it's more prevalent?
> An ambiguous (and rare) situation is now being handled
> differently. No new ambiguous situations have been created.
It's more prevalent because of how you changed the order of evaluation.
IMO, the previous behaviour was more logical. That is all. It now requires more
thought to determine if there will be side-effects.
> > Either way, the behaviour is still undefined.
>
> But at least now the manual states clearly that it
> is not defined, rather than being silent on the issue.
True. Thank you :)
> > afaik the same functionality could be implemented with a
> > 1 to 1 translation to length().
> >
> > I have done this in my preprocessor. No backend modifications required.
> > Is there something I have missed?
>
> Consider:
>
> x[i][j][1..$-1] = 0
>
> the [i] and [j] subscript operations are performed *once*.
>
> I assume your preprocessor would convert this to:
>
> x[i][j][1..length(x[i][j])-1] = 0
>
> So now you have to perform the [i] and [j] subscripting
> operations *twice* each (and what if i is actually a call
> to a function with side-effects?)
Correct.
Yes the subscript operation would be performed twice.
That's how we did it before and how we do it without using $ isn't it?
If [i] were a function call. The programmer would probably assign the result to
a temporary variable for use in the subscript operation to avoid possible
variances in the results of each call or to avoid the extra call for the sake of
efficiency.
i = obj_id("foo")
x[i][j][1..length(x[i][j])-1]
> To implement $ efficiently, it was necessary to adopt
> a left to right evaluation order for subscripts and not
> allow the rug to be pulled out when some function with side-effects
> decides to completely change the lhs var midstream. If you need
> more detail on this, I can probably dig out my old notes, but rest
> assured, I did not break compatibility without exploring all
> reasonable alternatives.
That's fine. Either I don't fully understand why it was nessecary to change how
subscripts were handled or it's just a matter of preference.
Either way, it's not practical to try and change it back seeing as there has
been major internal changes to the subscripting. The new behaviour still prevails
regardless if $ is used now.
It's certainly not a back-breaking issue anyways.
I don't want to make you do work just for the sake of interest.
Thanks for chiming in though.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
|
Not Categorized, Please Help
|
|
