World: r3wp

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

Strangely enough, you can think of the | as being prefix as well: 
it signifies the beginning of an alternative.

Does AND, in our parse situation, have anything in common with math/logic 
AND? I am not able to see so deep, but I know that parse is in fact 
some deep math ...

AND is like the shortcut boolean logic and. | is like the shortcut 
boolean logic or.

And can I explain, by such math layer, why it moves, or not? All 
I am trying to find out is, if we can explain to the user, why "AND 
block! into rule" does not consume block! position :-)

Because that is how you can check that the current value is a block! 
AND matches into rule.

re: => needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all ... I thought, that underlying C level can decide, if 
something can be prefix or infix = match a and look if next keyword 
is =>. But then it would mean, that we would slow down parse engine? 
Because then we would have to perform such check for each rule applied, 
to check if eventually => follows?

Because that is how you can check that the current value is a block! 
AND matches into rule.

 - remember that one for the docs. There will be many stupid users 
 like me, trying to understand, what the heck AND is doing and why 
 it is doing so = we want to have description theory why it is the 
 way it is :-)

The evaluation method requires that operations be prefix - it's a 
state machine. The only carried-over backtracking state is used to 
implement | alternates. It would double the complexity of PARSE to 
make another infix operation.

I've learned a lot about the implementation of PARSE this week. I'm 
almost to the point of being able to write it myself.

Hmm, interesting. Does not Carl think of 'either in terms of infix?

I like => more and more (especially as I suggested it :-), but Henrik 
suggests, it has different meaning in Math. Is that true? I do remember 
that I often use ==> to express "then", so I just shortened it to 
=>

I was also inspired by one script, and now I dont remember which 
one, which used something like ---> in combination with some indentation, 
but maybe it was just a debug output ...

I havn't commented much on parse because I tend to only use it in 
its most simple form:

	parse string delimiter


which got me thinking that, if we havn't already, perhaps this major 
use case is deserving of its own "split" function?

>> ? split
USAGE:
	SPLIT series dlm /into

DESCRIPTION:

 Split a series into pieces; fixed or variable size, fixed number, 
 or at delimiters