World: r3wp

btw - how will you explain it to the user? Maybe it is just too new, 
but unless you provided me with [a b | not a c], I was not able to 
depict [+ a | b | c]

OK, let's try an easy one. Try to explain + without usingh the word 
"addition". Symbols are sed for a reason.

but its just being picky... the real thing... is what is evil about 
blocks?

but you see its not an addition.  its "go-over-this-and-accumulate-failure-or-not"

here... we have the precise name... its over 30 chars long   ;-)

we went too far. We should accept Steeves proposal - allow EITHER 
to be embraced as using condition OR the rule. Single as that. You 
can't beat the EITHER name. Thinking here and there, I can't imagine 
how + could be named, with the used syntax ...

Alright, explain the arithmetical - without usoing the word "subtraction". 
I had switched subjects. Oh, and don't use "hyphen" either.

actually, I think there are better words than either.

Brian - not, it is you, who can't explain it in fact. You can come 
up with a sensible name for the pattern of usage, so you throw some 
obscure symbol at us :-)

you can = you can't

Symbols mean different things depending on context, and the context 
here is parsing, not arithmetic. We still need to use them.

Max already said it - here's the name :-) "go-over-this-and-accumulate-failure-or-not"

I'm thinking  about something along the lines of   subject-to

providing

I suggested to Carl kind of syntax for the equivalenc to CASE or 
SWITCH ... maybe one of those two?

I don't need to explain Carl's + semantics because Carl was quite 
explicit in his own explanation. It made sense if you know parse 
theory, and you won't use it if you don't know parse theory. Maxim's 
term was inaccurate, though he's getting better.

PARSE itself is equivalent to CASE, so no syntax needed.

BRANCH was the best term before Carl came up with +.

I do have the proper word for IF, semantically....  'DEPENDS.

Must be prefix.

as in this RULES depends on this RULE

Max - we have to stay with + or some other symbol. If you look at 
examples, there is stuff like [a 2 + b | c | d | e] and I don't think 
any name will fit all usage scenarios.

yes I know ... but we never had a single word which properly explained 
what is going on ... now we do.

(for if)

Only some words can be infix, depending on the semantics of the operation. 
& and | (whatever they are eventually called) can be infix. The rest 
have to be prefix.

I'm sorry, but the |  will just end up being


 [   complex rule with its own  "|" symbols ] | [   complex rule with 
 its own  "|" symbols] | [  complex rule with its own  "|" symbols 
  ]  so really the use of "|" jusy adds clutter and ambuiguity.

When you don't have a descriptive term that covers an idea, you use 
a symbol and tell someone to learn it.

but the idea about REBOL has always been to be anal about FINDING 
those terms... Carl himself has admitted to using up more time choosing 
mezz names than coding them.

PARSE already has a lot of | symbols, and the operation currently 
proposed to be named | actually ties intto the current semantics 
of those | operations.

currently proposed to be named +

what are you talking about? You want to change the meaning-of, or 
replace | symbol? :-)

I'm having trouble typing because of AltME freezes.

Pekr, *you* want to change the | symbol. Or rather, you want to do 
something exactly equivalent, changing the corresponding & operation 
to STAY.

| is visually good ... it is like wall dividing slots ... it fits 
... the + is more complex. Guru stuff, which we will have difficulcy 
to explain. Maybe it can't be done the other way. So - user has to 
learn what does it do by examples, get used to it, and then maybe, 
he will understand it, once he sees it in the code. The only question 
is, if eventually naming it, or changing the syntax to achieve the 
same, could be done more elegantly, which I start to doubt.

There is NO & operation ...

... not in current parse. Just in parse theory. I don't care about 
the theories.

... you are just using those excuses. Simply put - if you want STAY 
instead of AND or &, then we will throw it back to you, accusing 
you of the need to change already used | symbol by giving it a name 
:-)

Proposed. Originally, Peta renamed & to AND since he (she?) thought 
that a spelled-out word was required by the dialect. Then I changed 
AND to AT since I didn't know infix operations were possible. Then 
Carl changed AT to STAY, since he didn't see the point. Then he realized 
what the operation meant and changed it back to &, what it should 
have been in the first place since it is the opposite of |.

I was always thinking about parse being an alien in the parsing world. 
It was just Peta who introduced us to the TDPL, PEG and other terms, 
trying to fit it to various theories. My opinion is - if such changes 
will not lead to eventual direct usage of already existing parse 
rules somewhere out there, then I don't really care about all those 
theories. We are already unique, and I don't want parse to go back 
adhering to some "standards". It feels the same, like changing feel, 
face, facet and all the naming to fit more general naming convention 
of the outer programming world ...

TDPL wasn't used, and PEG was created to describe parsers like PARSE, 
and 5 years later than PARSE was.

The rest of the world is catching up with where PARSE has been for 
10 years.,

And the reason we are adopting operations from PEG, TDPL and GTDPL 
is because they fit into PARSE's semantics and are useful.

It's just filling in the blanks.

sorry NOT for +

I just want parse to stay readable for average man. The more symbols 
we add, the less readable the code might be at first sight. We should 
be carefull, or Larry Wall steps-in commenting R3 arrival, stating 
that R3 added even more punctuation :-)

although for "&" I agree, it really is just a single letter symbol 
which means AND, which in this case is right.

especially if the rule is infix (which it seems it will be  :-)

Perl 6 has already surpassed PARSE in its own category: their "regex" 
engine is a PEG parser, and has useful stuff we're adding now.

parse hasn't really evolved for what... 10 years?

PARSE was unique, but is becoming less so.