World: r3wp

I don't know

Whoops

s: 		"str"
s2:		"str 1^/ str 2 ^/ str 3"


rules:	[
		any [
			end break
			| copy value [to "^/" | to end]		(print value)
		]
		]
	

parse		s rules
print		"---"
parse		s2 rules

i run the above on core 2.6 and it loops forever . This was a bug 
fixed in 2.3 but it looks like the bug still exists

sorry, not a bug. I was inspired by the example in the changes page 
and it is missing the  thru "^/" after the to "^/"

parse item [
    any [
        "word" (print "got word")
        | copy value [to "abc" | to end]
            (print value) break
    ]
]

not a bug - you are not skipping the newline, so to "^/" will always 
match. you are not getting to the end.

>> rules: [
[    any [
[        end break
[        |
[        copy value [to newline | to end] (print value) opt skip
[        ]
[    ]
== [
    any [
        end break
        |
        copy value [to newline | to end] (print value) opt skip
    ]
]
>> parse s2 rules
str 1
str 2
str 3
== true

yes, thanks gabriele - happy holidays ! i find the opt skip not very 
intuitive !

wouldn't  to newline thru newline be easier to understand than opt 
skip

could be opt newline

joe, if you don't care about parse returning true you can just use 
skip (without opt, which is there for the end case)

also, if you don't care about your value having the newline in it, 
you can just replace to newline with thru newline.

another possibility (but gives more maineinance problems) is to split 
the copy rule into two, one for newline and one for end.

copy value to newline skip

copy value to end

Joe: another option is to use:

rules: [
    any [
        copy value [to newline | to end] (print value) skip
    ]
    to end
]

but, as Gabriele said, that is equivalent to:

rules: [
    any [
        copy value [to newline | to end] (print value) skip
    ]
]

if you ignore the parse result

to end skip will always fail. move the skip after the to newline.

Nevermind, failing isn't a problem here.

another possibility (but gives more maineinance problems) is to split 
the copy rule into two, one for newline and one for end.

 - I am curious whether this isn't actually better when the maintenance 
 is taken into account - suppose e.g. that we want to add yet another 
 alternative...

lad, maybe, but if you change the name of the variable to copy to 
you have then to change it twice in the rule.

generally, i'd prefer [copy value [rule1 | rule2]] to [copy value 
rule1 | copy value rule2], however it is not always that easy, so 
many times you have to do the latter.

I agree.

hi,  yesterday I realized I have a 1400 line single parse ruleset 
 which amounts to ~40kb of code !   :-)  I was wondering what are 
your largest Parse rulesets,  I'm just curious at how people here 
are pushing REBOL into extremes.


I might also say that parse is wildly efficient in this case, allowing 
my server to decipher 600 bytes of binary data through all of this 
huge parse rule within 0.01 - 0.02 seconds (spitting out a nested 
rebol block tree of  rebxml2xml ready data).

to anyone not yet accustomed to 'PARSE, really do take the time to 
look it through and use it.

when working so extensively with Parse, you migt try to write down 
your enhancement/fixes proposal and submit it to R3 team :-)

The one real limitation I always saw which makes some rules harder 
to write for nothing  is the first-of-any  search (to and through)

and THE MOST PROFOUND limitiation... why the hell is 'NOT within 
the dialect?

50% of the time its easier to match something which is not and then 
within that choice select something which is.

like bounds checking, making sure some items are not within a specific 
area, etc.

My largest Parse rulesets are in NicomDoc. The scripts nicomdoc.r 
and ndmath.r parse from text to rebxml format. They are 20k and 24k. 
ndrebxml2html.r parse from NicomDoc rebxml format til html, and that 
is a 28k script mostly parse rules. I once build a html dialect, 
and that was 24k.

And yes, parse is a great tool!

The html dialect can be found on the View desktop under REBOL/Public/Sites/Nicom/

Max complement charset  ...  can often be used as a sort of NOT

true, but that does not match many cases. obviously one can built 
NOT-A NOT-B and so one.. but man.. that gets tedious, which is not 
what parse should be.

I'm pretty sure my biggest parser so far is the one for Qtask's iCal 
importer: ~75K, ~2,900 lines. It's growing right now, to support 
recurrence rules and timezones.

I didn't write the whole thing manually though. I bootstrapped it 
by writing an ABNF parser, marking up the RFC spec, and generating 
as much as I could from that.

And don't forget to take a look at Gab's compile-rule function.

what does Gabriele's compile-rule function do ?

It's an extension to PARSE so you can use things like IF etc. in 
parse rules.

Sounds useful.

VERY useful... several times I've wanted something like that, but 
wasn't experienced enough in parse to figure something easy out...

why default parse is not extended in native level to support such 
constructs as IF, to-first, thru first, etc., if many ppl find them 
usefull?

lad, maybe, but if you change the name of the variable to copy to 
you have then to change it twice in the rule.

 - right. That is a general problem of procedural programming style. 
 OTOH, the "opt skip" variant has got another problem - the "opt skip" 
 code is related only to the first alternative, which seems to me 
 like the reason why Joe doesn't like it

and where is the compile-rule func?  on rebol.org?

have a look at: http://www.compkarori.com/vanilla/display/compile-rules.r

my contribution is at: http://www.compkarori.com/vanilla/display/TO%2C+THRU+And+NOT+PARSE+Rules

oh dear .. vanilla has died on me.  I get server error ...

strange, it works for me

still?