World: r3wp

well... to/thru are listed alongside  skip under "skipping input" 
in both r2 and r3 docs...  they cannot use sub rules, since they 
only do a find on the input.

Did you really read the documentation?

You could notice: "thru rule" "scan forward in input for matching 
rules, advance input to tail of the match "

(no purported "one character")

And, the fact, that the rules are listed under "skipping input" does 
not support your incorrect "are not matching rules".

yes, the new docs reflect what now happens in R3.

to/thru do not match subrules... they only do a find.

Which is the same which happens in R2, in fact, except for the bugs

to/thru do not match subrules

 - yes, that is a correct observation, although unrelated to the subject 
 of the discussion, and, actually, just a detail of the implementation, 
 that can easily change at any time, especially taking into account 
 the user preferences

Although, TO/THRU actually match subrules, when I think about it, 
just a limited set of them.

In string parsing, we can use either character subrules, or string 
subrules, in block parsing we can use value subrules, datatype subrules, 
and some other special subrules

it really just does a find (even the docs use the term scan).  the 
actual things we can to/thru are exactly the same as what can be 
used in find.

the only little shortcut, is that it can be used to search multiple 
things at once.

but its flawed, you know how.

so its not as usefull as it could be .

Wow! And I thought, I knew about parse. :-)

A)

As I understand it, matching a rule like [end] is valid and parse 
will return true, if you're at the end, and in this special case, 
the curser isn't advanced further (becuase it's the end). And I understand 
the rule [thru end] as trying to advance the curser past the end, 
which isn't possible, so it fails.

B)

If the rule [end] advance the curser past the end, and this is valid, 
so parse returns true, then the rule [thru end] also should return 
true. But but but this can't be the case, as then this would not 
return true:
parse [a] [word!]

which it does. The reason, it shouldn't return true, is because we're 
at the end, not past the end. Unless both being at the end and past 
the end should return true.


I guess, it's a matter of implementation (as this isn't well documented 
afaik). I prefer the A) situation, as the B) situation is more confusing. 
Don't you agree?

Think of the end of a series as an internal marker, which the user 
shouldn't see as an element in the series, if you ask me.

You are missing the point, why don't you read the THRU documentation 
instead of speculations?

Ok, I will. I did long time ago, but maybe it changed, or I missed 
something the first time, or I forgot, how it works!? :-)

See the above reference to the doc article

Oh, I got my understanding from http://www.rebol.com/docs/core23/rebolcore-15.html#section-4
The little example there is a good way to understand it:

page: read http://www.rebol.com/
parse page [thru <title> copy text to </title>]
print text
REBOL Technologies


I was thinking R2, maybe you guys talked about R3 only? Has this 
changed?

I think, the docs match pretty well.
thru	advance input thru a value or datatype


You're right, taking this strictly, we should be able to advance 
thru the end. But this doesn't make much sense, so my guess is, most 
people wouldn't take this strictly, when talking the end of a series.

The end specifies that nothing follows in the input stream. The entire 
input has been parsed.


I read it, as there isn't anymore to parse. So is it possible to 
parse past the end? I would say no.

This is just a speculative interpretation of a text of one example. 
See the documentation.

http://www.rebol.com/r3/docs/concepts/parsing-summary.html

Keywords that accept a repeat count are:
...
end


So the advancing must stop somehow, as we can parse end multiple 
times.

>> parse [a b c] [to end]      
== true
>> parse [a b c] [to end 5 end]
== true


Anyway, this may be a pointless discussion, if the language isn't 
clearly defined in such detail.

Why don't you read the documentation?

It is explained in there, and it is the *only* place where it is 
explained in general, not just using one example.

The fact is, that when a rule matches, the cursor may (optionally) 
advance, but it does not need to.

In case the cursor advances, the head of the rule match is distinct 
from the tail of the rule match. As opposed to that, when the cursor 
does not advance, the head of the match is identical with the tail 
of the match.

Which is the case of e.g. the above NONE rule.

But, many rules can have this property, even in R2

And, surely, one of the rules having this property is the END rule.

So, while the TO rule advances to the head of the subrule match, 
the THRU rule advances to the tail of the subrule match, which happen 
to be identical in case the subrule match does not advance the cursor.

Argh, I was confused by sentences like
Where do you think the cursor is after matching the [end] rule?
:-)
Old def. of thru: advance input thru a value or datatype

New def. of thru: scan forward in input for matching rules, advance 
input to tail of the match


Then it can be argued, the tail of end (of a series) is still the 
end. Or it can be argued, that thru always advance some way further 
(as in all cases except at end). I understand, why [thru end] not 
failing is confusing.

(And stop saying, I should read the doc. I have read it ... in full 
this time.) ;-)

it can be argued, that thru always advance some way further

 - actually it cannot be argued, taking into account, that it has 
 been documented

I was confused by sentences like
Where do you think the cursor is after matching the [end] rule?


Interesting, so, you do not know where the cursor is after matching 
the [end] rule? Otherwise, such a question cannot confuse anybody 
knowing where the cursor is.

That I don't agree with. I don't see, it say anywhere in the doc, 
that thru does not advance the input.

That is not what I said

I said, that, in general, PARSE may, or may not advance the input 
after successfully matching a rule. Which is true.

Interesting, so, you do not know where the cursor is after matching 
the [end] rule?

I assume, I know it, when it comes to parse in R2. I'm not sure with 
R3, as I don't have much experience with that.

Yes, true about parse may or may not.

I'm quite impressed (or surprised at least), how much parse has grown 
from R2 to R3. I haven't studied it close, but what's your opinion? 
Is all those rules necessary. I feel, it might be too complex to 
use?

And, I guess, that the "past" word does not express as clearly what 
Carl had in mind, and that he wanted to explain the general case, 
explaining all possible outcomes of subrule matching.

(in one sentence)

...how PARSE has grown from R2 to R3

 - actually, not at all. That is only a superficial difference. As 
 can be seen in the


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


article, (especially it is obvious when the "Idioms" section is examined), 
all the constructs from R3 are possible in R2 as well.

See also

http://www.rebol.org/view-script.r?script=parseen.r

Oh, ok.

The "Idioms" section actually suggests, that even some R2 constructs 
are "superfluous" in the sense, that they can be derived from more 
elementary constructs like sequence and choice.

For example,

    a: [opt b]

is actually the same as

    a: [b |]