Re: Digest for EUforum at topica.com, issue 6333
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.
Either way, the behaviour is still undefined.
> > for the sake of a very small improvement in speed.
>
> I didn't do the $ feature to gain speed, although it
> does in some cases. I did it because I got tired of
> writing out stuff like:
<SNIP>
I realize that, but 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?
I've not studied the Eu source in depth yet, but I'm sure that it would be
possible.
robert_craig[1..$]
gets properly translated to:
rober_craig[1..length(robert_craig)]
before any execution.
> I wasn't happy when I realized that some existing (weird) code
> would break, and I could have avoided the breakage by making the
> implementation of $ very inefficient in some cases. So inefficient,
> that I would never have implemented $ that way. Many people
> wanted something like $, so I decided to do a proper, efficient
> implementation of it (requiring a huge change to the subscripting code),
> while letting some old, weird, code break.
>
> I personally found one place in Language War that depended
> on the old behavior. It surprised me to realize that the
> code relied on this behavior, because it was not deliberate
> on my part. It was really just luck that it worked.
> Having to split one statement into two was easy, and
> made the logic much easier for anyone else to understand.
Agreed. Splitting the statement makes the code more understandable, but most
times you aren't even aware that you have coded some kind of cyclic assignment.
In the most recent case where I encountered the problem. The culprit function
was one that did the allocation of an object in a list, among other
intializations. It was nested extremely deep and the code was perfectly logical.
Granted it was relic code and I didn't intend to make it to use side-effects. It
just evolved that way.
Hypothetically, disregarding the fact that you've had to modify how subscripts
are handled, if I could implement the exact same functionality, without the
exacerbated problem of the side-effects and ignoring the possibility for a slight
improvement to execution speed, would this be acceptable/desirable?
Since you've had to change how subscripts are handled, I don't know that it's
very feasible to revert and change the implementation, but I'm just curious of
your opinion and perspective on this.
I remember I was pretty gnarly with you for not consulting the community when
2.5 came out and the side-effects issue was brought to light, and that was long
before I ever encountered any problems with it. So it's nothing to do with any
personal reliance on side-effects. It has everything to do with clean and natural
code. I apologize for being so hostile as I can often be, but my opinion hasn't
changed regarding this matter.
Maybe you can explain why it was necessary to change how expressions are
evaluated so that $ could be implemented?
Without inspecting the source, I'm guessing that you implemented $ as runtime
functionality instead of converting it to length() during compile time?
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
|
Not Categorized, Please Help
|
|
