| Type | Bug | Status | reviewed | Date | 18-Jan-2011 11:05 |
|---|---|---|---|---|---|
| Version | alpha 110 | Category | Datatype | Submitted by | oldes |
| Platform | All | Severity | minor | Priority | high |
| Summary | FIND and SELECT type-distinguishing behavior is not consistent between type classes |
|---|---|
| Description |
FIND and SELECT of blocks will sometimes consider the value searched for to be equivalent to a value of another datatype within the same type class. However, they are currently not consistent in this behavior between different type classes (number!, any-string! and any-word!). They're not consistent with R2 either, but that's not as much of an issue (see #666). FIND and SELECT: - don't distinguish between integer! and decimal! (do distinguish in R2), but do distinguish percent! - do distinguish between any-string! types (same as R2) - don't distinguish between any-word! types (do distinguish in R2) FIND/case and SELECT/case: - same - same - do distinguish between any-word! types (same as R2) We need some consistency here, or this will lead to an endless set of questions about why it isn't consistent. At the very least, the number types need to be consistent amongst themselves, including percents. We have several options here: - 1: Don't do type equality within type classes, /case or not (R2-style). - 2: Do type equality within type classes all the time, /case or not. - 3: Do type equality within type classes by default, don't with /case. - 4: Do type equality within type classes by default, don't with a new option (perhaps called /type), /case doesn't affect it. It is worth noting that maps and objects don't distinguish between word types for keys, but maps do distinguish between string types and disallow number types other than integer!. And maps and objects ignore case, keeping the type and case of the first comparable key. There are limits to consistency. |
| Example code |
; Numbers >> find [100% 1.0 1] 1 == [1.0 1] ; doesn't distinguish between integer! and decimal!, but does percent! >> find [100% 1 1.0] 1.0 == [1 1.0] ; doesn't distinguish between decimal! and integer!, but does percent! >> find [1.0 1 100%] 100% == [100%] ; does distinguish between percent! and the others ; Same for FIND/case, SELECT and SELECT/case ; Words >> find [a 'a] quote 'a == [a 'a] >> find/case [a 'a] quote 'a == ['a] ; Same for other word types, and for SELECT and SELECT/case |
| Assigned to | n/a | Fixed in | - | Last Update | 1-Feb-2011 01:19 |
|---|
| Comments | |
|---|---|
|
(0003031)
BrianH 18-Jan-2011 23:22 |
Apparently SELECT is using EQUAL? comparison for word types in R3, and SELECT/case using a subset of STRICT-EQUAL? without binding. Its behavior with other type classes is not consistent with this, or even consistent amongst itself. I'm going to rewrite this ticket so that the consistency bugs can be considered, rather than the R2 compatibility argument that got dismissed (see #666). |
|
(0003039)
BrianH 20-Jan-2011 02:13 |
I like options 3 or 4, but option 3 will likely get some complaints (see #1831 and #1832). Option 1 will break a lot of existing R3 code; the other options will break a lot of R2 code (see #666), and maybe require some tweaks to existing R3 code. |
|
(0003041)
maxim 20-Jan-2011 18:09 |
definitely should be 4.
the /type name works well with the type?/word function I find. I understand that type sloppiness is useful to simplify code, but this being forced upon us on such low-level functions as 'SELECT and 'FIND with no way out, really is ringing fire alarms in my head. Also, I didn't verify how 'SWITCH is being handled, but I feel it has to be symmetric with 'SELECT, because its the closest cousin to 'SELECT and the control flow function I (and many others) use the most. |
|
(0003042)
BrianH 20-Jan-2011 20:52 |
SWITCH with numbers doesn't distinguish between integers and decimals, but does distinguish percents from those:
>> switch 1 [1.0 [1] 1 [2]] == 1 >> switch 1.0 [1 [1] 1.0 [2]] == 1 >> switch 1.0 [1 [1] 1.0 [2] 100% [3]] == 1 >> switch 100% [1 [1] 1.0 [2] 100% [3]] == 3 With strings, words and characters, SWITCH does distinguish types, but not case. >> switch "a" [%a [1] "a" [2]] == 2 >> switch "a" ["A" [1] "a" [2]] == 1 >> switch quote 'a [a [1] 'a [2]] == 2 >> switch quote a [A [1] a [2]] == 1 >> switch #"a" [#"A" [1] #"a" [2]] == 1 With binaries, it does distinguish what would be case for the equivalent strings: >> switch to-binary "a" reduce [to-binary "A" [1] to-binary "a" [2]] == 2 I would prefer to get rid of the integer=decimal thing here and make it like the percent behavior. We were discussing making SWITCH/type be the equivalent of SWITCH TYPE?/word, a frequent code pattern that Carl thinks looks ugly (don't know the status of those plans). |
|
(0003043)
maxim 20-Jan-2011 22:54 |
I'll just restate that however SELECT ends up being with its comparisons and comparison-related refinements, SWITCH should do exactly the same. Obviously, SWITCH has other refinements which wouldn't be affected by this.
SWITCH/type idea is neat but I wouldn't use that name for it if SELECT ends up with that refinement too. this is one area in which REBOL is not consistent and its very awkward right now. We end up requiring to look up docs just to remember how "this" function compares things. just my POV :-) |
|
(0003045)
BrianH 21-Jan-2011 01:42 |
Looking back, it seems that the proposal was to have SWITCH treat type names and logic names as keywords in the block of cases, so they could be matched to their equivalent datatype! or logic! values. No /type option was suggested. This would be similar to what CONSTRUCT without /only does with the logic keywords. The only reference to that proposal here is a comment to ticket #578. So no worries about /type meaning different things to different functions. |
|
(0003081)
oldes 31-Jan-2011 23:31 |
Actually the original proposal was, that I've beed going to use code like:
>> select [a b return: c] quote return: == c but than I've found, that it's not safe, because I get this result with R3: >> select [a return b return: c] quote return: == b I was informed, that I can use: >> select/case [a return b return: c] quote return: == c It's OK for me, but as Maxim says, it's very awkward right now. PS: For my purpose is the best way to use parse anyway.. like: >> parse [a return b return: c][some word! quote return: set ret word!] ret == c I just had to found the new useful QUOTE keyword:) |
|
(0003082)
BrianH 1-Feb-2011 01:19 |
Oldes, I was talking about the proposal about SWITCH and type names - which doesn't have a ticket - not anything to do with SELECT. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 1-Feb-2011 01:19 | BrianH | Comment : 0003082 | Added | - |
| 31-Jan-2011 23:36 | oldes | Comment : 0003081 | Modified | - |
| 31-Jan-2011 23:31 | oldes | Comment : 0003081 | Added | - |
| 21-Jan-2011 01:42 | BrianH | Comment : 0003045 | Added | - |
| 20-Jan-2011 22:54 | maxim | Comment : 0003043 | Added | - |
| 20-Jan-2011 21:10 | BrianH | Comment : 0003042 | Modified | - |
| 20-Jan-2011 20:57 | BrianH | Comment : 0003042 | Modified | - |
| 20-Jan-2011 20:52 | BrianH | Comment : 0003042 | Added | - |
| 20-Jan-2011 18:09 | maxim | Comment : 0003041 | Modified | - |
| 20-Jan-2011 18:09 | maxim | Comment : 0003041 | Added | - |
| 20-Jan-2011 03:54 | BrianH | Code | Modified | - |
| 20-Jan-2011 03:32 | BrianH | Description | Modified | - |
| 20-Jan-2011 02:15 | BrianH | Comment : 0003039 | Modified | - |
| 20-Jan-2011 02:13 | BrianH | Comment : 0003039 | Added | - |
| 20-Jan-2011 02:03 | BrianH | Comment : 0003031 | Modified | - |
| 20-Jan-2011 02:02 | BrianH | Priority | Modified | normal => high |
| 20-Jan-2011 02:02 | BrianH | Status | Modified | dismissed => reviewed |
| 20-Jan-2011 02:02 | BrianH | Severity | Modified | not a bug => minor |
| 20-Jan-2011 02:02 | BrianH | Category | Modified | Native => Datatype |
| 20-Jan-2011 02:02 | BrianH | Code | Modified | - |
| 20-Jan-2011 02:02 | BrianH | Description | Modified | - |
| 20-Jan-2011 02:02 | BrianH | Summary | Modified | SELECT does not makes difference between 'word types => FIND and SELECT type-distinguishing behavior is not consistent between type classes |
| 18-Jan-2011 23:22 | BrianH | Status | Modified | submitted => dismissed |
| 18-Jan-2011 23:22 | BrianH | Severity | Modified | minor => not a bug |
| 18-Jan-2011 23:22 | BrianH | Category | Modified | Unspecified => Native |
| 18-Jan-2011 23:22 | BrianH | Code | Modified | - |
| 18-Jan-2011 23:22 | BrianH | Comment : 0003031 | Added | - |
| 18-Jan-2011 11:05 | oldes | Ticket | Added | - |