Re: Short Circuit
----- Original Message -----
From: "Robert Craig" <rds at ATTCANADA.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, October 07, 2000 4:47 AM
Subject: Re: Short Circuit
> David Cuny writes:
>
> > Euphoria allows logical and comparison binary operators
> > to return sequences. For example:
> > and
> > or
> > =
> > In the case of some operations, this is sensible.
>
> So you'd like to break the simple orthogonality of binary operators,
> and introduce a bunch of exceptions, that people will have to
> remember, into the language definition.
No, no, no, no! You talk of "binary operators" but David is only talking
about "comparision operators". They are not always the same thing. A '+' is
a binary operator because it needs two operands, but it is not a comparision
operator. An '>' is a binary operator, but it is also a comparision
operator. Comparision operations only exist in boolean expressions. Euphoria
is NOT orthogonal with respect to comparision operators. In some situations
these keywords ('>', '<', '=', '!=' , '<=' and '>=') are comparision
operators and in others they are sequence operators. If I say "seq1 > seq2",
am I comparing the two operands to come up with a true/false value or a
sequence of true/false values? Euphoria only allows the second
interpretation. In other words, when these operators are used with sequences
they perform sequence operations, but when they are used with atomic
operands they perform boolean operations.
> > (1) The '=' comparison is worthless. You can only
> > compare sequences that are *exactly* the same in structure,
> > with exactly the same lengths, down to the last nested subsequence.
>
> Wrong. Try:
>
> ? {1,2,3} = {{1,1,1}, {0,0,0}, {3,2,1}}
>
Right! Try:
? {1, 2, 3} = {{1, 2, 3}}
? {1, 2, 3} = {1, {2, 3}}
> > I challange anyone to find me an example where this is
> > actually useful, other than for performing obscure tricks
> > with bitmaps.
>
> global function upper(object x)
> -- convert any atom or sequence (of any complexity) to upper case
> return x - (x >= 'a' and x <= 'z') * TO_LOWER
> end function
Congratulations. This is a neat trick. Most people will not understand what
your doing here until they walk through it a bit. (Pity it only works for
ASCII codes though).
> > (2) Even if the behavior was useful, you *still* need
> > to build a loop to scan through the results.
>
> How about:
>
> find(1, "ABC" = "aBc")
Doesn't this only find the first truth value? David is right if you want to
find all the possible truth values.
> > (4) The '=' operator doesn't work the way people want it to
>
> You mean it doesn't work the way that Basic people expect.
> C people and others would not expect to compare
> strings using '='. In C they happily use strcmp().
Bzzzzt! Wrong answer. I've been using C for 16 or so years (and almost never
used BASIC during that time) and I've NEVER been happy about using strcmp(),
strncmp(), strnicmp(), stricmp() etc... That's why a String class was
devised in C++ so that people could code ...
String X, Y
if (X = Y)
{
...
}
In COBOL one uses such things as...
01 RECORD.
03 fldone pic x(3).
03 fldtwo pic x(4).
. . .
IF fldone EQUALS fldtwo ...
> > (5) Short-circuiting should be consistant.
>
> The fact that there would be a small inconsistency
> when short-circuiting was introduced 2 years ago,
> was discussed at that time. No one seemed concerned about it.
> The alternatives were to:
> a) not have short-circuiting at all
> b) break a lot of code
> c) introduce special new and/or short-circuit operators that:
> - few would bother using
> - that wouldn't speed-up existing code
> - which would confuse people since most of the
> time they'd be equivalent to 'and' and 'or'
>
> Up until now I've only had a few complaints that
> short-circuiting only applies in conditional expressions,
> not all expressions.
My reading of David's note was that he wasn't so much ranting against "short
circuiting" as such, but that sequences could not partake in short ciruiting
using the common operators. I didn't see David asking for short circuiting
in other forms of expressions, just boolean ones.
> > (1) Change the behavior of '=' so it acts like 'equal'.
> > It (and it's kin) only return boolean integer values.
>
> Far too much breakage of existing code.
>
> Breakage may not bother someone like yourself
> who is aware of the changes from one release of Euphoria
> to another. You can go back and correct any
> of your own code, and other people's code in include files
> that you use. But what about the Archive of almost 700 programs?
> What about the less informed people out there who suddenly find
> that their program is failing or behaving strangely, and start sending
> me tech support requests for the next N years? People want their
> existing programs to work. They don't want to have to search
> through old code for statements that are not aesthetically pleasing
> to David Cuny.
Whoa, was that a "low blow"? But I digress...
Let's say that it will break 50% of all Euphoria programs written. Okay,
that is probably too high a cost to bear. So let's just restrict the change
to boolean expressions. That is, add to the language rules so that the
IF/ELSIF/WHILE statements are allowed to have sequences and atoms used with
the normal comparision keywords. That will not break ANY existing code.
Then later, you can start issuing warnings when sequences and comparision
operators are being used in non-boolean expressions. Much later on, you can
remove from the language, the permission to use comparison operators in
non-boolean expressions and start crashing people's old code.
Anyhow, people would obviously prefer to code with Robert's aestehetics
rather than David's. I can see that, can't anyone else? (Just joking. Mine
are better than yours anyway, nah, nah, na, nah, nah ).
-----
TTFN
Derek
|
Not Categorized, Please Help
|
|
