1. Short-cut evaluation Question
Hello everyone!
I've got a question here about short-cut evaluation. As reference here, I'm
using the Linux version of the 2.4 interpreter. I'm pretty sure this is a
bug between my ears as opposed to a bug in the interpreter, but I'd like to
get some clarification on this.
I have the following type declaration:
global type Widget(object o)
if not atom(o) then
return false
else
return (o = 0 or TypesMatch(o, "QWidget") or IsBaseClass(o, "QWidget"))
end if
end type
Now then, in this particular instance I have confirmed via trace that o is
equal to zero. It seems to me that since we are testing using "or" in the
return statement, if any expression in the test evaluates to "true," then the
entire expression would be true. If that is the case, then short-cut
evaluation should stop processing the expression at that point and return
true.
Thus, in the case of the return statement here, the interpreter should see
that, indeed, o = 0, and then return true. But it is not ... it in instead
evaluating TypesMatch(o, "QWidget"), which is causing my library to become
quite upset, since o is a NULL pointer.
Now, it would be easy for me to add the line
elsif o = 0 then
return true
But apparently I'm not understanding something about short-cut evaluation
here. Could anyone enlighten me?
Thanks,
Travis W. Beaty
Osage, Iowa.
--
Infancy, n.:
The period of our lives when, according to Wordsworth, "Heaven lies
about us." The world begins lying about us pretty soon afterward.
-- Ambrose Bierce
2. Re: Short-cut evaluation Question
Travis wrote:
> I've got a question here about short-cut evaluation. As reference here, I'm
> using the Linux version of the 2.4 interpreter. I'm pretty sure this is a
> bug between my ears as opposed to a bug in the interpreter, but I'd like to
> get some clarification on this.
>
> I have the following type declaration:
>
>
> global type Widget(object o)
>
> if not atom(o) then
> return false
> else
> return (o = 0 or TypesMatch(o, "QWidget") or IsBaseClass(o, "QWidget"))
> end if
>
> end type
>
>
> Now then, in this particular instance I have confirmed via trace that o is
> equal to zero. It seems to me that since we are testing using "or" in the
> return statement, if any expression in the test evaluates to "true," then the
> entire expression would be true. If that is the case, then short-cut
> evaluation should stop processing the expression at that point and return
> true.
>
> Thus, in the case of the return statement here, the interpreter should see
> that, indeed, o = 0, and then return true. But it is not ... it in instead
> evaluating TypesMatch(o, "QWidget"), which is causing my library to become
> quite upset, since o is a NULL pointer.
>
> Now, it would be easy for me to add the line
>
> elsif o = 0 then
> return true
>
> But apparently I'm not understanding something about short-cut evaluation
> here. Could anyone enlighten me?
>
> Thanks,
Current Euphoria versions only use short-circuit evaluation in
conditions tested by "if", "elsif" or "while". I.e. if you want
short-circuit evaluation, write the code above like this:
global type Widget(object o)
if not atom(o) then
return false
elsif (o = 0 or TypesMatch(o, "QWidget") or IsBaseClass(o, "QWidget")) then
return true
else
return false
end if
end type
Regards,
Juergen
--
/"\ ASCII ribbon campain | Money is the root of all evil.
\ / against HTML in | Send 20 Dollars for more info.
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
3. Re: Short-cut evaluation Question
----- Original Message -----
From: "Travis Beaty" <twbeaty at osage.net>
To: <EUforum at topica.com>
Subject: Short-cut evaluation Question
>
>
> Hello everyone!
>
> I've got a question here about short-cut evaluation. As reference here, I'm
> using the Linux version of the 2.4 interpreter. I'm pretty sure this is a
> bug between my ears as opposed to a bug in the interpreter, but I'd like to
> get some clarification on this.
>
> I have the following type declaration:
>
>
> global type Widget(object o)
>
> if not atom(o) then
> return false
> else
> return (o = 0 or TypesMatch(o, "QWidget") or IsBaseClass(o, "QWidget"))
> end if
>
> end type
>
Short-cut eval does not work with return. Only with 'if' and 'while'.
>
> Now then, in this particular instance I have confirmed via trace that o is
> equal to zero. It seems to me that since we are testing using "or" in the
> return statement, if any expression in the test evaluates to "true," then the
> entire expression would be true. If that is the case, then short-cut
> evaluation should stop processing the expression at that point and return
> true.
>
> Thus, in the case of the return statement here, the interpreter should see
> that, indeed, o = 0, and then return true. But it is not ... it in instead
> evaluating TypesMatch(o, "QWidget"), which is causing my library to become
> quite upset, since o is a NULL pointer.
>
> Now, it would be easy for me to add the line
>
> elsif o = 0 then
> return true
>
> But apparently I'm not understanding something about short-cut evaluation
> here. Could anyone enlighten me?
>
> Thanks,
>
> Travis W. Beaty
> Osage, Iowa.
>
> --
> Infancy, n.:
> The period of our lives when, according to Wordsworth, "Heaven lies
> about us." The world begins lying about us pretty soon afterward.
> -- Ambrose Bierce
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
4. Re: Short-cut evaluation Question
Hello again!
On Sunday 29 February 2004 02:47 pm, Juergen Luethje wrote:
> Current Euphoria versions only use short-circuit evaluation in
> conditions tested by "if", "elsif" or "while". I.e. if you want
> short-circuit evaluation, write the code above like this:
>
> global type Widget(object o)
> if not atom(o) then
> return false
> elsif (o = 0 or TypesMatch(o, "QWidget") or IsBaseClass(o, "QWidget"))
> then return true
> else
> return false
> end if
> end type
>
> Regards,
> Juergen
Yes, your way of doing it does work. However, now I get warning messages that
"call to TypesMatch() might be short-circuited." Hmm ... wouldn't this
typically be the desirable outcome? I suppose the only time that it wouldn't
be is in someone were depending upon a side effect, and such a place would be
a rather bad place to do that, since Euphoria uses short-cut evaluation.
I've opted for this rather wordy set up instead.
global type Widget(object o)
if not atom(o) then
return false
elsif o = 0 then
return true
else
return (TypesMatch(o, "QWidget") or IsBaseClass(o, "QWidget"))
end if
end type
It seems to work, and without warnings.
As far as my previous set up ...
return (o = 0 or TypesMatch(o, "QWidget") or IsBaseClass(o, "QWidget"))
Why would short-cut evaluation not be a normal, or even "Good" thing in this
instance?
Cojabo: good point about the parenthesis. In this particular instance, that
doesn't seem to help though.
Travis W. Beaty
Osage, Iowa.
--
When asked the definition of "pi":
The Mathematician:
Pi is the number expressing the relationship between the
circumference of a circle and its diameter.
The Physicist:
Pi is 3.1415927, plus or minus 0.000000005.
The Engineer:
Pi is about 3.
5. Re: Short-cut evaluation Question
Travis Beaty wrote:
> Yes, your way of doing it does work. However, now I get warning
> messages that "call to TypesMatch() might be short-circuited." Hmm
> ... wouldn't this typically be the desirable outcome? I suppose
> the only time that it wouldn't be is in someone were depending upon
> a side effect, and such a place would be a rather bad place to do
> that, since Euphoria uses short-cut evaluation.
The Euphoria interpreter must think that TypesMatch()
can directly or indirectly (via calls to other routines)
cause a side-effect, otherwise it
wouldn't warn you about "might be short-circuited".
Side effects include setting a global variable,
doing I/O, poking into memory, and a few other things.
> Why would short-cut evaluation not be a normal, or even "Good"
> thing in this instance?
Short-circuit evaluation is currently only performed
for if, elsif and while expressions. It would make
some sense to extend it to expressions returned by types,
since they should also be atoms. I might do this eventually.
The only issue is that it starts getting harder to remember
the cases where s.c. is or is not applied.
Note that s.c. can't be used in some cases, e.g.
object x
x = TRUE or expression
We can't just say x is TRUE. What if expression
evaluates to a sequence? - the result should then
be a sequence.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
