1. Re: Short-Circuit
I awakened in the dead of night with the nagging feeling that I had better
consult the archives, to determine how correct my recollections were about
Robert, myself, and the short-circuit debate back in 1998.
As it turns out, I was wrong about major facts, and I owe Robert an apology.
I misrepresented him, his actions, his character, and myself. For this, he
has my sincere apology.
I should have looked things up first, instead of guessing.
The facts, from the archive:
[ I opposed short-circuiting ]
I had claimed to be one of those in favor of short-circuiting, but the facts
state otherwise. On June 23, 1998, I wrote:
> I am NOT in favor of short circuiting.
That's right. I was *against* it. Didn't ask for it, didn't want it. Never
rallied for it. I understood why it was desireable, but wrote that I wanted
sequence slicing to be made "safe" instead.
[ Robert was initially for short-circuiting ]
I had described Robert as being stubbornly against short-circuiting. Again,
the archives showed otherwise.
The earliest request I found for short-circuiting came from Einar Mogen, on
September 15, 1997. Unlike my recollection, Robert's reaction was not
entirely opposed to the idea:
> You are correct. Euphoria does not do "short-circuit"
> evaluation of and/or/not conditions. I have this on my
> list of desirable features, but it might not happen for
> a while, if at all, because:
>
> 1. It's hard to retrofit this in to ex.exe.
>
> 2. It would break some people's existing code ...
>
> 3. Euphoria's conditional expressions can
> involve sequences, as well as atoms ...
[ Robert quickly adopted short-circuiting ]
I had recollected that there had been a long, protracted battle to add
short-circuiting to Euphoria. This isn;t supported at all by the archives.
On June 21, 1998, Robert wrote his opposition to the idea:
> I've written a lot of code in C, and I like the
> "short-circuit" evaluation of AND/OR conditions.
> For this reason I recently spent a lot of time
> investigating how to add this to Euphoria.
> My conclusion:
>
> * it's rather difficult to add to the current Euphoria
> parser
>
> * if I change AND and OR to operate in the short-
> circuit manner, existing programs will break. ...
>
> * I don't really want to introduce 2 new keywords
> that have almost the same meaning as AND
> and OR. This is supposed to be a simple language.
>
> * Euphoria is not like C. Euphoria has boolean
> expressions where the result can be an atom *or a
> sequence* ... The evaluation of boolean expressions
> would have to depend on the context (condition vs.
> assignment or other expression.). That makes me
> uncomfortable.
>
> Bottom line: I'm not planning to proceed with this.
When Jiri urged him to reconsider:
> Small price to pay. Please, break them!
Robert replied June 22 - the very next day - that he would give it a shot:
> I'm going to take a harder look at this. I'm starting
> to think that the implementation won't be that difficult.
> Also, I could issue a warning in cases where old
> code might break, i.e. where a function with
> side-effects is called to the right of "and" or "or"
> in a boolean expression.
Andy Kurnia then led a heated argument pushing for short-circuiting,
supported by Jacques Guy, Jiri Babor, and Joe Phillips. Those opposing were
primarily worried about old code breaking.
As I noted before, my name was on the "opposing" roster.
On June 25, 1998, Robert wrote:
> I think the subject has been beaten to death
> on this list in the past week. I don't really need
> any more feedback unless someone can think
> of a totally new angle to the problem. I am still
> leaning strongly towards doing it. I am more
> concerned right now with details, like how to
> define it in the most clear, consistent way, given
> that Euphoria AND/OR expressions can produce
> sequences as results, not just atoms (like C and
> other languages).
On June 30, 1998, Robert then wrote the after determining that he couldn't
find *any* code on the RDS site that would break because of the code change:
> I implemented short-circuit evaluation
> of "and" and "or" whenever these occur in
> a "conditional expression" - that's one of the
> following 3 cases:
>
> if condition then ...
>
> elsif condition then ...
>
> while condition do...
>
> Full evaluation will continue to happen
> everywhere else.
Again, I apologize to Robert. It was wrong of me not to check my facts
first, especially when making claims against his character.
-- David Cuny
