World: r3wp

Well, I do not know exactly what to do now, there is an option to 
reflect the state in the DECIMAL-SYNTAX definition

At least it should be noted as a comment in the source

yes

I still think there is a problem with that form [aaa/]

It will be checked like 2 separate valid words although it's an invalid 
path

btw, I was not able to use decimals in paths in R2.
>> a: [0.3 test]
== [0.3 test]
>> a/0.3
== none

system/version?

2.7.8.3.1

aha, in R2, OK

I'm thinking its a rounding/precision error.

no, it looks like an unimplemented feature

(it is not possible to obtain different rounding when using 0.3 twice)

A change committed. "aaa/" is not accepted now, however, there are 
differences we should discuss.

I don't see the new commit, weird !

Hallo !

corrected

Another thing...

a zero length word is valid with that rule

 
 -> word-syntax succeded

That way, word-syntax must have one character length à least
word-syntax: [
	[
		slash-word
		| more-less-word

  | and word-char opt sign [#"." | not #"'"] not digit any word-char
	]
	termination 
]

good catch

>> load "a<a>"
== [a <a>]
Looks good to me.

There were some good reasons for the complexity of the rule in

Thanks I forgot to whine about that one

There were some good reasons for the complexity of the rules in http://issue.cc/r3/1302
and the error handling was necessary too, since the actual word syntax 
is only recognized after it eliminates the error conditions.

For instance, some of the words are definitely handled as special-cases, 
rather than as normal word characters. Different follow sets in those 
cases too.

Every word with / or < or > in it is a special case.

it's not < or > , it must be a valid tag!, else it"s an error

I don't think there is a need to break anything in word-syntax as 
it is

I don't think there is a need to break anything in word-syntax as 
it is

Actually, if it's not any one of these, specifically: "<" | ">" | 
"<>" | "<=" | ">=" | "<<" | ">>"
There aren't any other special cases in R3, I checked.

check your version in the A111 it"s not true anymore

I've been meaning to adapt those rules to R2 though. There should 
be more bugs there though, and unlike the bugs in the R3 syntax we 
can't fix them in R2.

I don't know if it's what you mean, but ther is only need to check 
if a word! is optionaly followed by a tag!

ie. for R3

value-syntax: [
	block-syntax
	| paren-syntax
	| integer-syntax
	| decimal-syntax
	| char-syntax
	| quoted-string
	| braced-string
	| binary-syntax
	| tuple-syntax
	| word-syntax opt tag-syntax  ;<=== there
]

No, forget it , it needs more work

Agreed with you

You're right, the word followed by tag works. I also just fixed another 
bug too: the ">" needed to be a choice after ">>".

for R3, I think the following trick is enough

word-syntax: [
	...
	[and tag-syntax | termination] 
]

R2 needs more

If I was doing a full parser I'd try to cut down on the lookahead 
parsing of more than a single character or charset, so as to avoid 
repeating the parsing. Plus, for R3 there's a ticket to improve tag 
syntax that I'd like implemented (single-quote strings in tags). 
For an R2 parser I suppose that an approach that is more tolerant 
of design flaws would be appropriate, since its syntax is in bug-for-bug 
backwards-compatibility mode.

I still can't believe that the syntax has so much drawbacks

I mean, they can't be deliberate

I'm curious to see how it was coded

There really weren't that many, and most of them were fixed in alpha 
97. Some of them are deliberate tradeoffs, such as http://issue.cc/r3/1317

One interesting thing is that R2 and R3 have binary parsers, not 
text parsers. The difference doesn't matter that much in R2 but in 
R3 it matters a lot.

try this in R2
[a<] and [a<  ]

All of the syntax characters in R3 fit in the ASCII range. That is 
why there are no Unicode delimiters, such as the other space characters.

Yup, that is why he made the tradeoff.

Annoying syntax... I take my pause for now

the "+<tag>" case differs from the "-<tag>" case!