Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Rebol/Core User's Guide Re:(5)

From: joel:neely:fedex at: 11-Oct-2000 15:12

Right, again, Ladislav! ;-) [lmecir--geocities--com] 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 [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677 REBOL [] print to-string debase decompress #{ 789C0BCE0BAB4A7176CA48CAB53448740FABF474F3720BCC B6F4F574CFC888342AC949CE74B50500E1710C0C24000000}