Re: Short-circuit evaluation

new topic     » goto parent     » topic index » view thread      » older message » newer message

Ricardo Forno writes:
> if (a > b) >= (x = z) then ... If a > b is true, then there is no need to
> evaluate x = z.

True, but I don't think I've ever seen an expression like
that used in a real program.

Short-circuiting can only theoretically be performed in Euphoria
when an expression must produce an atom as a result. 
So we know that:
              true or expression is true (without evaluating expression)
              false and expression is false (without evaluating expression)
If expression might yield a sequence, we can't short-circuit.

Short-circuit evaluation could be extended into new areas.
For example, the expression returned from a type...

     type one_item(object x)
         return atom(x) or length(x) = 1
     end type

Right now, length(x) will fail if x is an atom.
With short circuiting, this expression would be ok,
and we can assume that a type must return an atom.
Other cases would include expressions that are assigned
to a variable (or parameter) declared as an atom.

However, people need to remember, preferably 
without consulting the manual, which expressions 
can be short-circuited and which can't. 
I don't want to create a huge section in the manual,
filled with if's, and's and but's, that tries to explain
when short circuit evaluation will be used.
Right now, and/or short circuiting happens for 
control-flow statements -if/elsif/while. In practice,
that covers most of the useful situations.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu