REBOL3 tracker
  0.9.12 beta
Ticket #0001938 User: anonymous

Project:



rss
TypeBug Statusbuilt Date20-Jan-2013 19:22
Versionalpha 111 CategoryParse Submitted byabolka
PlatformAll Severityminor Prioritynormal

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 ton/a Fixed inr3 master Last Update22-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 -