World: r3wp

[new group for R3 parse discussions, as requested]

Brian, yes I will provide a special (already constructed ) rule to 
 parse stream of valid rebol value/word

Would this be a good place for TRANSCODE discussions too?

I think it is IMHO

A couple projects that I would find interesting:

- A recovering loader for REBOL source (using TRANSCODE and a manually 
created stack)

- A dialect compiler for R3 PARSE rules that generates the R2 workaround 
code

Steeve, if that rule is already constructed, it could have use beyond 
an incremental parser. Any chance it could be MIT licensed for inclusion 
in R2/Forward as a TRANSCODE backport?

Well, I alredy have in my mind to use the lexer to perform an incremental 
loader.

So that, we could use it to perform incremental execution of rebol 
code 
-> a code DEBUGER

Yup, IDEs need debuggers :)

that was the idea behind areat-tc to begin with, but my design was 
too much  narrow minded.
It ended in a bloated huge script of 45 Kb, with bad readability.
It''s requesting a more moldular approach.
I think I learn a lot after such mistake.

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