World: r3wp

Yes, parsing a dialect I have to produce PDF output.

wow, cool.

Tried it on rebps2pdf.r and the example found here:
http://www.fys.ku.dk/~niclasen/postscript/

Having an R2-compatible PARSE that you can run in R3 would be useful 
for large sets of parse rules that you haven't had the time to migrate 
yet.

Ah yes, good idea. Haven't thought about that yet.

did you start work on a string parser?

nope

oki.

Some day probably. Let's see, how it goes with bparse first.

It would also be useful to have an R3-compatible PARSE for R2. And 
both for Red.

bah, I'd just stick with R3 parsing for Red.  it'll be a good incentive 
for some to upgrade.

(to red or R3 parse, depending on how you see "upgrade"  ;-)

I think about downgrading. :-) You know, keep it simple. Like dropping 
SKIP as it's the same as any-type! etc. If I want SKIP, I can just 
define it then: skip: :any-type!

I'd drop any-type!  :-)

Having skip as a keyword mean, you can't use that word as a variable.

That doesn't work with string parsing.

ok

Most people tend to not use 'skip as a variable anyways, because 
of the SKIP function.

I in general very much like the idea, that many rebol functions can 
take different datatypes and work anyway. But I was thinking, if 
parsing blocks and parsing strings is so different, that it should 
be two functions?

and I always prefix my rules to have them stand out from keywords.

nah, it would just use up another word.  there is no ambiguity in 
the case of parse, as lets say ADD.  where the same datatype may 
mean two things.

For the mezzanine version, two functions might be better, though 
they can share code in the same module. Maybe just have one exported 
word for a dispatch function though.

(or the context equivalent of modules for R2)

yes

When programming it, I also wondered, why the or keyword is | and 
not OR. Do you know the reason?

Parsing tradition. And it's not really OR, it's backtracking alternation.

Right, just wondered, now rebol call e.g. floats for decimals etc. 
many attempts to make the language more humane.

Considering that the space character is the closest thing to AND 
if | is OR, we should consider ourselves to have gotten off lucky 
:)

parse [a b c] ['aAND'bAND'cEND]
hmm, yeah, you've got a point.

We used up that luck though when we called the lookahead-match operation 
AND, and the lookahead-non-match operation NOT.

& and ! maybe?

We're probably fine with the wording we got. Though strangely enough, 
| is the ELSE of the IF operation. ELSE is a more descriptive name 
for | than OR in general.

Geomol:

    [to rule skip]

does not mean the same as

    [thru rule]

, as can be demonstrated when comparing the behaviour of

   thru rule

for 

    rule = "abc"

It is quite a surprise for me, that you don't see the difference.

In R2 parsing a block:

>> parse ["abc"] [to "abc" skip]
== true
>> parse ["abc"] [thru "abc"]   
== true


I know, it's different when parsing a string instead of a block. 
My comparison of [thru rule] to the alternatives was meant as a loose 
comparison, not to be taken literally. So it's easy to think of THRU 
to work this way, because it does in many cases, therefore the confusion.

because it does in many cases

 - should rather be "because THRU is so limited, that it is unable 
 to handle many cases"

yeah :)

But, the recursive description:

    a: [b | skip a]

is quite natural.

Yes, and that should work in all cases, if the b rule is found, complex 
or not. And this will return true, if b is END, because  END is a 
repeatable rule (you can't go past it with SKIP).


NONE is also repeatable, and if you look in the code, I have to take 
care of this too separately. This mean, we can't parse none of datatype 
none! by using the NONE keyword, but we can using a datatype:

>> parse reduce [none] [none] 
== false
>> parse reduce [none] [none!]
== true


So it raises the question, if the NONE keyword should be there? What 
are the consequences, if we drop NONE as a keyword? And are there 
other repeatable rules beside END and NONE? In R2 or R3.

The "empty string rule" (represented by the NONE keyword in REBOL) 
is absolutely necessary to have. All other members of the Top Down 
Parsing Language family have it as well.

Ok, what is a good source of information to read about parsing in 
general? The Top Down Parsing Language family etc.?

You can find something in the Wikipedia:

http://en.wikipedia.org/wiki/Parsing_expression_grammar¨

http://en.wikipedia.org/wiki/Top-down_parsing_language

Is the "empty string rule" covered by butting a | without anything 
after it? Like in:

>> parse [] ['a |] 
== true
>> parse [] ['a | none]
== true

Hmm, as it looks, we could do without the empty string, we could 
use the rule like:

    empty: []

It could be interesting to creat an absolutely minimal PARSE function, 
that can handle all we expect from such a function but with as little 
code as possible (as few keywords as possible).

For strings, the

    empty: ""

should work as well, but it does not.

Another variant that comes to mind is

    empty: quote ()

From your idioms it can also be seen, that OPT can be dropped easily.

BTW (looks a unlucky to me), do you know, that in REBOL the NONE 
rule can fail?

Can't remember. Give me an example.

Nevermind, I do not remember. The NONE rule is described in the wikibook, 
so it can be found in there, I guess.