Type | Bug | Status | built | Date | 20-Jan-2013 19:22 |
---|---|---|---|---|---|
Version | alpha 111 | Category | Parse | Submitted by | abolka |
Platform | All | Severity | minor | Priority | normal |
Summary | Case-sensitivity of bitset!/charset! in PARSE |
---|---|
Description |
R3's PARSE currently has a nasty regression in the handling of case-sensitivity for bitsets/charsets. In R2, bitsets where always treated case-_sensitively_, irrespective of whether we used PARSE/case (see the first section of the example code). In R3, bitsets are currently treated case-_sensitively_ without /case, but case-_insensitively_ with /case, effectively inverting the desired meaning of the /case refinement (see the second section of the example code). The current behaviour of R3 is unacceptable: /CASE is used to indicate that case-sensitive comparison is to be used, but the current implementation does the complete opposite. See the comments for a discussion of possible solutions. This issue was originally reported by HostileFork on StackOverflow Chat. |
Example code |
; --- R2 Example Code --- R2>> parse "a" reduce [charset "a"] R2== true R2>> parse/case "a" reduce [charset "a"] R2== true R2>> parse "A" reduce [charset "a"] R2== false R2>> parse/case "A" reduce [charset "a"] R2== false ; --- R3 Example Code --- R3>> parse "a" reduce [charset "a"] R3== true ; OK R3>> parse/case "a" reduce [charset "a"] R3== true ; OK R3>> parse "A" reduce [charset "a"] R3== false ; Debatable R3>> parse/case "A" reduce [charset "a"] R3== true ; Unacceptable |
Assigned to | n/a | Fixed in | r3 master | Last Update | 22-Jan-2013 04:48 |
---|
Comments | |
---|---|
(0003381)
abolka 20-Jan-2013 19:27 |
I currently see two possible solutions:
(A) Fix this thoroughly by making bitsets behaviour consistent with the /case flag: - without /case, bitsets are treated case-insensitively by PARSE; - with /case, bitsets are treated case-sensitively by PARSE. (B) Fix this issue by falling back to R2's behaviour: with or without /case, bitsets are always treated case-sensitively by PARSE. Of those two solutions, I would prefer (A) for the sake of improved consistency and predictability. I think that there are enough PARSE incompatibilities between R2 and R3 already, so that it's not worth to hold back with fixing this issue properly in the name of backwards-compatibility. |
(0003382)
abolka 20-Jan-2013 19:32 |
HostileFork submitted a fix implementing (A) as proposed above as pull request 63:
https://github.com/rebol/r3/pull/63 |
(0003383)
BrianH 20-Jan-2013 21:48 |
Fork's approach (A) seems to be the best here. See #666 for R2 compatibility issues. |
(0003389)
abolka 21-Jan-2013 11:01 |
A quick poll on AltME has so far resulted in 3 further votes in favour of A (Gregg, Ladislav, Robert). |
(0003390)
abolka 22-Jan-2013 04:47 |
A fix implementing variant (A) has been merged in 6292a2f61b1fe37edbdc17cf61904290cf0a0c3b. |
Date | User | Field | Action | Change |
---|---|---|---|---|
22-Jan-2013 04:48 | abolka | Fixedin | Modified | => r3 master |
22-Jan-2013 04:48 | abolka | Status | Modified | pending => built |
22-Jan-2013 04:47 | abolka | Comment : 0003390 | Added | - |
21-Jan-2013 11:01 | abolka | Comment : 0003389 | Added | - |
20-Jan-2013 21:49 | BrianH | Status | Modified | submitted => pending |
20-Jan-2013 21:48 | BrianH | Comment : 0003383 | Added | - |
20-Jan-2013 20:01 | abolka | Comment : 0003381 | Modified | - |
20-Jan-2013 20:01 | abolka | Comment : 0003382 | Modified | - |
20-Jan-2013 20:01 | abolka | Comment : 0003381 | Modified | - |
20-Jan-2013 20:00 | abolka | Comment : 0003381 | Modified | - |
20-Jan-2013 20:00 | abolka | Comment : 0003381 | Modified | - |
20-Jan-2013 19:32 | abolka | Comment : 0003382 | Added | - |
20-Jan-2013 19:31 | abolka | Description | Modified | - |
20-Jan-2013 19:31 | abolka | Code | Modified | - |
20-Jan-2013 19:27 | abolka | Comment : 0003381 | Added | - |
20-Jan-2013 19:22 | abolka | Ticket | Added | - |