World: r3wp

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.

I always thought it would be one of the first thing R3 would work 
on.

PARSE added OPT and BREAK more recently than 10 years ago, and bugs 
were fixed, but otherwise unchanged.

I do thing BRANCH is the better term for the either / + keyword

thing = think

or  BASED-ON    :-)

This seems like a really good candidate for a symbol, but finding 
a prefix one is tough. If it could be postfix we could use ?, or 
even +. Postfix would look like infix, or rather like C's ?: when 
combined visually with the next | character.

I saw BASED-ON as a prefix symbol.

based-on rule | yay | nay

Then [a ? b | c] would be equivalent to [a b | not a c].

possible name for +  might be: ELSE or OTHERWISE :-)

Not in prefix it wouldn't be.

brian:   post fix ? is  actually not bad... and since condition rule 
is traversed anyways (either its true or false) .... it probably 
doable...

yeah so far, the only prefix term which reads well IMHO is BASED-ON

What I don't know is whether it is possible to do postfix anything 
- failure might cause backtracking before the ? is reached.

I really like, like in the end we are going to decode it for the 
users in documentation - "Now, you parse user, please read following 
syntax as - EITHER rule A is matched, THEN B is evaluated ELSE C 
is valuate" ... yet we will pretend, that we came up with some cool 
symbol to express what we just had to explain in human words :-)

no we won't use either... cause that is not what is happeneing.

;-)

attempts to match a rule, AND runs first rule if it matched OR second 
rule if it did not.

no? how do you explain [a b | not a c] then? I thought that - EITHER 
(IF) A is mathed, then B is being matched, or C is being matched 
(by being matched I mean - evaluated, hence might fail)

Max - who decides, what EITHER mean in parse context? We do. I can 
say - don't use COPY, as this is not what is happening (in REBOL's 
copy function semantics equivalence)

but copy actually does copy what is being parsed.  either isn't comparing 
a value like the if PARSE statement.

Max - you are NOT in REBOL level, so free yourself from pedantic 
"EITHER uses this syntax" equivalence, or dismiss COPY keyword too 
- it absolutly does not fit REBOL and even today on blog I had to 
fix Ingo's type, where he ommited to provide parse COPY with word 
to copy to ;-)