1. Short-cut evaluation Question
- Posted by Travis Beaty <twbeaty at osage.net> Feb 29, 2004
- 393 views
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
- Posted by "Juergen Luethje" <j.lue at gmx.de> Feb 29, 2004
- 392 views
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
- Posted by "Derek Parnell" <ddparnell at bigpond.com> Feb 29, 2004
- 400 views
----- 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
- Posted by Travis Beaty <twbeaty at osage.net> Mar 01, 2004
- 372 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 01, 2004
- 392 views
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