World: r3wp

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.

Good, that will be very welcome.

yep :-)

the problem is that the above can be extremely slow... just like 
regexp   :-)

be back later ... dont forget the assignment  ;-)

Thanks again Maxim

Sunanda, I had a look at the parse visualiser yesterday, it looks 
a bit advanced for me yet. A simple version would be good for newbies. 
 I got it to work on his examples, but my examples produced no output. 
 I expect I was doing something foolish.  I will return to it when 
my basic skills are a bit better.

Maxim.  Here is my first attempt at the homework you set me. This 
builds on what you showed me & also relates to the example given 
to me by Pekr.


data: "before first tag <TAG> after 1st pointy tag [TAG] after square 
tag <TAG> after pointy tag 2"

tag-square: "[TAG]"
tag-pointy: "<TAG>"

output: func [tag here] [
	print rejoin ["we are passed the " tag " : '" here "'"]
]

parse/all data [
	some [ 
		[tag-pointy here: (output tag-pointy here) ] 
		| [tag-square here: (output tag-square here) ] 
		| skip
	]
]


I thought it would make the action clearer if the output was in a 
function & the keys used variables.

mhinson: your rule:

b: [to "bb" break]


looks quite dangerous. TO means a lot of input may be skipped, which 
is usually not what you want. Moreover, BREAK in that rule is not 
the right place. (it just breaks the rule, but that is totally unnecessary.

(I am not a big fan of BREAK myself, every rule can be written without 
BREAK)

Ladislav, thanks for your comments.   It has been suggested that 
I should avoid TO in any backtracking parse until I know much more 
about what I am doing.

yes, in your rules you certainly wanted to look for more alternatives, 
than just for "bb". In that case the usage of To is not advisable.

(you have to tell Parse what the alternatives are *before* using 
any cycle construct like TO, SOME, etc.)

so, my guess is, that you wanted something like
b: "bb"
y: "yy"
parse input [any [b | y |  skip]]

or some such, the above would find all occurrences of the parts you 
specified

if you want to find just the first occurrence, then you may use e.g.:

occurrence: [b | y]
parse input [any [occurrence break | skip]...]

mhinson: there is simple rule to how to read TO: skip everything, 
unless you find the target. This is not what you wanted in your original 
example, because e.g. TO "b" might also mean, that "b" might be the 
last char of your string. So if you are looking for FIRST occurance 
of [a | b | c], you really have to forget TO and use skip based parsing 
by one char. Hence some [a break | b break | c break | skip] is your 
friend ...

To [a | b | c] may work in the future, but it certainly does not 
work now (although it is not hard to replace using ANY or SOME)

I am trying to formulate an example that shows why I thought TO was 
useful.  It mostly has to do with where I want to extract the data 
complete with the key I used to find it.  Without using TO it seems 
that I need to add the string I was looking for back onto the data 
I have extracted.

did you have a look at the link Sunanda mentioned? http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse?

aha, you want something like the AT command. That is easy.
[here: "string" :here]

Yes, that was the firt time I found that as I had not realised the 
Wiki was so extensive. It is a good source.

for this example, what would be the most simple version that returns 
exactly "B2." without using TO?
parse "A1.B2.C3." [to "B" copy result thru "."] print result

assuming the only reference points are "B" and "."

b: [here: "B" :here copy result thru "."]
parse input [any [b break | skip]]

you may need some other tricks, like how to make the rule fail, if 
no occurrence was found

I could not reply. AltME was broken. I dont understand the syntax 
of the :here statement.

it's easy - there are so called parse markers. Imagine parse working 
on strings (blocks) at parse level. But then there is underlying 
level, the string (block) itself. You can access the string from 
the parse level either from parens, or by setting markers.

so what code from Ladislav does is:


here:  ; mark the position in the input string. Something like AT. 
Then you can use it in your parens
B
      ; it matches "B". 

:here  ; return back to saved position. So parse input string AT 
position moves back behind the "B"

You can also think about it like:

start: some-matching rules end:  (copy/part start end)

So is :here part of the parse dialect? I undedrstand here: but not 
:here