World: r3wp

I am also concerned about the security implications of having PARSE 
call functions outside of parens. In parens you know what you're 
getting. This is why QUOTE and IF require parens for the REBOL code 
they execute.

All of the added operations could have been done before with code 
in parens and/or explicit position setting. It's easier this way.

I put a note up because of my silly misunderstanding of the intent 
of adding AND to PARSE.  But I get odd results with the likes of 
   parse "abeabd" [and [thru "e"] [thru "d'"]]  which behaves like 
ANY

Not a silly misunderstanding, a bug, bug#1238 in particular.

One of 4 parse bugs in a83.

OF course in STSC APL  "laod" was as good as "load" and in Smalltalk 
I still long for "slef" and "sefl" but I draw the line at "elfs" 
which is clearly unfit in the age of "octopuses"

And that doesn't even count the stuff not implemented yet.

I thought ONE (but no move) on the model of SOME and ANY when I was 
misunderstanding AND as "all"  as [ ONE [rule1 rule2 rule3 ] ]

ONE would be an interesting name for the OF proposal.

Shorter than UNIQUE

Sorry, that would be a different operation.

Shorter than FROM or GATHER though.

Wait, ONE wouldn't work, since you actually get all of the rules, 
just not in order.

I posted examples to show why a84 is more rebolish. http://www.rebol.net/cgi-bin/r3blog.r?view=0255#comments

looks good ...

Steeve - will better parse help with editor? IIRC it was you and 
Shadwolf, who did it?

A little, but the main drawback i have with parsing in editor is 
that parse doesn't handle incremental parsing.

Because i do parsing line by line to be able to parse only modified 
lines.

So that, i have to rewrite all the rules (describing the document) 
in an obfuscated way to deal with incremental parsing.

BrianH has some plans towards "streamed" parsing. Hopefully it can 
be done over ports in the future ...

Actually, we can simulate streamed/incremental parsing. But we need 
to transform all the input rules (it can be automatized).
I would prefer an inlined behavior of parse for such purpose.

It's why i asked to Carl if we could return the rule stack during 
parsing (i.e. with a special command).

What was the answer? I missed your request during yesterday's chat 
probably ...

Request delayed for R3.1

3.1 - that will be in Spring, so I think that we can wait ...

it seems

parse is in mode parse/all by default now, but we can remove the 
option, a bug ?

*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?