OpenEuphoria

Re: Short Circuit

• Posted by David Cuny <dcuny at LANSET.COM> Oct 07, 2000
• 733 views

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