OpenEuphoria

Short Circuit

• Posted by "Cuny, David at DSS" <David.Cuny at DSS.CA.GOV> Oct 04, 2000
• 825 views

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