[refinements] Mutually exclusive refinements
[1/15] from: atruter::labyrinth::net::au at: 15-Aug-2004 10:47
Here's my attempt at handling mutually exclusive refinements without using
nested 'either.
f: func [/a /b /c /d /e][
print switch/default true compose [
(a) ["A"]
(b) ["B"]
(c) ["C"]
(d) ["D"]
(e) ["E"]
]["?"]
]
Anyone come across a better way?
Regards,
Ashley
[2/15] from: Izkata:Comcast at: 14-Aug-2004 19:51
----- Original Message -----
From: "Ashley Trüter" <[atruter--labyrinth--net--au]>
To: <[rebolist--rebol--com]>
Sent: Saturday, August 14, 2004 7:47 PM
Subject: [REBOL] [refinements] Mutually exclusive refinements
> Here's my attempt at handling mutually exclusive refinements without usin
> g
<<quoted lines omitted: 9>>
> ]
> Anyone come across a better way?
Hey, you just taught me a little about functions and refinements.. But -
>> f/b/c/d
B
Would it be better to use 'if ? Or is that the result you wanted?
[3/15] from: atruter:labyrinth:au at: 15-Aug-2004 11:03
> Would it be better to use 'if ? Or is that the result you wanted?
I thought mutually exclusive said it all. ;)
Also note the implied order of precedence:
>> f/d/a/b
A
which is intentional.
Regards,
Ashley
[4/15] from: Izkata:Comcast at: 14-Aug-2004 20:10
----- Original Message -----
From: "Ashley Trüter" <[atruter--labyrinth--net--au]>
To: <[rebolist--rebol--com]>
Sent: Saturday, August 14, 2004 8:03 PM
Subject: [REBOL] Re: [refinements] Mutually exclusive refinements
> > Would it be better to use 'if ? Or is that the result you wanted?
>
> I thought mutually exclusive said it all. ;)
>
0.o <Didn't see that> <goes to Dictionary.com>
[5/15] from: carl:cybercraft at: 15-Aug-2004 14:45
my attempt at handling mutually exclusive refinements without usin
>g
>nested 'either.
<<quoted lines omitted: 8>>
>]
>Anyone come across a better way?
This is possibly marginally better, perhaps...
f: func [/a /b /c /d /e][
print select reduce [
a ["A"]
b ["B"]
c ["C"]
d ["D"]
e ["E"]
true ["?"]
] true
]
>> f
?
>> f/a
A
>> f/c
C
>> f/c/a
A
-- Carl Read
[6/15] from: greggirwin:mindspring at: 15-Aug-2004 0:15
Hi Ashley,
AT> Here's my attempt at handling mutually exclusive refinements
AT> without using nested 'either.
AT> f: func [/a /b /c /d /e][
AT> print switch/default true compose [
AT> (a) ["A"]
AT> (b) ["B"]
AT> (c) ["C"]
AT> (d) ["D"]
AT> (e) ["E"]
AT> ]["?"]
AT> ]
I won't say "better", but another way is:
f: func [/a /b /c /d /e][
print any [
all [a b "AB"]
all [a "A"]
all [b "B"]
all [c "C"]
all [d "D"]
all [e "E"]
"?"
]
]
Which, as you can see, allows for combinations of refinements that
aren't mutually exclusive. I can't think of a case where I've had
more than a couple refinements that are mutually exclusive *without*
another option that may be combined with them.
-- Gregg
[7/15] from: gabriele:colellachiara at: 15-Aug-2004 11:58
Hi Ashley,
On Sunday, August 15, 2004, 2:47:52 AM, you wrote:
AT> Anyone come across a better way?
Someday, somewhere, you'll be able to use:
>> help case
USAGE:
CASE block /all
DESCRIPTION:
Evaluates each condition, and when true, evaluates what follows it.
CASE is a native value.
ARGUMENTS:
block -- Block of cases (conditions followed by values) (Type: block)
REFINEMENTS:
/all -- Evaluate all cases (do not stop at first true case)
>> case [
[ 1 > 1 [print 'not]
[ 1 = 1 [print 'yep]
[ 2 = 2 [print 'not-again]
[ ]
yep
== true
;-)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[8/15] from: antonr:lexicon at: 15-Aug-2004 22:05
Mutually exclusive refinements
should mean:
you don't get any (= exclusive)
if they are specified together (= mutually).
Anton.
[9/15] from: SunandaDH:aol at: 15-Aug-2004 9:18
Anton:
> "Mutually exclusive refinements" should mean:
> you don't get any (= exclusive)
> if they are specified together (= mutually).
That's a logical response. But it's not the only logical response.
Take an example: a function whose job it is to adjust a date to the nearest
Monday (start of week) or Saturday (start of weekend).
It is obvious what it should do if I invoke it "properly":
nearest-to/sow now/date
or
nearest-to/sowe now/date
But what if I code?
nearest-to now/date ;; no refinement
or
nearest-to/sow/sowe/date ;; both refinements
Possible responses include (there are many others):
-- function crashes with or without logging an error message
-- function returns none or false
-- function returns input date unchanged
-- function defaults to /sow -- so I get the nearest Monday
-- function works out both /sow and /sowe. Then it returns the earliest one,
so I get a Monday or a Friday
All of those are reasonable behaviours under some conditions. But unless you
know the usage the function was *initially* intended for, it's not really
possible to guess what default behaviour my actual, real, nearest-to function
displays.
Of course, it might make a lot more sense, and remove a lot of dangerous
guessing, if it had been initially written as two separate functions.
Sunanda.
[10/15] from: antonr:lexicon at: 15-Aug-2004 23:55
Ah sorry,
I forgot to add to my statement below
that, in standard rebol functions, you can't
get mutually exclusive refinements, because
nothing is stopping you specifying them together.
(unless a hand comes out of the monitor and
physically prevents you typing them. :)
I wanted to point out that Izkata might have
better said: "mutual refinements *handled*
exclusively".
Anyway,
Anton.
[11/15] from: atruter:labyrinth:au at: 16-Aug-2004 0:49
> "Mutually exclusive refinements" should mean:
> you don't get any (= exclusive)
> if they are specified together (= mutually).
>
> Anton.
http://www.fact-index.com/m/mu/mutually_exclusive.html
flip-coin: func [/heads /tails][
...
]
traffic-light: func [/red /amber /green][
...
]
;)
Regards,
Ashley
[12/15] from: greggirwin:mindspring at: 15-Aug-2004 10:48
This is a good topic; it's making us think.
Context will be important here, WRT how things should behave. The
common case, where we're writing code that uses refinements, should
probably throw an error if you specify two conflicting options; it's
likely a coding mistake that subjects you to the logic embedded in the
function WRT precedence.
Gabriele said:
Someday, somewhere, you'll be able to use:
>> help case
USAGE:
CASE block /all
You can, even today. I think it was Jaime Vargas who posted a version
somewhere, though I can't put my finger on it at the moment. Anyone
got it handy? Jaime, was it you?
-- Gregg
[13/15] from: lmecir:mbox:vol:cz at: 15-Aug-2004 19:23
Gregg Irwin napsal(a):
>You can, even today. I think it was Jaime Vargas who posted a version
>somewhere, though I can't put my finger on it at the moment. Anyone
>got it handy? Jaime, was it you?
>
>-- Gregg
>
http://www.fm.vslib.cz/~ladislav/rebol/pif.r
[14/15] from: gabriele:colellachiara at: 16-Aug-2004 11:06
Hi Gregg,
On Sunday, August 15, 2004, 6:48:30 PM, you wrote:
GI> You can, even today. I think it was Jaime Vargas who posted a version
GI> somewhere, though I can't put my finger on it at the moment. Anyone
GI> got it handy? Jaime, was it you?
Yep, and Ladislav's PIF is not much different either. Though
having it native means we won't need 10 different versions of it
floating around anymore. ;)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[15/15] from: moliad:aei:ca at: 16-Aug-2004 7:26
Gabriele Santilli wrote:
> Though having it native means we won't need 10 different versions of it
> floating around anymore. ;)
And we risk having faster eval as RT can optimise some of its evaluation while in binary?
-MAx
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted