World: r3wp

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

yes

Should I understand it to move the parser "cursor" back to the position 
of 
index? here
?

Look at my explanation above, and try to understand it. After here:, 
there is going to be "B" matched. So it means, that index is moved 
past "B". But you want to have your string copied including "B". 
So by issuing :here, you put parser to the saved position.

exactly ...

... you can have many such named markers ...

I can apreciate the usefullness of that.

I am not sure why the BREAK is needed in the example from Ladislav 
above. Is it to force the rule to return true when the "B" and "." 
matches are found to prevent it carrying on looking for a second 
match further down the string?

Testing that idea out looks as if I have stumbled on the right answer. 
 Maybe there is hope for me yet.