World: r3wp

When it comes to things like word syntax, the errors raised for bad 
syntax and the particular cases where they are raised need to be 
part of the rules.

In a full syntax description, some of those charsets would be named 
differently of course.

You raise a good question Brian. Should the rules emit their own 
errors ? 

I guess the intent is to keep them light for now. If an error occurs, 
the parsing just stop.

Another guess is that alternative rules (eg. inside value-syntax) 
should be kept order independent when possible (with the drawback 
that they are slightly more convoluted than necessary).

last but not least


word-char: complement union charset "()[]^"{}/;<>,\#$%:@^@" whitespace
word-ext: [
	word-char any [word-char | digit]
	[and [#"<" | #">"] | termination]
]
word-syntax: [
	not sign not #"." not #"'" word-ext 
	| #"." [and [#"<" | #">"] | termination]
	| #"." word-ext
	| sign termination
	| sign not #"'" word-ext
	| more-less-word
]

grumpffff, still missing the cases with prefix [+.] and [-.]

word-syntax: [
	not sign not #"." not #"'" word-ext 
	| #"." [and [#"<" | #">"] | termination]
	| #"." word-ext
	| sign termination
	| sign not #"'" opt #"." word-ext      ; <--- there
	| more-less-word
]

I committed a slightly different variant (but based on your findings 
as well). Could you (or other volunteers) check it, please?

Remaining problems with [termination] in word-syntax.
When a word is stuck with a less-word or a tag (R2 and R3)
a<
 == [a <] valid
a<=
 == [a <=] valid
a<>
 == [a <>] valid
a<<
 == [a <<] valid
a<tag>
 == [a <tag>] valid

a>=
 invalid
a>
 invalid
a>>
 invalid

IMO, t's enough to check if the following char is #"<" only

word-syntax: [
	slash-word termination
	| more-less-word termination
	| opt sign [#"." | not #"'"] not digit any word-char
		[termination | and #"<"]
]

a<
 == [a <] - this does not work in R3

???? it's working there

>> system/version
== 2.100.95.3.1

>> system/version
== 2.100.111.3.1

Humm... a bit old, well with the last version you're true

but, it remains a problem when followed by a tag

A112 (not released) is reported to have other improvements related 
to get-words and set-words

remains a problem when followed by a tag
 - indeed, needs adjustment then

A question for Brian: do you think the case:


load "a<a>" ; == [a <a>] shall be mentioned in CC? (and, eventually, 
where?, a new ticket or an old one?)

Question:
Why #"/" is in termination-char ?

(termination-char: union whitespace charset "()[]^"{}/^@;" )

That is because #"/" is a separator in paths

well it's a problem for the other datatypes which use [termination]

example?

example: word-syntax
with the current ruke a word can be terlinated with #"/'

*rule

yes, but that is not a problem

*terminated/followed

(is it?)

>> hh/
** Syntax Error: Invalid path -- hh/
** Near: (line 1) hh/

Yes, but that is not a problem for the word, it is an invalid path

[aaaa/] is not a word! it's a path!

I was just wondering if that is what Steeve meant

yep

Steve are you aware of the R3 parse AND operator?  maybe that is 
throwing you off?

yes, load "aaaa/" reports an "invalid path". However, the word is 
valid.

>> p: load "aaaa/1"
== aaaa/1

>> type? first p
== word!

but I think it should be detected inside the path-syntax not in the 
word-syntax or not ?

Actually, inside the path-syntax you need to detect the word...

the AND is a look ahead.  it doesn't advance the input, so whatever 
is matched by    [ AND termination ] only tries to find a delimiter.

signaling the end of the word, without consuming the "/"

I know that already Max ;-)

ok, just wanted to be sure :-)

Al least it's a problem with [termination] used in tuple-syntax and 
decimal-syntax.
Don't say i'm wrong here again :-)

I do not know an example where it would be wrong

[1.2.3/] how can that be valid ?

ah, yes... you are struggling with the AND here   :-)   the termination 
is not part of the tuple... but it does mark it  :-)

with the current rules it would be checjed like [1.2.3 /]

that is not a valid path, but this one is:

>> type? second load "a/1.2.3/b"
== tuple!

That's right it makes the tupple valid which is wrong

The tuple *is* valid, what is invalid is just the path in your example

no, it makes the PATH invalid.

what !!!!!!

I can't believe it
[1.2.3/b] = [1.2.3  /b]