World: r3wp

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.

Maybe the last section here:

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse/Parse_expressions#Troubleshooting

That is not related

Nevertheless, I messed it up. The NONE rule probably cannot fail, 
but it can consume some input.

(which does not look good as well)

With bparse, this hangs:

bparse [a b c] [some [none]]

but it can be stopped by hitting <Esc>.

Yes, but that is OK, it is just an infinite cycle

Nobody should expect an infinite cycle to stop.

It can't be stopped using PARSE, it seems.

In parse, NONE is a keyword unless it comes after TO or THRU, then 
it's looked up.

>> parse [#[none!]] [none]     	; as a keyword
== false
>> parse [#[none!]] [thru none]	; looked up
== true

Same behaviour in R2 and R3.

Maybe it would be a good idea to make all these combination trigger 
an invalid argument error?

any end
some end
opt end
into end
set end ...
copy end ...
thru end

and then only let
to end
be valid.