World: r3wp

*we can't

/all still affects simple parse (splitting instead of rules).

With the PARSE changes, this puts us within the range of a parsing 
model with a reasonably solid theoretical foundation and a lot of 
experience with parser generators. We could compile PARSE rules into 
equivalent incremental rules.

yep we could start by building a compiler of rules into  incremental 
ones (with rebol i mean)

i made some tests in the past

About STAY, i don't see the interest to continue even if the following 
rule is not matched . Can someone give an use case ?

because when i  do this:

>> parse [1] [stay skip ?? to end]
to: [1]
== true

or

>> parse [ ] [stay skip ?? to end]
to: [ ]
== true

it's like doing:
>> parse [ ...] [?? to end]

STAY have no purpose to my mind...

It's just a little annoying, see:

>> parse a: "12" [remove copy val skip] print [a val]
==2 none


So, the [remove] treats well the [skip], but discard the content 
of [copy val]

Now, see:

>> parse a: "12" [remove [copy val skip]] print [a val]
== 2 1


The content of [val] is preserved in that case, don't know why here, 
but not above...

I would expect 'val being 1 in both cases .....

But maybe reading the "expression" the REBOL way - from left to right, 
is not correct?

i rather think it's a bug

Is it that REMOVE takes one argument?

Yes, it takes on argument - the rule ...

(I'm just reading that new blog article about it... Sorry for adding 
new ignorant question before doing anything to alleviate my ignorance.)

sometimes getting reply here on altme is faster than reading corresponding 
article :-)

That's not the problem, SET VAR ot COPY VAR are not rules, they should 
not be "viewed" by REMOVE

I am still guessing at what is intended in R3-a84 but the first looks 
OK and the second looks like a bug                               
                                                                 
  >> parse "abad"  [thru "a" stay [to "b"] (print "at b") thru "d"]
at b
== true


>> parse "abad"  [stay thru "c" (print "at c")  [to "b"] thru "d"]
at c
== true    ;   BUT must still be a bug

It's not a bug, it's behaving like Carl wanted. 
The final question is:  To do what ?

STAY could be a by product by wrongly implemented AND.

Yep, a bye bye product

express yourself via channels Carl listens to - blog, chat, or even 
better - CureCode ... :-)

I would like to say how the new parse is powerfull and light.
For example: 
I have a block which contains 1, 2, or 3 values

I have to insert something between 1 and 2, if there is at least 
2 values.
and something else between 2 and 3., if there is 3 values.

See:

parse block [
	skip
	not end
	insert [ _ ] skip
	not end
	insert [ . ]
]

Is that not marvelous ?

this is how it works in A84?

And we still don't have IF, USE, INTO string!

just think how you would do my example with standard code, it would 
be more verbose.

how does skip not end work? I don't get it.

skip is skip,no?

not end means, that the rule is matched as true, if not at end ...

it is kind of check

does skip mean, skip 1 element?

if not at end, insert [.]

yes, skip is skip 1 by default ...

not skip 1, but 1 skip ....

ah, forgot that the block is only of max. three values

BTW, why are we saying END instead of TAIL ?

parse block [
	skip   ;** skip the first value

 not end   ;** check if the block have a second value (if not, then 
 stop)

 insert [ _ ] skip   ;** insert what is inside [ ] before the second 
 vlue , skip what it has been inserted, and skip one more time to 
 pass the second value.
	not end  ;** check if there is a third value (if not, then stop)
	insert [ . ]  ;** insert [.] before the third value 
]

I think I get it now, thanks.

I wonder if we can test against a larger parse project now, such 
as postscript.r?

i widely using it now, i rewrite an assembler/desassembler for Z80

STAY is only useful for rules with effect: modifiers, and rules containing 
productions. Sometimes you need to do stuff where necessary and not 
care whether they were necessary later.

We do have IF (renamed CHECK).

It's theorical, i wonder if it's of any real use because we can do 
what you mean without STAY.

END is a keyword. This is PARSE, not DO.

I am of the opinion that STAY is of (very) limited but significant 
use, but that AND is of critical, everyday use, as much as NOT.

i want see the code where you demonstrate that STAY saves something.

i'm not convinced :-)

i agree for AND urgency

STAY is of use when combined with CHANGE or INSERT, when you want 
the parse position to be set to the position before the insert not 
after, and when the modification is optional, or otherwise doesn't 
need to be specially checked.

I posted on the blog about REMOVE.  much prefer matching a rule.

since we can easily do [11 skip]  to simulate an index.

STAY is a more efficient shortcut for OPT AND.