World: r3wp

But some ideas stay relevant.
Incremental parsing.
Allowing incremental syntactical checkings.

Allowing fast modification of the document (sort of DOM capability).
Only what is modified indue styles reconstruction and rendering.

(Copied here) If you are using PARSE for incremental parsing, watch 
out for this: http://issue.cc/r3/1787

No prob, I was here during the related discussion.

Btw, if there are other bugs in R3's PARSE that need to be discussed 
before being submitted to CureCode, this seems like a good group 
to do so.

could this be linked with a wiki page in rebolfrance.info and alimented 
with the tips and tricks from here ?

Don't forget this: http://www.rebol.net/wiki/Parse_Project

Ladislav has been updating that page lately, but it could use acceptance 
status references.

No prob, I already overpower parse In My not so Humble Opinion.

I already have many attempts with incremental parsing, even with 
R3.
I just try to come with the best design.

Does anyone know if there is any difference between the REJECT and 
FAIL operations? Was REJECT just added as a FAIL synonym because 
ACCEPT was added?

The internal representation of the Document is the hard point.
Incremental parsing means caching some infos during parsing.

What to cache, what not to cache, and in which form, that is the 
question.

same question with accept and break.

maybe just synonym currently

Btw, i found a bug I think, with INTO

There was a change to INTO in R3, so any bugs in it might be that, 
or related to that. What bug?

INTO [... accept] or INTO [.. break ] will fail if the serie position 
is not advanced of  at least one step before the accept or break.

(not sure I'm clear)

Not clear, because I can't replicate the bug from the description.

Well, it's worst, you can't exit from an INTO command with ACCEPT 
or BREAK

>> parse ["12"][into [2 skip] ??]
end!: []
== true

>> parse ["12"][into [skip accept] ??]
== false

should be true to my mind

ACCEPT and BREAK break from loops, though loops might not mean what 
you think they mean.

so you have to use the same trick than with R2
TO END

The block passed to INTO is (in theory) supposed to be treated the 
same as a top-level rule passed to PARSE.

Yeah but... I'm a little disappointed

The top-level rule is the only rule that isn't considered to be a 
loop, but I guess that counts for INTO as well. All other rules have 
an implicit 1 1 loop around them.

It's like wrapping every statement in a LOOP 1 [...] in the DO dialect.

so far, the syntactical rules for rebol scripts.



https://docs.google.com/document/pub?id=1kUiZxvzKTgpp1vL2f854W-8OfExbwT76QUlDnUHTNeA


(Not produced the transcode rule though)

But it's enough to perform the prefetch of a document and to construct 
the internal representation.

>> parse [] [reject]
== true
>> parse [] [fail]
== false
Apparently REJECT only works on loops.

yep, has to be notified in the Doc if not

Note: If using the new TO or THRU syntax to recognize something that 
would require a QUOTE to recognize otherwise, use the QUOTE in the 
TO or THRU. If you don't, there are bugs.

>> parse [1] [thru [quote 1]]
== true

>> parse [1] [thru [1]]
== true  ; should be a syntax error

>> parse [1] [thru [1 2]]
== true  ; should be a syntax error

>> parse [1] [thru [1 2 1]]
== true

>> parse [1] [thru [1 2 2]]
== true  ; should be false

>> parse [1] [thru [1 2 1 1]]
== true  ; should be a syntax error

>> parse [1] [thru [quote 2]]
== false

According to the original proposal and what Carl said when he implemented 
it,
>> parse [1] [thru [1 2 1]]
== true
should be a syntax error too.

Difference between REJECT and FAIL:

>>  parse [] [while [reject]]
== false

>> parse [] [while [fail]]
== true

THRU and TO have lot of restrictions.
You can't use them with charsets.

you can't use nested sub-rules or anything else than simple values.

It is best to use the correct syntax for now if you want your rules 
to work. You can't count on PARSE to trigger syntax errors when it 
should, for now.

(FAIL is a rule that fails, while REJECT makes the rule that contains 
it fail, even if it is WHILE, or ANY)

Steeve, that is correct, but problem is that you aren't supposed 
to be able to "use nested sub-rules or anything else than simple 
values" except QUOTE, but PARSE is doing things incorrectly instead 
of triggering the error it ie supposed to trigger.

as opposed to that, ACCEPT and BREAK don't differ

Ladislav, it makes sense

Steeve instead of TO RULE use WHILE [at rule break | skip | reject], 
and instead of THRU RULE use WHILE [rule break | skip | reject]

I know, I already use it, though, I use some [..] more frequently

ah, sorry, it is not AT, but AND, which should be used...

Btw, when a stack overflow occurs, It's terminating the console without 
sending any warning.
Did you experiment that ?

parse [ ] r: [ r ]

Vista says something bad happend, but XP just close the console.

Win 7 says
  internal error: stack overflow

Which means that stack overflows aren't being checked by PARSE. Write 
a ticket.

Went through the Parse Proposals list and tweaked the Priorities 
section to double as a status list. Unfortunately, some of the rejected 
proposals must have at some point been removed from the proposals 
page. We wanted to document them and why they were rejected, so they 
don't get proposed again. I may have to go the history and find the 
rejected proposals that were deleted and restore them to the page, 
so they can be rejected explicitly with explanations.

The main ones missing that need documented rejection are the alternatives 
to the USE and INTO proposals. The reasons they were rejected provide 
valuable information about the way PARSE works internally, information 
we don't want to lose.

The TO or THRU NOT proposals need to be restored as well, so they 
can be explicitly rejected.

Especially since they are referenced elsewhere.