[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