World: r3wp

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

and THRU multi is even simpler:

    a: [thru b]

is equivalent to

    a: [b | skip a]

yep... all hard to understand and code in real life.  which is why 
I say that the new keywords, just make it easier to parse stuff. 
 They aren't hacks or tricks anymore, they are supported directly 
by the parse dialect.


its like the stack handling... its just going to be MUCH simpler 
so use push, than tinker with your own stack.

or rather 'USE ... sorry.

I'm not saying STAY isn't useful, just that it is lower priority 
than AND because it's use is more limited.

you see the thru multi you show... is excessively hard to "see", 
even I look at it and have to wrap my brain against it, and its really 
not "obvious"

I like having STAY though, since I am one of the advanced parse users 
that would find use for it, like Maxim and Carl :)

we will see...

A

as shown above, it is superfluous; the a: [b fail |] rule is exactly 
as simple as a: [stay b]

All of the new additions are superfluous, Ladislav. They were added 
to make our lives easier, not to enable stuff we couldn't do before.

I'm  looking at this.....    a: [b fail |]  and its totally obscure 
... I don't see it at all, I can study and eventually "understand" 
it, but within a 1000 line parse rule... <eek>. 

the way I see STAY is: [pos: b :pos]

(speaking as a general user... not myself specifically)

Sorry, that's still AND. STAY is [pos: opt b :pos].

well, I do not think, that e.g. NOT is superfluous, since it substantially 
simplifies the expression. This is not true for STAY.

The fact is that all of these were added to make our lives easier. 
Now I don't think STAY is worth the effort to implement it, but given 
that Carl *already has* implemented it, it it worth removing? This 
is regardless of the merits of AND, which are unquestioned.

NOT is very important, especially because charset can't be complemented 
in R3 (Actually they can, but it's a monstrous thing to add all the 
possible chars in a bitset, just to skip someones)

I agree that if we were to dump all of the enhancements but one, 
NOT is the one I would choose :)

We could fix charsets too (add a complemented bit), and that would 
help too.

would be useful for FIND

unless Carl implements the find/not refinement

I agree that if we were to dump all of the enhancements but one, 
NOT is the one I would choose :)
 - I guess, that it is my favourite too

Carl *suggested* the find/not option :)

'NOT  and the 'TO/'THRU multi.  its just soooo much simpler to slice 
and dice text using it, which is a large percentage of what parse 
is used for.


I remember Carl's historical reason that it made us lazy... hehehe... 
his CR.LF stripping example shows that he is quite lazy himself  
;-)

TO/THRU multi is not so important in text parsing because we can 
use charsets

I am just curious, whether Carl intends to implement the full TO/THRU, 
acting on any subrule

it's working now in a84

It is badluck, that recursive rules are not useful in fact, since 
the stack is too small :-(