World: r3wp

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.

[set var end] sets the var to none; [copy var end] sets to none in 
R2, the empty string/block in R3; [thru end] doesn't match, so it 
should just get a warning in case the rules were written to expect 
that; [opt end] is definitely legit; perhaps [any end] and [some 
end] should get warnings for R2, but keep in mind that rules like 
[any [end]] and [some [end]] are much more common, have the same 
effect, and are more difficult to detect; [into end] properly trigers 
an error in R2 and R3 because the end is not in a block, while [into 
[end]] is legit and safe.

So you want to allow COPY, SET and OPT. Warn about THRU (because 
of the bug), ANY and SOME, because of R3 compatibility. Trigger an 
error for INTO if its argument rule isn't a block or a word referring 
to a block, but nothing special if that rule is END.

[any end]Êand [some end]

As we don't have warnings, I suggest these to produce errors. They 
can produce endless loops, and that should be pointed out in the 
docs, if they don't produce errors.
[opt end]

Yes, it's legit, but what's the point of this combination? At best, 
the programmer knows, what she does, and the combination will do 
nothing else than slowing the program down. At worst, the programmer 
misinterpret this combination, and since it doesn't produce an error 
or anything, it's a source of confusion. I suggest to make it produce 
an error.
[into end]
Produces an error today, so fine.
[set end ...] and [copy end ...]

I wasn't thinking of [set var end], but about setting a var named 
end to something, like [set end integer!]. Problem with this is, 
that now the var, end, can be used and looks exactly like the keyword, 
end, maybe leading to confusion. But after a second thought, maybe 
this being allowed is ok.
[thru end]

Making this produce an error will solve the problem with the confusion 
around, what this combination mean. And in the first place, it's 
a bad way to produce a 'fail' rule (in R2, in R3 it has the value 
true, and parsing continues). It's slow compared to e.g. [end skip].

These are just suggestions to make a better PARSE. I've learnt, it's 
a good idea to not allow most combinations of keywords in R2 parse. 
Another example:

>> parse [] [opt into ['a]]      
== false
>> bparse [] [opt into ['a]]
** User Error: Invalid argument: into


The PARSE result is wrong, as I see it. My BPARSE produce an error. 
Better?

[any end]and [some end]As we don't have warnings, I suggest these 
to produce errors.


- it is impossible to trigger errors every time an infinite loop 
is encountered
- this case has been discussed and the solution was found already

[opt end] ...I suggest to make it produce an error.

- not reasonable, the rule *is* legitimate, as you noted

What you suggest is just a bunch of exceptions in the behaviour, 
which is always bad

You should rather look up how the "infinite loop problem" when using 
ANY and SOME was solved

Here: http://www.rebol.com/r3/docs/concepts/parsing-summary.html#section-11

Input position must change
. And the solution was to invent a new keyword, WHILE. Hm...

I try to keep it simple.

This is much simpler than your exception:

- actually working, your exception does not
- not slowing down parsing

ok :)

As to the WHILE keyword: some people may never use it, being content 
with SOME and AND as they work in R3

I mean SOME and ANY

If you're going to make a better parse, it might be good to take 
into account the efforts that have already started to improve it 
in R3. The R3 improvements need a little work in some cases, but 
the thought that went into the process is quite valuable.


[set end ...] or [copy end ...]: In R3, using any PARSE keyword (not 
just 'end) in a rule for other reasons triggers an error.
>> parse [a] [set end skip]
** Script error: PARSE - command cannot be used as variable: end

[any end] or [some end]: What Ladislav said.


[opt end]: The point of the combination is [opt [end (do something)]]. 
[opt anything] is no more useless than [opt end]. Don't exclude something 
that has no effect just for that reason. Remember, [none] has no 
effect as well, but it's still valuable for making rules more readable.

>> parse/all "/docs/rfq/" "/"
== ["" "docs" "rfq"]

shouldn't this be either
["docs" "rfq"]
or
["" "docs" "rfq" ""]
for the sake of consistency?

yes it should.  :-(

Maxim, you asked for a function version of string parse. Was that 
because of situations like this?

its because I do  A LOT more parsing on strings than on blocks.... 
one of the reasons is that Carl won't allow us to ignore commas in 
string data.  so the vast majority of data which could be read directly 
by rebol is incompatible.   


this is still one of my pet peeves in rebol.  trying to be pure, 
sometimes, just isn't usefull in real life.   PARSE is about managing 
external data, I hate the fact that PARSE isn't trying to be friendly 
with the vast majority of data out there.

Do you mean, you want to be able to parse like this?

>> parse [hello, world!] [2 word!]

its happened often yes.  less lately, since I'm dealing more with 
XML and less with raw data.

more like:

parse load/all "hello, world!" [2 word!]

I have wondered sometimes, what effects it would have, if such commas 
was just ignored. We need commas in numbers, but maybe commas could 
just be ignored beside that.

So do you suggest, load/all "hello, world!" should return [hello 
world!] ? (Notice no comma.)

And without space, comma should maybe split the text? Like:
>> load/all "hello,world!"
== [hello world!]

yes, I always thought that commas should be removed of decimals, 
and simply ignored when loaded.


in mechanical data, commas are never used for decimals.  because 
apps need to load it back and all software accept that dots are for 
decimals and commas for separating lists.   why should REBOL try 
to be different, its just alienating itself from all the data it 
could gobble up effortlessly.

so a comma would be an exact alias for a space, when its not within 
a string.

I almost agree. Here we use comma as decimal point. A few countries 
does that. So all data with money amounts have numbers with comma 
as decimal point here.

But it should be possible to take care of those numbers with commas, 
and ignore all other commas, I think. As we don't ever write
42,
but always something like
42,00

if it's a decimal. So if 42, is seen, it can just be read as integer 
42 and ignore the comma (if using load/all for example).