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

[none idiom found?] The best shortcut word for "not none?"

 [1/16] from: greggirwin::mindspring::com at: 1-Sep-2006 12:56


If you use ANY and ALL, the result may be none. The mezzanine that converts a NONE result to a logic! value is FOUND?. I was going to suggest that we add an alternative, for cases like this, to improve the readability. found? all [a = b zero? a - b] That is, I've always read FOUND? as "was the value found?", as you would when using FIND. Now, whenever I think I've caught something that Carl missed, I try to think about it a bit before requesting a change, because it usually turns out that he's thought ahead of me and did the right thing; it just takes me a little time to see it sometimes. :) So, I was going to say a new word would be nice but, when I stopped to think about it a little more, I realized that all I need to do is read it in context. In the above example, it would mean "If it is found that all the following are true...", which couldn't be clearer (I tried to come up with better words, and couldn't). So, thanks Carl, and thanks to Ladislav for making me think about this. What else in REBOL have you found that makes you think, or read code, differently? -- Gregg P.S. Don't forget that if you put a block of keywords in the subject of emails on this ML, REBOL.org will index them automatically! -G

 [2/16] from: lmecir::mbox::vol::cz at: 4-Sep-2006 8:33


Gregg wrote: If you use ANY and ALL, the result may be none. The mezzanine that converts a NONE result to a logic! value is FOUND?. I was going to suggest that we add an alternative, for cases like this, to improve the readability. found? all [a = b zero? a - b] That is, I've always read FOUND? as "was the value found?", as you would when using FIND. Now, whenever I think I've caught something that Carl missed, I try to think about it a bit before requesting a change, because it usually turns out that he's thought ahead of me and did the right thing; it just takes me a little time to see it sometimes. :) So, I was going to say a new word would be nice but, when I stopped to think about it a little more, I realized that all I need to do is read it in context. In the above example, it would mean "If it is found that all the following are true...", which couldn't be clearer (I tried to come up with better words, and couldn't). So, thanks Carl, and thanks to Ladislav for making me think about this. What else in REBOL have you found that makes you think, or read code, differently? -- Gregg Thank you for "highlighting" this issue. You made me think about it once again and find out, that all problems may not be solved yet. My original need was to obtain a LOGIC! value, so the question is, if I shouldn't have used the TO function. Advantages: a) TO LOGIC! is twice as fast as the FOUND? mezzanine and faster than the NOT NONE? idiom b) TO LOGIC! clearly shows what my intention is c) TO LOGIC! does not behave exactly like FOUND? sometimes. See TO LOGIC! FALSE and the question is, which result is appropriate for the specific usage. For the above use this question is unimportant, but it may occur elsewhere. Even when we really need to know whether something has been found, the situation is complicated. See e.g.: found? select 1 reduce [1 none] , which is related to the question, what you expect when writing: switch/default 1 reduce [1 none] [2] Discussion and your preferences are welcome. -Ladislav

 [3/16] from: lmecir::mbox::vol::cz at: 4-Sep-2006 8:47


Gregg wrote: If you use ANY and ALL, the result may be none. The mezzanine that converts a NONE result to a logic! value is FOUND?. I was going to suggest that we add an alternative, for cases like this, to improve the readability. found? all [a = b zero? a - b] That is, I've always read FOUND? as "was the value found?", as you would when using FIND. Now, whenever I think I've caught something that Carl missed, I try to think about it a bit before requesting a change, because it usually turns out that he's thought ahead of me and did the right thing; it just takes me a little time to see it sometimes. :) So, I was going to say a new word would be nice but, when I stopped to think about it a little more, I realized that all I need to do is read it in context. In the above example, it would mean "If it is found that all the following are true...", which couldn't be clearer (I tried to come up with better words, and couldn't). So, thanks Carl, and thanks to Ladislav for making me think about this. What else in REBOL have you found that makes you think, or read code, differently? -- Gregg Thank you for highlighting this issue. You made me think about it once again and find out, that all problems may not be solved yet. My original need was to obtain a LOGIC! value, so the question is, if I shouldn't have used the TO function. Advantages: a) TO LOGIC! is twice as fast as the FOUND? mezzanine and faster than the NOT NONE? idiom b) TO LOGIC! clearly shows what my intention is c) TO LOGIC! does not behave exactly like FOUND? sometimes. See TO LOGIC! FALSE and the question is, which result is appropriate for the specific usage. For the above use this question is unimportant, but it may occur elsewhere. Even when we really need to know whether something has been found, the situation is complicated. See e.g.: found? select 1 reduce [1 none] , which is related to the question, what you expect when writing: switch/default 1 reduce [1 none] [2] Discussion and your preferences are welcome. -Ladislav

 [4/16] from: lmecir::mbox::vol::cz at: 4-Sep-2006 15:28


