World: r3wp

Yes, John, handling of such values has been discussed a while ago. 
That is why in R3 the QUOTE directive has been defined.

Nice!

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

The idiom
Description: "Range of times operator"
Operation: 	a: [m n b]
Idiom:	a: [m b (k: n - m) [k [b | c: fail] | :c]]


only seem to be true, when n >= m. When n < m, parse works as if 
the rule was
a: [n b]

That is somewhat surprising, do you see any difference?

(I don't)

aha, sorry, you are right

Corrected, should be better now.

Can an R2 parse expert help me with an efficient parse, please?

I've got a set of bbcode-type tags, eg:
    tags: [ "[a]" "[b]" "[cc]" ] 
    

And I've got a data string that includes those (and other) tags, 
eg:

    data: "xxxx[a]aa aa[b]xxxx[a] yyyy[d]yyy[cc]dd[e]ddd[b][A]zz[zz"


What I'd like is the data string split at the designated tags, eg:

    [ "[a]" "aa aa" "[b]" "xxxx" "[a]" " yyyy[d]yyy" "[cc]" "dd[e]ddd" 
    "[b]" "" "[A]" "zz[zz" ]
    
Thanks!

rebol []

=tags=: [ "[a]" | "[b]" | "[cc]" ] 
    
data: "xxxx[a]aa aa[b]xxxx[a] yyyy[d]yyy[cc]dd[e]ddd[b][A]zz[zz"


blk: []
parse/all data [
	start:
	any [
		here: copy tag =tags= there: (
			append blk copy/part start here
			append blk tag
		) start:

		| skip
	]
	(append blk start)
]

?? blk

ask ""

should be better including [ to "[" ] at the right place

no since notice that he's not loading all [tags]  just those he really 
wants.

(maybe I misunderstood why you'd want a [ to "[" ] :-)

even if, just replace 
>skip
by 
> skip opt to "["
(not tested)

better in the sense: faster

Steeve, that looks good, thanks!


Only difference from my "expected results" is that you've also returned 
the "pre-tag" "xxxx" .... that's okay -- incidental issues like that 
are completely negotiable in the search for a solution.

>[skip to "[" | to end]
should be even better

> [skip to "[" | end skip]
skip an extra loop by exiting with a fail

sunanda, wrt first elemetn, I thought it was a typo on your part 
 ;-)

:) --- in the real-life app, I'd insert a dummy tag at the start 
to hoover up any pre-tag data.

Maxim can alter its parser to avoid such ack, easly task :-)

In R2:

>> parse [a b c [d e f] g h i] [to [d e f] mark: (probe mark) to 
end]
[[d e f] g h i]
== true


Here the block after TO isn't a sub-rule, but a value to search for 
(a block of words). Doing the same in R3:

>> parse [a b c [d e f] g h i] [to [d e f] mark: (probe mark) to 
end]    
** Script error: PARSE - invalid rule or usage of rule: e


Is the block a sub-rule here? I've tried to search the docs, but 
haven't found an explanation.

TO and THRU were changed to support multi-rules, so they aren't really 
comparable to their R2 versions. And there are some bugs in the implementation 
where some rules that don't match the acceptable syntax are just 
treated as not matching instead of triggering an error the way they 
should. This has made it difficult to properly document their current 
behavior.

PARSE is definitely something I wish was more open, because there 
are bugs I would like to fix.

I think that there is no direct equivalent in R3 to R2's TO/THRU 
inline block. R3's TO/THRU inline block treats the block as its sub-dialect 
for TO/THRU multi, and that doesn't allow complex values or more 
than one value in a single alternate. The direct R3 equivalent of 
what you are requesting would be this, but it doesn't work:

>> parse [a b c [d e f] g h i] [to [[d e f]] mark: (probe mark) to 
end]
** Script error: PARSE - invalid rule or usage of rule: [d e f]

Instead you have to do a trick with to block! in a loop and then 
match the block to quote [d e f] explicitly, keeping looking if it 
doesn't match. It's annoying.

PARSE is definitely something I wish was more open

I have done a bit of work on a function version of PARSE. Maybe having 
PARSE as a normal REBOL function could help in fixing bugs? My version 
is not quite ready to publish. Are there a set of PARSE tests somewhere, 
that I could test my version against? I would prefer R2 tests to 
start with. I'm doing my own tests, but maybe we have a more complete 
set of tests somewhere, like in the R3-alpha world (I think, was 
the name), where we did a lot of tests on different things.

I would be happy to use a function! version of PARSE since i never 
had to do time critical parsing.

did you do any kind of speed differences?

(tests)

not yet, I maybe could do a quick test...

>> dt [loop 100000 [bparse [a b c] ['a 'b 'c]]]
== 0:00:00.965689
>> dt [loop 100000 [parse [a b c] ['a 'b 'c]]] 
== 0:00:00.235949

bparse is my block parse function.

>> dt [loop 10000 [bparse [a b c a b c] [2 thru 'b 'c]]]
== 0:00:00.133237
>> dt [loop 10000 [parse [a b c a b c] [2 thru 'b 'c]]] 
== 0:00:00.029891

So a factor 4 or so.

not bad actually.

Geomol: "Are there a set of PARSE tests somewhere, that I could test 
my version against?" - there are the core tests at

https://github.com/rebolsource/rebol-test


, that contain a couple of PARSE tests in the functions/series/parse.r 
section. It would be nice if you added some tests.

Thanks, I'll look into it.

What's the opinion on this?

>> parse [a b] [set w ['a 'b]]
== true
>> ? w                      
W is a word of value: a

It seems to work the same as: parse [a b] [set w 'a 'b]
Same in R2 and R3.

It seems like an error that is improperly not triggered. SET is supposed 
to set to a single value, not a series of values - an embedded block 
is a single value.

I think it is OK. Set just sets the word to the first value matched.

I do not think it makes any sense to trigger an error.

It doesn't make sense to trigger an error if the data is weird, but 
triggering errors if the rules are weird is critical for debugging, 
especially for generated rules. Triggered errors are the programmer's 
best friend - that's the R3 policy.

For instance, R3's TO and THRU are extremely difficult to debug right 
now because they don't trigger most of the errors they should trigger.

This is a simple rule:

set w rule

sets the word 'w to the first value matched. No error.

It is quite obvious what the first value matched is.

so, no way to match a complex rule?

s/match/set

RULE might be complex, but what is so strange about setting 'w to 
the first value matched?

it's not transparent what is the 1st value if 'rule is defined somewhere 
else and not inlined

imagine, i define "my own type", like address!

That is not the error I was talking about. This is the error:
>> parse [a b] [set w ['a 'b]]
== true
>> ? w                      
W is a word of value: a


It is the attempt to set the value to a complex rule that is the 
error. It wouldn't be an error to do this: parse [a b] [set w 'a 
'b]

If we keep the current behavior, there needs to be a lot of strongly 
worded warnings about the potential gotcha in the PARSE SET docs.

It does not matter where the RULE is defined. The first value matched 
is the value at the current position of the cursor, if the match 
occurs, that is.

As said, it does not matter what the RULE is. The first value is 
the first value.