Comments on: Nit PICKing
Here's a commonly repeating pattern: you need two pick one of two values based on a condition.
For, example, say you need to pick one of two strings. Sure, you can write:
str: either cond ["this"]["that"]
Of course, that line seems inefficient because you're evaluating one of two blocks. You're forcing the interpreter to nest (and nesting is for the birds unless you're really computing something.)
Instead, I often write the more optimal expression:
str: pick ["this" "that"] cond
The pick action is fast, but cond better be TRUE or FALSE (or 1 or 2) or boom - throw exception.
Yet even further, if the values are actually variables the above becomes a bit longer...
str: get pick [this that] cond
Being a greedy block-miser, I must say I'm dissatisfied by any of these methods. (Insatisfait, as I am learning to say.) So, these days I've started writing:
str: pick1 cond this that
Of course, since pick1 is a user-defined function, it's not really more efficient in evaluation, it just looks better.
All of this is really just nit picking... but it's funny how little nits eat away at you during long coding sessions. But, dreaming... if pick1 were a native... now maybe we have something there. (Would take maybe 10 minutes to add it.)
Of course, then we'd need a good name for it, and you know what that means...
What do you think? Is this food for thought or nits for picking?
14 Comments Comments:
Grant Rettke
2-Jul-2008 12:24:03 |
Hi Carl,
First I must admit that I am a REBOL lurker, and I haven't dug into language yet, though, every time I read about it I get more and more excited about it. With that in mind, here is my question:
You mention that if pick1 were a user-defined function it would be more efficient in evaluation. Why is that the case? Is it just that you had performed optimization on system-defined functions?
Reading that made my ears perk up when I think about the Scheme revised reports that made such a point to mention that there is no artificial distinction between system and user-defined functions, though, they were referring to a bigger difference than just performance. | Henrik
2-Jul-2008 12:51:28 |
Well, from the dictionary there is CHOOSE, but that's a few more chars to type.
Grant:
You mention that if pick1 were a user-defined function it would be more efficient in evaluation. Why is that the case?
From the post:
Of course, since pick1 is a user-defined function, it's not really more efficient in evaluation, it just looks better.
I believe Carl means the opposite. A user defined function (mezzanine) is slower than a native (built-in, written in C) function, so there is no mystery. :-) | James_Nak
2-Jul-2008 14:36:48 |
I dunno, my 1st thought was "pick-one". I also like "based-on" as in:
based-on cond [][] | Louis
2-Jul-2008 16:00:41 |
"Depending" comes to mind. Like:
str: depending cond this that | Ashley
3-Jul-2008 0:20:49 |
Why a new word? How about allowing:
str: either cond this that
| -pekr-
3-Jul-2008 0:56:32 |
if we are looking for the new word, then - "upon condition this that" | Carl Read
3-Jul-2008 1:41:53 |
It'd be useful, so I'd say add it to R3.
GRAB or TAKE have the advantage of being short words, though they don't suggest a choice. Then there's OPT, though the true condition would need to select the second value... ;-)
| Carl Read
3-Jul-2008 2:15:27 |
Ashley: EITHER would almost work, except for when we wished to return unevaluated blocks. That could be got around by having an /only refinement to force the return of unevaluated blocks, so it might work - and it'd be good if it could.
| Paul
3-Jul-2008 5:02:23 |
Pick evaluates an item if the condition is true or false.
Either evaluates a condition if it is true false or none.
So a new command would be better if it handled the none condition also. For example:
reap: func [cond a b][if cond [return a] b]
I also prefer this to be a new function because adding code to existing functions can cause unnecessary evaluation. | Brian Hawley
4-Jul-2008 9:59:40 |
I agree with Paul that this function should treat the none condition as false, but I have a concern: evaluation. I would prefer that this function only accept word arguments, and not evaluate the words ('word parameters). Like this:
either-get: func [cond 'a [word!] 'b [word!]] [
either :cond [get/any a] [get/any b]
]
or this:
either-get: func [cond 'a [word!] 'b [word!]] [
get/any get pick [b a] not :cond ; to deal with none
]
This would not evaluate the word arguments, though arguments in parentheses would evaluate to a word! value that would be passed to the function. The condition would only be evaluated at call, not again inside the function. | Brian Hawley
4-Jul-2008 10:07:45 |
Ashley, I thought of using either for that too, but that would change its evaluation. If you changed its block arguments to 'block [block! word!] then you couldn't evaluate expressions to retrieve or generate the block without putting them in parentheses. There is likely REBOL code out there that would break horribly. | Paul
4-Jul-2008 11:28:13 |
Brian, I don't think restricting to word types is a good idea because more often than not I would assume we would be using this new function to assign a value to a word and therefore must accomodate other types.
| Brian Hawley
11-Jul-2008 6:04:47 |
Paul, the word! type of a 'a function doesn't affect the type of the value assigned to the word. Those functions would work fine for the purposes you state.
For example, the first+ function takes a 'word parameter of type word!, but the word must be assigned a series. You can't specify that the word must be assigned a series in REBOL's type system, so there is just a doc comment saying so.
In the above functions the only thing the function does with the word is a get/any, so the word doesn't even need to have a value assigned to it, let alone have any other type constraint. | tomc
17-Jul-2008 22:21:39 |
'eor being short for either-or |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
