World: r3wp

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.