World: r3wp

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]

it may be valid but it has nothing to do with a path anymore

Paths have to start with a word, don't they?

path-syntax shall be something like path-syntax: [word-syntax some 
[#"/" value-syntax]]

Otherwise, they load as a block.

yep.  so the above is not a path   :-)   its a tuple, followed by 
a refinement.

Argh sorry
>> [a/1.2.3/a]
== [a/1.2.3/a]
valid path

Ok you"re right again with tuple!

Same for other types too. e.g. paren!

My last try.
It doesn't work with decimals

the key here really is that AND  ;-)

>> [a/0.3/a]
** Syntax error: invalid "decimal" -- "0.3"
** Near: (line 1) [a/0.3/a]

>> [a/0.3/a]
** Syntax error: invalid "decimal" -- "0.3"
** Near: (line 1) [a/0.3/a]

Ahaaaaaaaaaaaaa