World: r3wp

I don't like ! instead of NOT, siince it's too hard to distinguish 
visually from |.

I don't clamor about parse not being like RE - that is its strength. 
I've never considered that difference a problem.

parse is readable, I'd rather have EITHER with blocks than some infix 
operators which loose the sense of PARSE...

sorry I mis-interpreted that word as a loud bragging.

(clamor)

And they're not implied branches - it's an explicit statement. If 
you don't like the name + that's fine, it's the changed semantics 
I like.

The only problem that I have with + is  that it's *not* an infix 
operator, it's prefix.

this is really - WTF for me. It turns parse into unreadable guru 
stuff with such a semantics ...

& would be infix, a replacement for STAY (originally called AND, 
then AT).

just don't replace STAY word with &, if you don't want to make situation 
even worse ...

its like saying 


when I say implied, I really mean that you cannot just look at rules 
like they are now with a single use bblocks for many rules.  it terminates 
 somewhere later ... you must find an  | statement....  which doesn't 
properly map to open or close something... its implied based on something 
else before it...  [ ]  are explicit.

STAY was a bad choice. AND was better - the only reason I picked 
AT is because I thought infix was impossible.

its like saying
  sorry... don't know where that came from... ignore

but what's the point of AND   everything is already AND by default. 
just put them in a block, so they are and.  when you read & it doesn' 
appear that the parser isn't moving forward.

EITHER doesn't work like EITHER, and it needs to be prefix, and use 
the semantics of Carl's + proposal or it won't work. Suggest a name 
to be used instead.

the only thing he's complaining about is putting things in a block... 
what's the problem with that?

either [] [] []  can't be more explicit thant that... what is the 
problem with blocks?  or a paren for the condition?  really I don't 
get it.

If you see | it doesn't say that the parser is backtracking either. 
& is the opposite of |.

To use a tool it sometimes helps to know how. Assume some basic reading 
of docs will be needed to use a programming language.

BrianH: COPY is NOT COPY, so what?

EITHER doesn't need to skip past |, so pick another name. It will 
be prefix. Suggest it in the 249 blog.

This is not the same thing as a programming language conditional 
- it is a GTDPL concept.

Just like CHECK isn't like IF, it's like ASSERT.

I can't suggest anything, as I don't understand what the article 
is all about. Stuff like  - "advance past the next 2 alternate rules 
on failure."

And I can tell you - if I - the occassional parse user can't easily 
decode the meaning by just looking into the examples, there will 
be many such users ...

... and - I don't buy arguments like - it is a GTDPL concept. Our 
(parse) users will not care about such statements. We are not here 
to adhere to any academic theories, but to make things usefull. If 
we wanted to adhere to what the world uses in parsing area, we should 
go the regular expressions route ...

OK, enough. I will wait how it turns out. Let's just remember, that 
we can go our own way, as parse already does. No need to turn it 
into obscure other whatever-parse-old-70ties-theory-suggests things 
...

Do you get that the concept needs a name, and that obscure concepts 
also need names? The standard syntax for this concept won't work 
in REBOL, and the only other comparable parser is the one in Perl 
6, and we can't use that syntax either, or its semantics either (it's 
compiled). This *is* guru stuff - people get PHDs about parsing. 
Carl's proposal for +'s semantics is the way that this has to work 
given how REBOL parsing is implemented.

the thing I don't  *get*  maybe you can explain, is where he adds 
the increment to the '+ ... what does that mean... really I don't 
grasp it.

Now, *that* is obscure. Noone else does that, not even Perl 6. That 
is unique.

but what does it mean?

dang ... I just *got* it...

either  [ a | b ]  [ c ] [ d ]

I don't mind the possibilities, I do care of naming and how long 
does it take for me to interpret it. If we go + route, we can change 
NOT to !, add &, II, >, -->, etc. :-)

NOT is not going to be !, for the reasons I already mentioned.

you see? looking at what Max just posted, I *imediatelly* can understand, 
what does his code do.

& makes more sense than STAY, because it relates to |. Both backtrack.

still don't see why the use of blocks is evil when its the way of 
parse for everything else.

Now I don't understand once again - if you are suggesting just changing 
the name of STAY to &, then please DON't do it!

Maxim, the a's in Carl's examples aren't involved in the expression.

Pekr, no, Carl was thinking of changing AND to STAY, but decided 
against it when he figured out how to make it infix.

Maxim, "everything is already AND by default" is not true. Everything 
is "and then" by default, which is AND with moving forward. What 
we need is AND without moving forward. An infix & handles that nicely, 
and is the opposite of the infix | meaning OR.

Ladislav just cheared to how Carl is precious about naming, and he 
liked STAY and QUOTE. STAY imediatelly expresses its meaning. Changing 
to to AND makes the situation only worse ....

So you want to rename | too?

brian  yes... I am wrapping my head around this... but I have to 
re-read the STAY proposal before getting too vocal... I'ts been to 
long since I've read it.

I actually wouldn't mind it being 'OR

(bts... about the 'a yes I didn't use the same vars in sequence... 
sorry)

[+ a |  b | c] is equivalent to [a b | not a c] but without the overhead 
or side effects being executed.

So, do you have a name for that?

This is really just - EITHER A [b][c], no?

[a b | not a c]   actually it should say... [ [a b] | [not a c]] 
  sorry but the |  doesn't roll back the a it will only roll back 
the b... its bit me too many times

No, because the a is not a condition, it's a rule.