REBOL3 tracker
  0.9.12 beta
Ticket #0001650 User: anonymous

Project:



rss
TypeBug Statuscomplete Date11-Sep-2010 14:47
Versionalpha 107 CategorySyntax Submitted bymeijeru
PlatformAll Severityminor Priorityhigh

Summary Empty issue not parsed correctly: Single # is parsed with CRLF
Description Since issue! is now any-word! and not any-string!, an empty issue should no more exist than an empty get-word (:). However, a single # followed by end-of line is parsed as containing three characters.

NOTE: As of R3.A108, a single # is defined as the NONE value. -Carl
Example code
>> length? #
== 3
>> to-binary to-string #
== #{230D0A}

Assigned ton/a Fixed inalpha 108 Last Update2-Nov-2010 13:33


Comments
(0002490)
BrianH
13-Sep-2010 01:42

Issues shouldn't have the same character restrictions as other words, so there is no reason that an empty issue can't continue to exist. It could be useful for some cases, and the syntax supports it (syntax restrictions are the reason for the character restrictions for the other word types). However, an empty issue should be an empty issue, not an issue with a CRLF.
(0002491)
meijeru
13-Sep-2010 11:27

There are more things wrong:
>> probe length? #()
6 ;; expected scanning to stop at ()
>> probe length? #[]
** Syntax error: invalid constructor: []
>> probe length? #/a
5
== /a ;; can't have it both ways: is /a is scanned separately, length should be 1
>> type? probe length? #/a
5
== /a ;; would have expected refinement! as in following example
>> type? probe 1
1
== integer!
(0002492)
BrianH
13-Sep-2010 11:58

Your second example was legit, an appropriate response to a botched serialized syntax constructor.
For your fourth example, there were two expressions. Try this instead:
>> reduce [type? probe length? #/a]
6 ;; this is wrong, should be 0
== [integer! /a] ;; this is right
(0002494)
meijeru
15-Sep-2010 16:18

In the fourth example, my version 107 gives 6 for the length, not 5! Plus, it is still the case that the #/a]CRLF combination is scanned twice, once for producing the length 6 issue, and once for producing the second component of the reduced block. But maybe you consider this one and the same error...
(0002495)
BrianH
16-Sep-2010 05:41

Comment fixed. This is only one error, in TRANSCODE. The syntax scanner for the index! type is wrong. The second scan of the characters that you mentioned is correct.
(0002500)
Carl
20-Sep-2010 22:42

There are actually quite a few test cases needed here to get issue! right, mainly because # is a lead-in to other forms. The problem is that the scanner is not tuned in that way, as can be seen in this clearly ambiguous case:

>> type? #user@example.com
== email!

In other words, the scanner is ambivalent about the # lead-in, and we probably need to raise its lexical precedence.

However, I can easily fix the immediate bug posted here, and I should mention that I'd like to redefine a single # as a single lexical character representing #[none], which is very common in stored blocks, such as those used in micro-databases. No other alternatives stand out as plainly to me.
(0002519)
BrianH
21-Sep-2010 23:38

"I'd like to redefine a single # as a single lexical character representing #[none]" - I'm all for that :)
(0002759)
Ladislav
2-Nov-2010 13:33

in the core-tests suite

Date User Field Action Change
2-Nov-2010 13:33 Ladislav Comment : 0002759 Added -
2-Nov-2010 04:37 BrianH Status Modified tested => complete
20-Oct-2010 04:13 BrianH Status Modified built => tested
21-Sep-2010 23:38 BrianH Comment : 0002519 Added -
20-Sep-2010 22:55 carl Description Modified -
20-Sep-2010 22:55 carl Status Modified reviewed => built
20-Sep-2010 22:55 carl Fixedin Modified => alpha 108
20-Sep-2010 22:55 carl Description Modified -
20-Sep-2010 22:47 carl Comment : 0002500 Modified -
20-Sep-2010 22:44 carl Comment : 0002500 Modified -
20-Sep-2010 22:42 carl Comment : 0002500 Added -
16-Sep-2010 05:41 BrianH Comment : 0002495 Added -
16-Sep-2010 05:39 BrianH Comment : 0002492 Modified -
15-Sep-2010 16:18 meijeru Comment : 0002494 Added -
13-Sep-2010 11:58 BrianH Comment : 0002492 Modified -
13-Sep-2010 11:58 BrianH Comment : 0002492 Added -
13-Sep-2010 11:27 meijeru Comment : 0002491 Added -
13-Sep-2010 01:42 BrianH Comment : 0002490 Added -
13-Sep-2010 01:41 BrianH Priority Modified normal => high
13-Sep-2010 01:41 BrianH Status Modified submitted => reviewed
13-Sep-2010 01:41 BrianH Category Modified Datatype => Syntax
13-Sep-2010 01:41 BrianH Code Modified -
13-Sep-2010 01:41 BrianH Summary Modified Empty issue should no more exist -- single # is parsed with CRLF, though => Empty issue not parsed correctly: Single # is parsed with CRLF
11-Sep-2010 14:47 meijeru Ticket Added -