Ladislav Mecir napsal(a):
> Gregg wrote: > If you use ANY and ALL, the result may be none. The mezzanine that
<<quoted lines omitted: 29>>
> specific usage. For the above use this question is unimportant, but it > may occur elsewhere.
there is one *important* difference I overlooked, though: to logic! 0 ; == false Speaking of which, I would prefer a different behaviour, what do you think?
> Even when we really need to know whether something has been found, the > situation is complicated. See e.g.: > > found? select 1 reduce [1 none] >
correction: it should have been: found? select [1 #[none]] 1
> , which is related to the question, what you expect when writing: > > switch/default 1 reduce [1 none] [2] >
or switch/default 1 [1 #[none]] [2] , if you prefer

 [5/16] from: greggirwin::mindspring::com at: 4-Sep-2006 11:36


Hi Ladislav,
>> c) TO LOGIC! does not behave exactly like FOUND? sometimes. See TO >> LOGIC! FALSE and the question is, which result is appropriate for the >> specific usage. For the above use this question is unimportant, but it >> may occur elsewhere. >>
LM> there is one *important* difference I overlooked, though: LM> to logic! 0 ; == false OK, so 0 and false are where things differ between FOUND? and To LOGIC!; in both cases, FOUND? returns true while TO LOGIC! returns false. I think the key phrase is "appropriate for the specific usage"; but we also have to consider your point below about SELECT/SWITCH. LM> Speaking of which, I would prefer a different behaviour, what do LM> you think? I understand the reason for it--mapping to C BOOL values of 0 and 1--and I think it's probably most useful the way it is now, from a pragmatic point of view. LM> found? select [1 #[none]] 1
>> , which is related to the question, what you expect when writing: >>
LM> switch/default 1 [1 #[none]] [2] This is a *really* good question. I'm always amazed at the behavior we find that you might think would be a problem, but isn't, in practical use. I don't know that I've ever been bitten by the above, but it seems like an obvious flaw when you look at it that way. Maybe this would be a good question for a blog post by Carl. I remember him saying once that FORALL and FORSKOP were originally intended as macros for WHILE, hence leaving the series at the tail. I wonder if the original goal for FOUND? considered its use with ANY and ALL, logic results, or just the result of FIND; and does SWITCH work that way by design, or was it just a convenient implementation with very little risk (i.e. expected behavior) in everyday use. -- Gregg

 [6/16] from: lmecir::mbox::vol::cz at: 5-Sep-2006 6:14


Gregg Irwin napsal(a):
> This is a *really* good question. I'm always amazed at the behavior > we find that you might think would be a problem, but isn't, in > practical use. I don't know that I've ever been bitten by the above, > but it seems like an obvious flaw when you look at it that way. >
If the CASES block you supply to SWITCH has got the expected format, then you cannot have a problem. The fact is, that SWITCH does not check whether the CASES block has got the expected format, though. Another problem may occur if you supply a function instead of an "expected" block.
> Maybe this would be a good question for a blog post by Carl. I > remember him saying once that FORALL and FORSKOP were originally
<<quoted lines omitted: 4>>
> very little risk (i.e. expected behavior) in everyday use. > -- Gregg
I bet that it is the case you described - a convenient implementation not checking whether "the contract" holds, but am asking Carl anyway. -L

 [7/16] from: lmecir::mbox::vol::cz at: 5-Sep-2006 13:41


How about this implementation change, which is favoured by Cyphre, Gabriele and Anton, as it looks? (disadvantage - it is slower than the original due to the double search) switch1: func [ "Selects a choice and evaluates what follows it." [throw] value "Value to search for." cases [block!] "Block of cases to search." /default case [block!] "Default case if no others are found." /local blk ][ value: find cases value if value [value: find next value block!] either value [do first value] [if default [do case]] ] example: [ switch1 1 [2 4 6 ['even] 1 3 5 ['odd]] ] -Ladislav

 [8/16] from: gabriele::colellachiara::com at: 6-Sep-2006 12:37


Hi Ladislav, On Tuesday, September 5, 2006, 1:41:57 PM, you wrote: LM> either value [do first value] [if default [do case]] I think you could write this as: do either value [first value] [case] with the assumption that case is none when the /default refinement has not been specified. Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

 [9/16] from: lmecir:mbox:vol:cz at: 6-Sep-2006 13:38


Gabriele Santilli napsal(a):
> Hi Ladislav, > On Tuesday, September 5, 2006, 1:41:57 PM, you wrote:
<<quoted lines omitted: 5>>
> Regards, > Gabriele.
OK, here is the improved version, which I am proposing to Carl too: REBOL [ Author: ["Ladislav Mecir" "Gabriele Santilli"] Purpose: "A SWITCH alternative, see example" ] switch1: func [ "Selects a choice and evaluates the first block that follows it." [throw] value "Value to search for." cases [block!] "Block of cases to search." /default case [block!] "Default case if no others are found." ][ if value: find cases value [value: find next value block!] do either value [first value] [case] ] example: [ switch1 1 [2 4 6 ['even] 1 3 5 ['odd]] ]

 [10/16] from: anton::wilddsl::net::au at: 7-Sep-2006 1:03


Looks good to me. I think it can't be further optimized. Anton.

 [11/16] from: fsievert:uos at: 6-Sep-2006 19:59


Anton Rolls <anton-wilddsl.net.au> schrieb:
>Looks good to me. >I think it can't be further optimized.
Maybe something like this? switch1: func [ "Selects a choice and evaluates the first block that follows it." [throw] value "Value to search for." cases [block!] "Block of cases to search." /default case [block!] "Default case if no others are found." ][ do any [ all [ value: find cases value value: find next value block! first value ] case ] ] CU Frank

 [12/16] from: greggirwin::mindspring::com at: 6-Sep-2006 12:41


FS> do any [ FS> all [ FS> value: find cases value FS> value: find next value block! FS> first value FS> ] FS> case FS> ] FS> ] I'm OK with either one. If it weren't for how integers parse, we could do this: do either parse cases [ thru value to block! value: to end ] [first value] [case] Adding the int handling will probably make it unwieldy though, unless Ladislav has a handy parse trick up his sleeve. :) -- Gregg

 [13/16] from: anton::wilddsl::net::au at: 7-Sep-2006 14:01


Gosh! Hi Frank! Haven't seen you for a while :) No, this optimization doesn't work (I almost posted one like this too), because DOing the found block might return unset! or none!, so the ANY would not be satisfied and the default case would be done erroneously. Anton.

 [14/16] from: gabriele:colellachiara at: 7-Sep-2006 14:06


Hi Anton, On Thursday, September 7, 2006, 6:01:33 AM, you wrote: AR> No, this optimization doesn't work (I almost posted one AR> like this too), because DOing the found block might AR> return unset! or none!, so the ANY would not be satisfied AR> and the default case would be done erroneously. DO is after ANY. :) I think it's fine. Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

 [15/16] from: anton::wilddsl::net::au at: 7-Sep-2006 22:35


Ahh... you're absolutely right! Frank's version now looks the fastest, probably. Anton.

 [16/16] from: lmecir::mbox::vol::cz at: 8-Sep-2006 9:19


Hi Frank, welcome back!
> Anton Rolls <anton-wilddsl.net.au> schrieb: >> Looks good to me.
<<quoted lines omitted: 19>>
> CU > Frank
thanks, using your version. FYI, Carl wants to introduce a suitable refinement to SELECT to support this SWITCH. -Ladislav

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted