World: r3wp

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.

Maxim, Steeve, I also prefer REMOVE 1 (my original proposal from 
November) and CHANGE 1. REMOVE 2 is too fiddly to satisfy the bug-reduction 
purpose of the CHANGE and REMOVE proposals.

I think carl also prefers it, especially since he wrote as a pre 
rule, so it needs no explicit blocks on simple rues.   :-)

Maxim, Did you miss the more recent note where Carl announces that 
your preference has been implemented in a84 ?

About that bug: CureCode it. I'm serious, post it ASAP.

Which bug ?

remove copy

yep... I read it just after posting  :-)

Brian, you said: 

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.

you mean something like:

parse [...][ STAY rule remove something]

but it's the same thing that:
parse [...] [remove something]

i don't see your point, give an example please.

PARSE bugs, particularly new ones, are all urgent priority. This 
is what we're working on now.

REMOVE doesn't advance, so STAY isn't needed. That's why I didn't 
mention REMOVE.

steeve, remove is the odd case cause it returns the original position 
anyways, insert moves cursor past insert

CHANGE or INSERT, or rules containing productions.

I would stay A LOT with remark  , stay  its just a shorthand for 
  

 pos: [rule] :pos 

 but its handy  :-)

No, that's AND. STAY is pos: opt [rule] :pos

Brian, try it with INSERT if you want, it's the same useless thing.

>> parse a: "123" [STAY "456" insert "0"] a
== "0123"

Exactly the same thing that:

>> parse a: "123" [insert "0"] a
== "0123"

STAY has no use

You are still putting the matching rule as the stay argument, not 
the modifying rule.

hmmm....

i give it a try

oh I see...

>> parse "123" [insert "0" ??]
end!: "123"
== false

>> parse "123" [stay insert "0" ??]
end!: "0123"
== false

Right now, since we don't have CHANGE, the opt aspect of STAY doesn't 
matter with INSERT. To have use you have to use it with rulees with 
productions in them.

i see a little better now

STAY is equivalent to OPT AND or AND OPT.

Just like AND is the (much less annoying) equivalent of NOT NOT, 
in theory.

Brian, i posted the bug, you can rewrite it now :-)

Cool, thanks :)

Done.

the

    a: [stay b]

rule can be rewritten as

    a: [b fail |]

generally, I am of the opinion, that it is superfluous

many of the parse rules are shorthands for already doable things 
(except 'NOT and to/thru multi)

moreover, the AND rule is usually what is desired, not the STAY rule, 
which is just a bug. I do not know any really meaningful use case 
for STAY; the above INSERT surely isn't one

remark could be rewriten using stay, and it would be much simpler 
to build/read.

That's why I put STAY so low on the priority list. Maxim, you are 
still confusing STAY and AND.

nope.

you do not know shorthand for NOT? It may be as follows:

    a: [not b]

is equivalent to

  a: [b then fail | none]

nope remark does what I call persistent parsing.  it only moves ahead, 
once all INNER rules have recursively flushed themselves out.

with inner parsing rules modifying the input and potentially triggering 
new parse matches.

cause inner rules generate parse-able content, which was not part 
of the original input.

true functional unfolding  :-)

the Rebol programming wikibook contains a bunch of such idioms