World: r3wp

>> 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.

You cannot find anywhere a formulation like "set the value to a rule". 
That is not what can happen.

address! [string! tuple! hash!]
parse ["cat" 1.2.3 #4] [set addr1 address!]

if im reading this address! looks just like a value reference...

It could be considered a useful feature, since the whole match needs 
to match before the SET is performed. However, the docs need to be 
*extremely* precise about this because the "set the value to a rule" 
interpretation is a common misconception among newbie PARSE writers. 
It would be good for the docs to give an example of the type of code 
this allows you to do, explaining the difference.

>> parse [1 2] [set x [integer! issue!]] 
== false
>> x                                    
== 1


this is not i would expect for sure... what are the brackets for 
if they don't have any effect?...

it gives
** Script error: x has no value
in r3 though

But we have COPY to do, what you want, if I understand:

>> address!: [string! tuple! issue!]           
== [string! tuple! issue!]
>> parse ["cat" 1.2.3 #4] [copy addr1 address!]
== true
>> addr1
== ["cat" 1.2.3 #4]

onetom, It's not "set the variable to a rule", it is instead "match 
a rule then set the variable to the value at the current position 
in the data".

as stated in the "Idioms" section, I think, that

    a: [set b c]

shall be equivalent to:

    f: [(set/any [b] if lesser? index? e index? d [e])]
    a: [and [c d:] e: f :d]

By "It could be considered a useful feature" I mean that if this 
were not allowed, you would have to write this:
    parse data [set x ['a 'b]]
like this instead:
    parse data [and ['a 'b] set x skip skip]

Sorry, that's what Ladislav said, with different phrasing.

Yes, Brian, you just wrote it in a simpler way

I was thinking of phrasing for the examples in the docs to explain 
the SET feature.

Those full equivalences are great for someone who really needs to 
know how things work internally (such as when they need to clone 
PARSE), but you need simple examples first in docs for people who 
just want to use PARSE properly. Btw, has anyone started a set of 
full PARSE docs in DocBase? The parse project page could be raided 
for information, but it really doesn't serve as a full parse manual.

Do I understand correctly, that you did not read the


http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse

article yet?

I haven't read the REBOL wikibook yet.

This is the formulation used to document the SET directive:


If the subexpression match succeeds, the set operation sets the given 
variable to the first matched value, while the copy operation copies 
the whole part of the input matched by the given subexpression. For 
a more detailed description see the Parse idioms section.

Sounds accurate, if a little intimidating to newbies. I wish we had 
a really good PARSE manual that could turn newbies into experts.

Any newbies feeling intimidated by the formulation?

It could be fine, depending on where you put it in the manual. The 
early parts would need to explain the terminology so the latter parts 
can use it.

Well, certainly it should be read, otherwise it is useless.

PARSE in R2 seems to have less support for combined keywords than 
R3, as can be seen in this example:

>> parse [] [opt some 'a]
** Script Error: Invalid argument: some

But there is no error, when combining OPT and THRU:

>> parse [] [opt thru 'a]
== false


Should that trigger an error? If no error, it should return true, 
right?

No and no.

opt thru 'a

means the same as

[opt thru] 'a

When R3's TO and THRU should trigger an error, most of the time they 
just don't match instead, for no apparent reason. There's at least 
one ticket for that.

Ladislav, why would [opt thru 'a] not mean [opt [thru 'a]]? Isn't 
that the definition of opt?

Ladislav, but shouldn't then [opt some 'a] mean [[opt some] 'a] ? 
It gives an error in R2.

And by that I mean [opt some] might mean [opt [some none]]. :-) It's 
hard, this!

aha, sorry, the combinations of keywords like opt thru are undocumented, 
and the behaviour really is unexpected

Ok, makes sense. Problem is probably too little documentation (design) 
in the details in the first place.