1. Re: Andy and Pete, about :=
Hello...
Indeed, Pete's solution does the job (thanks a lot for the fast,
efficient answer!). It means that the ordinary while loop has to be
transformed into a "do" loop; why not, it is not too confusing. It
departs from the original programmer's standpoint, and, IMO, a language
is all the better when it avoids this structure translation process.
The problem of bugs related to same-looking, same-context symbols (like
"=" and "==" in C) could be avoided with a good syntax highlighting
program editor. ed's handling of delimiters and other non-identifiers
could be critical here.
Also, if the allowable syntax is only
<single var, without even an index>:=<anything but a single var without
even an index>,
the cases where you could forget the extra symbol and still get a legal
statement reduce to situations where it wouldn't be very useful; I'm
wondering if there's any.
If a function has intentional side effects, so be it, and the
programmer must realize it is executed each time it appears in code,
whether to explicitly use the result or not. The issue here is not the
construct, IMO, but the edge effects in functions, which often generate
hard to find bugs.
Since ':' is not a legal character in identifiers, and a namespace must
be followed by an identifier, inside which '=' is not legal either,...
where would be the trouble incorporating this in existing code?
Regards
CChris
---Original message
> Date: Mon, 16 Sep 2002 19:44:47 +0000
> From: Andy Serpa <renegade at earthling.net>
> Subject: RE: Technical question, somehow related to Inner loop compiler
>
> Christian.CUVIER at agriculture.gouv.fr wrote:
> > Hi, all EUpeople! Back on the air again after a while off...
> >
> > Assume I have the following code in a program:
> >
> > while f(args1)!=g(args2) do
> > ....
> > end while
> >
> > f and g may be slow to compute, and the loop may use these values. So,
> > an obvious way to code would be:
> >
> > while f(args1)!=g(args2) do
> > x=f(args1)
> > y=g(args2)
> > ....
> > end while
> >
> > But it means computing again those functions.
> >
> > My question: Does the interpreter optimize for this, so that x and y
> > are assigned the values that are somewhere in a temporary variable,
> > instead of recomputing? If this is not so, it may sound as a good idea
> > to add this feature, doesn't it?
>
> Actually, that wouldn't be appropriate in the case of a function,
> because a function may have (intentional) global side-effects
> (incrementing a global variable, for instance).
>
> Combining an assignment with a comparison would be handy in certain
> cases (like a while loop), but would mean adding ":=" or "==" operators
> which would be hard to incorporate into existing code. One fact not
> pointed out all that much is that the existing implementation avoids a
> lot of easy-to-make bugs. (It is very easy to forget that extra "=" in
> the "==" operator in languages that allow it, and since both are
> generally legal in the same spots, they are hard bugs to find.)
>
