Right, again, Ladislav! ;-)
[EMAIL PROTECTED] wrote:
>
> Hi Joel,
>
> you wrote:
>
> > Well, I was as surprised as you will be by the following behavior:
> >
> > >> ifs: func [
> > [ {If positive do block 1, zero do block 2, minus do 3}
> > [ [throw]
> > [ condition [number!]
> > [ block1 [block!]
> > [ block2 [block!]
> > [ block3 [block!]
> > [ ] [
> > [ either positive? condition [do block1] [
> > [ either negative? condition [do block3] [do block2]
> > [ ]
> > [ ]
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "positive"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "zero"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "positive"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "zero
> >
> > I had expected that the argument type check would barf on my little
> > pathological case, but it didn't!!!!!
> >
>
> You should read exception #5 for word evaluation of my Rebol/Core
> User's Guide Comments to understand the behaviour. The fact is, that
> Ifs really gets a number
>
You're right... I should have thought more carefully about how the
type check would deal with the paren! value supplied.
However, I didn't follow the next comment at all.
>
> and there is no need to worry about any change during the Ifs
> evaluation in the case you supplied and, moreover, if Ifs is
> defined as above, no such bug is lurking behind the scenes.
>
In the case I supplied, the multiple evaluation DOES cause a bug (or
did I misunderstand you?) as can be seen in the results of "zero",
which occurred every other time. That failure mode occurs when the
evaluation of b returns -1 during the positive? condition test
and then returns 1 during the subsequent negative? condition test,
thus failing both and falling through to the last alternative (which
presumably represents a zero argument value). The supplied argument,
in fact, NEVER evaluates to zero; by alternating between positive and
negative one on subsequent re-evaluations, it can "fake out" any of
the earlier implementations of ifs (the ones that don't evaluate
it once, saving the result).
OBTW, I'm still very interested in whether you have any light to shed
on why the two versions of ifs below behave differently.
>
> >
> > ifs: func [[throw] ce b1 b2 b3 /local cf] [
> > either positive? cf: ce [
> > do b1
> > ][
> > either negative? cf [
> > do b2
> > ][
> > do b3
> > ]
> > ]
> > ]
> >
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "positive"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "negative"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "positive"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "negative"
> >
versus
> >
> > ifs: func [[throw] cexp pblk zblk nblk /local cval] [
> > do either positive? cval: cexp [pblk] [
> > either negative? cval [nblk] [zblk]
> > ]
> > ]
> >
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "zero"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "positive"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "zero"
> > >> ifs b ["positive"] ["negative"] ["zero"]
> > == "positive"
> >
> > Well, it appears that do does NOT distribute over evaluation of its
> > argument!!!!!
> >
Thanks!
-jn-
--
; Joel Neely [EMAIL PROTECTED] 901-263-4460 38017/HKA/9677
REBOL [] print to-string debase decompress #{
789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC
B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}
