Re: Short Circuit
Robert Craig wrote:
> 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.
First, thanks for responding. The tone of my e-mail wasn't exactly cordial.
I wasn't simply aiming this at you: I was hoping for a larger response than
the usual vocal handful.
Even after reading through your responses several times, I remain convinced
that *most* people would prefer comparison operators to return boolean truth
values. But the underwhelming response to my posting leads me to think that
most people aren't as unhappy with the current behavior as I thought.
There's certainly not been any great show of support that would convince you
(or me, if I were in your place) that breaking existing code to add my
requested features would be worth the pain it would cause. *sigh*
(Actually, at this point in the day, most votes seem to be *against* me)
> introduce a bunch of exceptions
It's not clear to me what these 'exceptions' are. As I've pointed out, I
*think* most people expect 'and', 'or' and the comparison operators to
return boolean values. Even the C coders that you mention don't expect the
kind of behavior that Euphoria provides. Perhaps the APL people remain
unsuprised.
> Wrong. Try:
>
> ? {1,2,3} = {{1,1,1}, {0,0,0}, {3,2,1}}
Yes; I was (literally) in the middle of admitting to Kat that I had
misunderstood how sequence equality works. I stand corrected. My confusion
stems from performing the following test:
? {"cat"} = {"pizza"}
and getting an error message when I had expected it to return:
{0}
> 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
It's a valid example, but I should have given you the example of the bitmap
'trick' to explain what I was talking about. The bitmap 'trick' replaces all
the colors in a bitmap with a new color:
mask = ( bitmap = color )
bitmap = (bitmap * not(mask)) + ( mask * newColor )
What it has in common with your example and Matthew's is that it relies on
multiplying a boolean value by some constant to work. I think it's
significant that all three examples rely on abusing booleans (by multiplying
them) in order to do useful work. In my mind, that places them in the
'trick' category.
Since I'm a bit grumpy, I'll point out that 'upper' relies on the ASCII
character set, and is only valid for languages that uses the Roman alphabet;
I'm waiting for someone to complain when they use Win32Lib with a foreign
language.
And yes, I spelled "challenge" wrong.
>> (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")
Michael Nelson also picked this, but I'll disagree with this: the 'find'
operation most certainly is a loop, if only indirectly. And the example only
returns the index of the *first* difference; which is rather atypical.
The example also relies on both sequences being the same size. So you can't
generalize it to something like, say, string comparison operations. I'd hate
to select that as a strong explanation as to why comparison operators should
be orthogonal.
>> (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().
What about people using Perl, JavaScript, Python, and other languages?
I wouldn't use the word 'happily' either to describe a C coder using strcmp.
Strings aren't first-class citizens in C. There was quite a bit of rejoicing
with C++ with the advent of real string classes, and an overloaded '=='
operator.
So I have great difficulty imagining a C coder being 'happy' to discover
that Euphoria uses a 'strcmp' sort of function for comparisons.
> 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.
I was one of those proponents of short-circuiting. My recollection (which
could be entirely wrong, since I didn't check the logs) was that you were
unconvinced that Euphoria actually needed short-circuiting operations:
1. It was redundant, since it could be simulated by nesting conditional
tests.
2. It would make the language more complex.
3. Few people were asking for the feature.
4. It wouldn't be backwards compatible.
The decision of how to code it wasn't a group consensus - you decided that
breaking large amounts of code wasn't an option, and chose that particular
implementation. That's a compelling reason to take that route, but I
wouldn't conclude that "No one seemed concerned about it."
>> (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.
If you were to provide some sort of with/without keyword, there would be no
need for code to break. I don't think it's an optimal solution, but it's
better than nothing.
> Breakage may not bother someone like
> yourself who is aware of the changes
> from one release of Euphoria to another.
Breakage *is* a real issue for me. I don't expect any suggestion that even
mildly changes the existing codebase to be entertained unless it presents
compelling benefits. After all, Euphoria is how you make your living.
Some suggestions (like the for/else/end for) are more whimsy than anything
else, but I take this particular suggestion quite seriously. It appears I'm
in the minority, though.
> They don't want to have to search through old
> code for statements that are not aesthetically
> pleasing to David Cuny.
How many people code like this:
if compare( ... ) = 0 then
after they discover the 'equal' function? I certainly don't. I doubt even
the most brilliant C coder is going to bother once they find a shorter,
safer way to code it.
This isn't about 'aesthetics', it's about usability. I don't write these
things because I like to irritate you (or anyone else). I'd prefer to stay
on everyone's good side - especially yours!
But I'm convinced that the '=' operator is a continual source of frustration
- not just for me, but for people who intially try the language, and then
drop it and never become paying customers.
Unfortunately for my hunch, there's not much information either way to show
that people really care, either to prove me right, or to disprove me.
[ Summary, of Sorts... ]
Despite your arguments for "orthogonality", I don't find the examples that
you've presented compelling reasons for having comparison operators return
sequences. The first relies on multiplying booleans; the other is a special
case that can't be extended to more general cases. They certainly aren't the
sort of things I'd expect someone to do on a regular basis.
In contrast to those rare beasts, equal() is the bread and butter of
sequence operations. Back in the dawn of Euphoria, you decided on
"orthogonality" over more general usability. I think this was a bad call,
but I appear to be a voice in the wilderness on this.
Because of this decision, there's a mountain of code that might break if you
change it. As Michael Nelson noted,
> "For me, the deciding factor is that changing =
> (and >, >=,<,<=, and !=) would break too much
> existing code."
Despite the mounting pile of votes against me, I remain convinced that there
should be a first-class operator for sequence comparisons.
-- David Cuny
|
Not Categorized, Please Help
|
|
