World: r3wp

they were long time dismissed by many, but I am glad the attitude 
changed :-)

yes... how many times I heard the term... it break's parse's "purity" 
 yerk...  it makes me loose money (cause I have to spend more time 
writting complex rules for simple tasks).

:-)

Updated the proposals page with the changed proposals (to the best 
that I can figure out).

Could someone decode how to read 'either parse syntax? I am still 
confused. The word is absolutly wrong, if infix, I can only imagine 
it, if prefix.

[parse "ab"      ["a" either "b" | "c" | "d"]]


How to read it, please? If "a" is being matched, then try to match 
"b", or try to match "c"?

Think of it as ?

My other word favorites are:

then (absolutly best imo)
try
only

did we ask for too much and unleashed a monster in Carl?  ;-)

also
 would work here. a also b | c

I'm thinking that giving too much fun stuff for Carl to do is scary... 
he should go back to extensions...  or maybe not... he might popup 
a full ANSI C parse rule,  in an hour, just to prove its easier than 
before ;-)

a 'WITH b | c

then , try (too much implies rebol's try?), also , next , with , 
only

but imo THEN makes the most sense ...

I agree... then is the most readable and is pretty close to the meaning, 
and especially since then is related to if then else.

brian - advanced stuff like [a 2 + b | c | d | e]  still possible?

well, 'still another name :-)

posted another bunch of favorites ...

Sorry, I find using words for infix operations to be confusing. Better 
to adopt two-char symbols.

There is some truth to it, Henrik. It took me some time to realise, 
why 'either looks weird. As you said - I tend to look at the right 
side of it = prefix, not as an infix.

I am against + sign though. I thought about equivalence of 'then, 
which is sometimes expressed as ==>, hence => or -> would be enough, 
although a bit cryptic. The word 'then is still my favorite ...

Brian: I can't see 'change implemented. Or is "change" done by 'insert?

... ah, 'change is planned, just not yet done or documented ...

hmm, 'and reads much worse in the example at the end of parse doc, 
than STAY or HOLD would read there ...

I suggest anyone interested, to read example at: http://www.rebol.net/wiki/Parse_Project#Examples
, to see, how it "feels". AND keyword is like an alien from the outer 
space there, and if there would not be comment at the and of the 
line, stating (after fixig a typo): "Back in the same position as 
before the AND.", you would hardly know, what does have AND (most 
often perceived as logical operation) in common to keeping the position 
at original series index? Why not STAY, KEEP, HOLD?

Or do I understand AND meaning incorrectly?

It is called AND because it means that something at this position 
has to match one rule *and* another.

Your other suggestions give too much unnecessary information about 
backtracking. Compare the | word (meaning OR), which doesn't mention 
backtracking.

OK, but - what happens after the match? (at the end of the block) 
- where is the position? At the end of currently matched rules, or 
at its beginning? Because my initial understanding was, that STAY 
was supposed to match the rule (look-ahead), but, it did not advance 
the positon. And if it is true for AND, it does more, than its name 
suggests, no?

As for EITHER/+, my favorite proposed name for that is now =>. We 
absolutely have to use '| for the second part, since => is *not* 
an infix operation, it just looks like one. Since we can't use 'else, 
'then looks a little silly, as do all alphabetic words when paired 
with a symbol like '|. We need another symbol, and => implies advancement 
without making it seem that the data position is being advanced like 
'next would.

If both rules of the AND succeed, then the ending position of the 
second rule is what you end up with. It's like shortcut boolean and.

I never perceived I as OR. I simply thought about it as about some 
wall, separating option slots :-)

Nope, it's an ordered OR.

Brian - that makes a difference then ... isn't example comment wrong 
then? "Back in the same position as before the AT."

Let me check...

forget AT, there should be AND, it is a typo. But as I understand 
it, it returns back at initial position?

As you described AND few moments ago, it sounds logical - if all 
conditions are succesfull, then OK, otherwise return to the starting 
position right in front of AND?

Ah, but you didn't get that AND only appears to take two arguments. 
It actually only takes one argument, and the second works on its 
own.

hmm, so and is not semantically aligned with | ? I mean [a & b & 
c]?

btw - how is that => is not infix?

Simply put - so far I am confused ....

AND has to be prefix to work, which is why it isn't called &. Algorithmically, 
it is the commplement of |, which needs to be infix to work, and 
is the only operation that *can* be infix. Implementation restrictions 
that we try to make sensible, by using visual naming tricks.

OK, but - we always think about OR vs AND as their logic counterparts. 
Now it is not true, or is it? By our definition:


AND: Purpose: A look-ahead rule: Matches the parse rule without changing 
the current position. 


I am denerved about the "without changing the current position" part. 
It is some explicit rule user will have to know. Why not to advance 
the position?

All of these are rules the user will need to know. It's a programming 
language, not baby talk.

hmm, actually I wonder, how can I match one input stream by multiple 
rules (the real logical AND), this is not probably even possible 
:-)

The whole point of AND is to *not* advance the position. It allows 
you to check more than one thing about the same data.

AND block! into rule - does mean - check if the next match is being 
a block, but don't advance. And if so, go into rule? If so, then 
AND is totally weird name ...

It works the way you want.

I need following to work in terms of parse dialect :-)

keep: :and

Not a weird name, it is the closest equivalent to a logical and that 
you can get in a backtracking system. The only weird part is that 
it is prefix instead of infix. However, if you remember that *all* 
parse operations are prefix (except | ) then it won't seem so weird.

=> needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all:

- The a is matched first, and if it fails it backtracks and advances 
to the next alternate (aka, past the next | )
- If a succeeds then the next rule is processed.

- The next rule is =>, which matches its argument rule and then skips 
the next alternate, whether the rule succeeds or fails
- b is the argument rule of =>
- | c is what => skips