Comments on: NONE-transparent functions
A none-transparent function is one that exhibits this behavior:
>> none? function none
== true
An example is:
remove find block value
The result of find can be none, but remove does not care. None is a valid argument to remove.
Another example is:
clear find block value
This behavior is productive in many cases, but not everywhere. There are times when you want to trap the error case as soon as possible.
For example:
find find block value value2
Here it is better if find is not none-transparent.
In addition to remove and clear, the new take function is also none-transparent. But are there other functions that really should be?
If you have a strong argument in favor (or against) let me know by posting a comment.
6 Comments Comments:
Scot
15-Apr-2007 0:34:05 |
I'd prefer to be able to catch none with a refinement. | Henrik
15-Apr-2007 4:36:13 |
Or perhaps use a flag. Are flags evil? Or is it going to be too similar to ATTEMPT? It's one of those functions I have a turbulent relationship with with all those soothing NONEs returned and then a kick in the nuts, when an error shows up as NONE.
Perhaps a block like with ATTEMPT could be used, where all functions will accept NONE as an argument temporarily, but other errors are properly returned. I have no name for such a function though. | Volker
15-Apr-2007 9:08 |
I think the main use is chaining with 'find. remove and take make sense. 'pick and friends could, but would hide errors to easily.
Not really related here, but related to smarter none-handling: could pick use none too, not only logic? so that [ pick [true-value false-value] none ] would work? Maybe none could indicate last value instead of second value, then [ pick [true-value false-value none-value] ] would work too. (thinking loud)
| Maxim Olivier-Adlhoch
16-Apr-2007 0:00:22 |
I think the core rule which has to be followed is that returning none instead of an error is only possible if the function being called cannot return none on "success" otherwise.
for find, this would seem ok, since find will return a series on success. it would allow us to wrap in within any/all blocks directly which it cannot safely do now.
any [
find all [option-is-set? serie] value
default-value
]
| Maxim Olivier-Adlhoch
16-Apr-2007 0:09:40 |
Some functions like PICK already support "errors" on input like index overflows and the such... I guess whatever happens, we'll end up adapting the code to it... no solution is perfect on all algorythms.
if explicit bounds and input checking is required, we'll add it on the entrant data BEFORE calling whatever none-transparent func is being called. | Gregg Irwin
16-Apr-2007 15:19:42 |
What about series iterators? Would there be an issue with FOREACH being none-transparent, and just not doing anything, as it does with an empty block? |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
