Re: Digest for EUforum at topica.com, issue 6333
Chris Bensler wrote:
>
>
> Again. It was an example only.
> It's not a matter of what a person would rely on, but what you would logically
> expect. Following codeflow, you should be able to read the code and follow
> what
> is happening. That was more or less possible before. Now we have to scrutinize
> every assignment to be sure it won't cause side effects.
> Fine, yes, it would be better to split the statement anyways, regardless of
> the
> presence of the $ shorthand, but who does?
>
> I don't depend on it, but I really don't want to have to think about it so
> much
> either. I'm SURE I'm not alone in having made that assumption. I'm sure, other
> than the fact of it being brought up. The majority of people are entirely
> unaware
> of any problem at all.
The problem with the assumption is that it doesn't stand up to scrutiny.
I can understand how it was initially made, but a bit of thought should
raise a red flag. You've got an assignment statement going into a sequence,
but you're fiddling with the sequence inside of the function (or in something
it calls) before you actually assign it. There's not an obvious way to
resovle the 'race condition' of when does the subscripting happen. The
way it worked before wasn't documented, so while I can understand the
confusion when it stopped working, the bottom line is that you were relying
on something that was undocumented, and that isn't clear how it should
work anyways.
From the manual:
"...do not try to modify the lhs_var in two different ways in the same
statement."
That makes a lot of sense to me. You have to ask yourself, which one
will be final? It's now defined to be undefined, so if you rely on
some behavior, you might get a nasty surprise (as you already did when
the behavior changes).
> I'm curious what other languages have problems like this with side effects.
> If I had discovered the problem with side-effects when I began using Eu, I
> probably
> never would have even persued it.
I'm sure they all act differently, and maybe even inconsistently, once
compiler optimization occurs.
> I've been debugging programs without IL for 8 years now.
> Eu is not C. Do you ever have to look at low level code when you use PHP or
> python or Perl, etc?
The only one I use is perl, and I'm not aware of a way to get that level
of detail (of course, I haven't even used the perl debugger, so my knowledge
is far from complete). I can definitely tell you that I would like to
see that detail. It's certainly helped me a lot with Eu, and with C/C++
to be able to see exactly what's going on. It really shortened the
learning curve.
> I think you may be thinking of a different post and poster.
Probably true. Sleep has been hard to come by lately...
Matt
|
Not Categorized, Please Help
|
|
