OpenEuphoria

Re: Short Circuit

• Posted by Derek Parnell <dparnell at BIGPOND.NET.AU> Oct 07, 2000
• 763 views

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