| Type | Bug | Status | tested | Date | 24-Mar-2010 15:00 |
|---|---|---|---|---|---|
| Version | alpha 97 | Category | Mezzanine | Submitted by | Sunanda |
| Platform | All | Severity | minor | Priority | normal |
| Summary | EXTRACT fails to handle UNSET! and FALSE values |
|---|---|
| Description |
EXTRACT uses ANY to determine whether a value is there or not. But that doesn't work right with unset! values or false - only none should count as a missing value. b: copy [] loop 3 [append b unset 'a append b length? b] sort/reverse b ;; just to show that UNSET! can be sorted == [5 3 1 unset! unset! unset!] But EXTRACT morphs the UNSET! to NONE extract b 2 == [5 1 none] extract b 1 == [5 3 1 none none none] I appreciate that UNSET! is definitely a second class value (though slightly better handled that in R2) and that many REBOL operations throw an error when fed an UNSET!. For consistency with R2, perhaps R3's EXTRACT should also throw an error rather than convert the datatype. |
| Example code |
none = first extract reduce [()] 1 true ;;not expecting TRUE |
| Assigned to | n/a | Fixed in | alpha 108 | Last Update | 20-Oct-2010 03:19 |
|---|
| Comments | |
|---|---|
|
(0002115)
BrianH 25-Mar-2010 00:20 |
It's worse than you think: FALSE is treated as a missing value too. Changed ticket accordingly.
I don't think that generating an error is appropriate: It would lose contextual information about the position of the unset value. We might as well just propagate the unset values to the return block. To do otherwise would hide the effects of the (probably erroneous) code that generated the unset value in the first place. Unfortunately, this is going to slow down EXTRACT quite a bit. |
|
(0002123)
Sunanda 25-Mar-2010 07:59 |
Thanks for deepening the analysis....The problem with FALSE is far more important.
Should an UNSET! in EXTRACT trip an error like R2? Much as I'd like UNSET! to be easily handled in R3, it is a problematic value. Anyone using UNSET! has a high hill to climb to do so safely: most operations do trip an error with UNSET! eg (using the same b block as before), eg: equal? b/1 b/4 ** Script error: equal? does not allow unset! for its value2 argument strict-equal? b/1 b/4 ** Script error: strict-equal? does not allow unset! for its value2 argument *** Although SORT does work (as per the original bug report), it is one of the few block operations that do. UNION, DIFFERENCE, UNIQUE, etc all throw errors when they handle an UNSET! eg: unique b ** Script error: unset! type is not allowed here *** So it may be more consistent for EXTRACT to throw an error than to work! Other options: * make UNSET! acceptable everywhere * document the inadvisability of using UNSET as a value |
|
(0002135)
BrianH 26-Mar-2010 22:47 |
Fixed in mezz-series.r 7123, and it isn't much slower (one call to NONE? and one or two assignments, per iteration).
EXTRACT doesn't trigger an error for unset values in R2 either, as of 2.7.7. And as of 2.7.8 it won't have the same FALSE bug. The treatment of unset values in REBOL is always tricky. The whole point of the type is to trigger errors, to be a version of NONE where not having a value is considered a bad thing. So every time we allow or don't allow unset, we consider whether it would provide more information to trigger the error then, or leave the unset in place so it can trigger a more informative error later. Or in some cases, we want to actually work with unset values so we make (or keep) a workaround (like the op trick). In the case of EXTRACT, we are going to propagate the unset value to the result so that there is a trace of where the unset was in the first place. And so that EXTRACT can work in situations where unset values are acceptable - that is up to the user of EXTRACT to decide, not us. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 20-Oct-2010 03:19 | BrianH | Code | Modified | - |
| 20-Oct-2010 03:19 | BrianH | Status | Modified | built => tested |
| 22-Sep-2010 06:40 | carl | Fixedin | Modified | => alpha 108 |
| 22-Sep-2010 06:40 | carl | Status | Modified | pending => built |
| 26-Mar-2010 22:49 | BrianH | Comment : 0002135 | Modified | - |
| 26-Mar-2010 22:48 | BrianH | Comment : 0002135 | Modified | - |
| 26-Mar-2010 22:47 | BrianH | Comment : 0002135 | Modified | - |
| 26-Mar-2010 22:47 | BrianH | Comment : 0002135 | Added | - |
| 26-Mar-2010 22:31 | BrianH | Status | Modified | reviewed => pending |
| 25-Mar-2010 07:59 | sunanda | Comment : 0002123 | Added | - |
| 25-Mar-2010 00:20 | BrianH | Comment : 0002115 | Added | - |
| 25-Mar-2010 00:10 | BrianH | Summary | Modified | EXTRACT fails to handle UNSET! values => EXTRACT fails to handle UNSET! and FALSE values |
| 25-Mar-2010 00:10 | BrianH | Description | Modified | - |
| 25-Mar-2010 00:10 | BrianH | Code | Modified | - |
| 25-Mar-2010 00:10 | BrianH | Status | Modified | submitted => reviewed |
| 24-Mar-2010 15:00 | sunanda | Ticket | Added | - |