1. Short Circuit
I got bitten by the conditional short-circuit with the following code:
function test( sequence s1, sequence s2 )
return length( s1 )
and length( s2 )
and match( s1, s2 )
end function
Yes, I know that it's clearly documented, and I recognized the error once I
traced through the code. But, IMNSHO...
To my way of thinking, 'or' means 'conditional or'. So Euphoria's performing
a 'sequential or' is a suprising behavior. If I wanted to 'or' a sequence,
I'd expect to write:
s = or( 1, s )
After all, we already have 'or_bits' to distinguish bitwise operations. Why
not have a function to distinguish sequence operations? How about:
s = or_seq( o1, s1 )
s = and_seq( o1, s1 )
s = not_seq( s1 )
s = compare_seq( o1, s1 )
s = equal_seq( o1, s1 )
These are not operations that are typically performed, so it doesn't add
much burden to the coder.
The comparison operators:
and or not = > >= != < <=
would *always* return a boolean value, and the booleans:
and or
would *always* perform short-circuiting. The following would be legal:
if "foo" = "bar" then
if "foo" > word then
i = length(s1) and length(s2) and find(s1,s2)
and the following:
s = "foo" and 1
s = not "foo"
would result in a run-time error:
expected an numeric value, not "foo"
Clarity, consistancy, and the removal of a common stumbing block I think
this would be a *huge* win for Euphoria. Even after using Euphoria for
years, I still write comparisons like this:
if "foo" = ^H^H^H^H^H^H^H equal("foo" ...
-- David Cuny
2. Re: Short Circuit
I suspect that I had been a bit confusing in my initial post, so I'm going
to take another stab at this again. No 'sequential or's in this post; I'll
try to restrict myself to real terms. I'll also be *much* less subtle,
sorry.
[ The Problem ]
Euphoria allows logical and comparison binary operators to return sequences.
For example:
and
or
=
In the case of some operations, this is sensible. For example, the standard
math operators *should* with sequences. It makes sense to
add/subtract/multiply/divide two sequences.
The behavior of the '=', 'and' and 'or' is another matter entirely.
(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. I challange anyone to find me an example where this
is actually useful, other than for performing obscure tricks with bitmaps.
(Sorry, no prizes will be given to the winning entries.)
(2) Even if the behavior was useful, you *still* need to build a loop to
scan through the results. So instead of writing:
s = ( s1 = s2 )
for i = 1 to length( s ) do
if s[i] then
-- some code here
end if
end for
you could just as easily write:
for i = 1 to length( s ) do
if s1[i] = s2[i] then
-- some code here
end if
end for
So there's no real benefit of returning the comparison results as a
sequence.
(3) The code shouldn't return an error. To be consistant (for example, with
'gets'), it should return an integer on failure, and a sequence on success.
(4) The '=' operator doesn't work the way people want it to. And, in the
end, the needs of the users should drive the design of the language, not the
other way around.
I've focused on the '=' operator, but similar arguments can be made for
changing the behavior of 'and' and 'or', with this additional argument:
(5) Short-circuiting should be consistant. It goes against the basic idea of
Euphoria (and simple consistancy) to have a keyword sometimes do one thing,
and sometimes do another.
[ The Solution ]
The solution is simple, and would break very little code. The result would
make Euphoria easier to use, more consistant, and less prone to errors. I
would think this would lead to More Happy Customers, which would be
beneficial to RDS.
(1) Change the behavior of '=' so it acts like 'equal'. It (and it's kin)
only return boolean integer values.
(2) Add the following functions to replace the old '=' behavior:
compare_seq( o1, o2 )
equal_seq( o1, o2 )
(3) Change 'and' and 'or' so they only accept integers, and only return
boolean integers.
(4) Add the following functions to replace the old functionality:
and_seq( o1, o2 )
or_seq( o1, o2 )
(5) Change short-circuiting so it always occurs.
Comments?
-- David Cuny
3. Re: Short Circuit
No complaints here. Its not exactly what I've asked for but its very good.
I'll vote for these ideas.
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, October 06, 2000 10:45 PM
Subject: Re: Short Circuit
> I suspect that I had been a bit confusing in my initial post, so I'm going
> to take another stab at this again. No 'sequential or's in this post;
I'll
> try to restrict myself to real terms. I'll also be *much* less subtle,
> sorry.
>
> [ The Problem ]
>
> Euphoria allows logical and comparison binary operators to return
sequences.
> For example:
>
> and
> or
> =
>
> In the case of some operations, this is sensible. For example, the
standard
> math operators *should* with sequences. It makes sense to
> add/subtract/multiply/divide two sequences.
>
> The behavior of the '=', 'and' and 'or' is another matter entirely.
>
> (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. I challange anyone to find me an example where
this
> is actually useful, other than for performing obscure tricks with bitmaps.
>
> (Sorry, no prizes will be given to the winning entries.)
>
>
> (2) Even if the behavior was useful, you *still* need to build a loop to
> scan through the results. So instead of writing:
>
> s = ( s1 = s2 )
> for i = 1 to length( s ) do
> if s[i] then
> -- some code here
> end if
> end for
>
> you could just as easily write:
>
> for i = 1 to length( s ) do
> if s1[i] = s2[i] then
> -- some code here
> end if
> end for
>
> So there's no real benefit of returning the comparison results as a
> sequence.
>
> (3) The code shouldn't return an error. To be consistant (for example,
with
> 'gets'), it should return an integer on failure, and a sequence on
success.
>
> (4) The '=' operator doesn't work the way people want it to. And, in the
> end, the needs of the users should drive the design of the language, not
the
> other way around.
>
> I've focused on the '=' operator, but similar arguments can be made for
> changing the behavior of 'and' and 'or', with this additional argument:
>
> (5) Short-circuiting should be consistant. It goes against the basic idea
of
> Euphoria (and simple consistancy) to have a keyword sometimes do one
thing,
> and sometimes do another.
>
> [ The Solution ]
>
> The solution is simple, and would break very little code. The result would
> make Euphoria easier to use, more consistant, and less prone to errors. I
> would think this would lead to More Happy Customers, which would be
> beneficial to RDS.
>
> (1) Change the behavior of '=' so it acts like 'equal'. It (and it's kin)
> only return boolean integer values.
>
> (2) Add the following functions to replace the old '=' behavior:
>
> compare_seq( o1, o2 )
> equal_seq( o1, o2 )
>
> (3) Change 'and' and 'or' so they only accept integers, and only return
> boolean integers.
>
> (4) Add the following functions to replace the old functionality:
>
> and_seq( o1, o2 )
> or_seq( o1, o2 )
>
> (5) Change short-circuiting so it always occurs.
>
>
> Comments?
>
> -- David Cuny
4. 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.
> (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}}
> 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
> (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")
> (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().
> (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.
> (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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Short Circuit
On 6 Oct 2000, at 4:45, David Cuny wrote:
I can't believe i have some points to counter you on, David..
<snip>
> (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. I challange anyone to find me an example where this
> is actually useful, other than for performing obscure tricks with bitmaps.
if ( c:\file.orig = q:\file.bak ) then erase( c:\file.orig ) end if
> (Sorry, no prizes will be given to the winning entries.)
Drat.
> (3) The code shouldn't return an error. To be consistant (for example, with
> 'gets'), it should return an integer on failure, and a sequence on success.
Agreed,
if ( operator(x,y) != error )
then -- working code
else -- error recovery code
end if
But,, what will the error code be that cannot be returned by a valid legal
comparison?
> (4) The '=' operator doesn't work the way people want it to. And, in the
> end, the needs of the users should drive the design of the language, not the
> other way around.
YEA!!,, like having a goto ! Thanks, David 
> (5) Short-circuiting should be consistant. It goes against the basic idea of
> Euphoria (and simple consistancy) to have a keyword sometimes do one thing,
> and sometimes do another.
Short circuiting should be transparent to the programmer/user. I set it 'on' in
Pascal of
years, and saw no difference other than speed.
> (1) Change the behavior of '=' so it acts like 'equal'. It (and it's kin)
> only return boolean integer values.
Despite my initial thought of returning a percentage of trueness, a binary
true/false is
the best way, trueness otherwise would be too subjective.
> (2) Add the following functions to replace the old '=' behavior:
>
> compare_seq( o1, o2 )
> equal_seq( o1, o2 )
RPN? Ptui. Why not plain old
if ( o1 = o2 ) then -- code -- end if
> (3) Change 'and' and 'or' so they only accept integers, and only return
> boolean integers.
Ewwww, that could kill off video effects manipulation! Errr,, unless you are
counting a
bitmap as one huge integer. Subsequences are a different matter, prolly.
Kat
6. Re: Short Circuit
David Cuny writes:
> (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. I challange anyone to find me an
> example where this
> is actually useful, other than for performing obscure tricks
> with bitmaps.
>
> (2) Even if the behavior was useful, you *still* need to
> build a loop to
> scan through the results.
<snip>
OK, here's an example. It's not exactly what you're looking for (it uses
'<' and '>' instead of '='), but:
This function is used in some integer programming code of mine. I'm testing
to see if a solution is made up of integers. And no, I can't use integer(),
since I'm solving using numerical methods, and I have to take a tolerance in
account. Actually, the code is looking at two cases, straight integer
programming, and binary integer programming (all variables must be either 1
or 0), in which case I've set BIN to 1.
function Integer( sequence solution, integer vars)
-- solution = max/min, variable values for proposed solution, objective
function value
-- vars = number of variables
solution = solution[ 2 .. vars + 1 ]
if BIN then
solution = 1 - ( solution < TOL ) - ( solution - 1 > - TOL ) *
( solution - 1 < TOL )
else
solution = remainder(solution,1)
solution = (solution > TOL) * ( solution < 1 - TOL )
end if
return not find(1,solution)
end function
As you can see, not only was the operator very handy, but I used find() to
avoid looping through the sequence. Frankly, it was the flexibility
sequences gave me in this type of application that really sold me on Eu.
7. 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
8. 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
9. Re: Short Circuit
Kat wrote:
> I can't believe i have some points to
> counter you on, David..
Sorry I took so long to respond to this; my reply got lost in the shuffle.
> if ( c:\file.orig = q:\file.bak ) then erase( c:\file.orig ) end if
I think you misunderstood my question. You currently can't do that sort of
thing without the Euphoria aborting *unless* the sequences are exactly the
same length. I consider this to be undesirable behavior.
> But,, what will the error code be that cannot be
> returned by a valid legal comparison?
This is a digression that I'm not terribly interested in, but since I was
the one that brought it up, I'll go ahead and follow through. If you accept
that this hypothetical comparison routine should always return sequences,
then returning an integer value instead of a sequence would flag an error.
This would be akin to gets(). The *value* returned isn't really interesting,
the *type* is what serves as an error flag.
> YEA!!,, like having a goto ! Thanks, David
I have to admit, having a unconditional jump out of a routine would be quite
handy sometimes. I've currently got a recursive descent parser, and when it
encounters an error, it then triggers an error at every level as it unwinds
back through the parse tree... ouch!
> Short circuiting should be transparent to the
> programmer/user. I set it 'on' in Pascal of
> years, and saw no difference other than speed.
I'm not sure what you mean by 'transparent', but it makes a functional
difference. Consider this example:
if length( s )
and s[1] = 'a' then ...
If you pass an empty sequence to the test, and there is no short-circuiting,
the code will cause Euphoria to abort. It will perform the first test
successfully:
if length(s) => 0
but the second will get an out of bounds error, because s[1] is greater than
the length of the sequence:
and s[1] = 'a' => program aborts
On the other hand, if short-circuiting is active, if the first condition is
false:
if length(s) => 0
then the interpreter doesn't even bother to perform the second test (thus
the name 'short circuit'). So it's not just a question of the code running
faster - with short circuiting, the code actually behaves *differently*.
> Despite my initial thought of returning a percentage
> of trueness, a binary true/false is the best way, trueness
> otherwise would be too subjective.
You'll have to wait for my 'quark' language, which allows you to not only
specify 'truth' operations, but 'beauty' and 'charm' as well. 
> > (2) Add the following functions to replace the old '=' behavior:
> >
> > compare_seq( o1, o2 )
> > equal_seq( o1, o2 )
>
> RPN? Ptui. Why not plain old
>
> if ( o1 = o2 ) then -- code -- end if
More confusion on your part, I think. It's a good thing I'm not a technical
writer. I think Derek did an excellent bit clarifying my post. See my next
comment.
> > (3) Change 'and' and 'or' so they only accept
>> integers, and only return boolean integers.
>
> Ewwww, that could kill off video effects manipulation!
Which is why I suggested compare_seq() and equal_seq(), so you could still
do those cool tricks if the behavior of '=' was changed.
Does that clarify things at all?
Thanks!
-- David Cuny
10. Re: Short Circuit
On Fri, 06 Oct 2000, David.Cuny at DSS.CA.GOV wrote:
>
> 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.
>
I think most people would welcome any change which would make Euphoria
simpler and more balanced (Rob's famous "orthogonality")
He speaks disparagingly of "introducing a bunch of exceptions that people
will have to remember", while ignoring the fact that people already have to
remember the following exceptions:
x = 1 -- valid
x = "HELLO" -- valid
if x = 2 then -- valid
if x = "HELLO" -- invalid
So what is this if not an "exception" ?
It's not the only one, by any means.
Along the same lines, Rob has repeatedly refused to see any need for structures
in Euphoria, even though the vast majority of the programs being written are
for Windows or Linux, both of which REQUIRE the passing of C structures in
order to do anything useful. Since we currently have no structures, there is
obviously no code to "break", so why not just implement plain C structures into
the core language, and do away with all the hassles of peeking, poking,
allocating, freeing , etc.?
Irv
11. Re: Short Circuit
On 8 Oct 2000, at 9:27, Irv wrote:
> I think most people would welcome any change which would make Euphoria
> simpler and more balanced (Rob's famous "orthogonality")
> He speaks disparagingly of "introducing a bunch of exceptions that people
> will have to remember", while ignoring the fact that people already have to
> remember the following exceptions:
>
> x = 1 -- valid
> x = "HELLO" -- valid
>
> if x = 2 then -- valid
> if x = "HELLO" -- invalid
>
> So what is this if not an "exception" ?
This one also begs for a one line test in the interpreter, in the same code that
tiggers
the error for that line: if the error is that it's a sequence, send it to
equal(x,"hello") ,
sheesh, don't error out!!! And if you run across a ":=" or a "==", go do the
assignment
part of "=", Rob!
> It's not the only one, by any means.
>
> Along the same lines, Rob has repeatedly refused to see any need for
> structures
> in Euphoria, even though the vast majority of the programs being written are
> for Windows or Linux, both of which REQUIRE the passing of C structures in
> order to do anything useful. Since we currently have no structures, there is
> obviously no code to "break", so why not just implement plain C structures
> into
> the core language, and do away with all the hassles of peeking, poking,
> allocating, freeing , etc.?
/me looks at the listserv title: Euphoria Programming for MS-DOS
Kat
