World: r3wp

does the above make sense to you?

does "some" make it repeat?

yes, and at least one rule must match or else it fails and rolls 
back to parent. rule

but skip will always succeed?

so can you explain to me why the ["<TAG" ... ] rule is BEFORE the 
skip rule?

is it because thay are itterated in order?

that is the reason for the lesson... once you grasp that you are 
about 50% there already  :-)

some will loop over and over until ALL rules fail. if that happens 
then IT fails too.

'SOME  will loop ....

so why did it only print the string once?  simple question... but 
not so obvious to answer for a newbie  :-)

Here is a crude way to do what we did earlier that doesn't use parse 
but matches any part to any first occurence of the letter

>> chars: charset "by"
== make bitset! #{
0000000000000000000000000400000200000000000000000000000000000000
}
>> copy/part z: find {aabbyyc} chars next find z "c"
== "bbyyc"

because the match only occured once?

yep... it only was able to match the first rule when got AT that 
point in the data

every other time (including after it matched the tag) the second, 
alternative, rule matched, and we where able to hit the end of the 
string.

<TAG>
 here:

here only gets the remaining part of the string assigned to it if 
the previous key parse returns true

set words within parse rules are set to the point in the series that 
the parser IS , AT that exact moment.

I read about that & how [index? here] will return that position

so if you had put the HERE: like so:
[here: "<TAG>" ...  

then the tag itself would be part of the printed string.

but note that at that point, it has not matched the "<TAG>"  yet 
 !

so is the first position in the parse expression special in that 
it is always evaluated?

I see it is     
parse {123} [(print "hello")]

it evaluates until it finds a given character that it cannot match

Maxim, I fear my 10 mins are more than up, please dont let me keep 
you from your tasks. You have been more than kind.

the thing to know about parse mhinson is that you want to set forth 
the righ  matching conditions to get to the end of the string that 
your parsing because if something doesn't match it will abort at 
that point and return false.

ok, I'll be back later for lesson two  :-)  but I'll give you a simple 
lesson 1.5 assignment  ;-)

edit the above so it matches either "<TAG>"  OR  "[TAG]"   :-)

ok thanks Maxim.

I'm keeping it baby steps, but these are the simple building block 
which really build up about 90% of all real dialects.

Thanks Paul, I fear I have been ignoring the use of other things 
like find. I guess with more complex parse expressions find may be 
a shortcut to extract a substring from a predictable block of text..

Yeah, I often resort to find over parse because it makes more mental 
sense to me.

the "comprehension" of those simple things is essential, simply knowing 
about them is useless... cause in real life, you will have to "SEE" 
the whole recursive structure of the parse rules played in your head. 
 


if you don't fully grasp what is going on, you can't really create 
that essential mental map.   that is what kept me from understanding 
parse for 6 yess... SIX years :-(   and suddenly over the course 
of 2 days, I finally "GOT" it and a week later I was building a 700 
line parse rule for a real-time server doing signal convertion from 
one data format to another through two network ports.

I think I partly got the feeling that anything other than parse was 
non-purist.

You might find Brett's parse visualiser useful:
http://www.rebol.org/documentation.r?script=parse-analysis-view.r

Sounds like a chalange.   I have wrote quite extensive data conversion 
routines in Pascal, but that was in the 80s.

Well problem is that parse is not always most convient.

its funny cause once you "get" parse... just about every data manipulation 
is really easy using it.  remark, used find and copy and shit like 
that before... it was a horrendous 100 lines of code.


it was replaced by 10 lines of parse code and now runs 20-50 times 
faster and can do much more funky stuff on top of it.  :-)

paul... that's cause you probably don't get it as much as you could 
 :-)

For example, I rather do this:

parse/all {zzabyybc} [to charset copy result thru "c"]

Yeah Maxim, my mind trys to believe something should be possible 
with parse and I always hit that roadblock when it isn't.

isnt Paul's example a "propper" parse?

Hehe - that is my point.

that was my situation before too... hell I had trouble doing just 
about anything in parse... for sooo long... now I can argue with 
the parse gurus... hehe I admit I'm a wee bit proud of that  ;-)

hehe

so how could the data extracted be used without the "copy"?

mhison its a valid, but not really appropriate use of parse

my example doesn't work mhinson.

its not the copy aspect of it, its how he traverses the data.

In my mind it should but that functionality doesn't exist as far 
as I know.

when you start to add a single other rule, that will start to fall 
appart.

paul, it is part of possible R3 improvements

Ah, so Paul wants to create in effect a "regular expression" and 
use it in the parse.