World: r3wp

Yes, it takes a little while to become familiar with parse.

this does surprise me a little , but I am not sure if this was the 
problem or something else, because I hrought I tried with some and 
all things

It means, basically:
	SOME: Do this 1 or more times, until fail or end is reached:

  [Try "b", if that fails, try "c". If that fails, try "a"]     <--- 
  Given "a" "b" "c", this rule always succeeds.

aha.. I think / hope I found an example of my problem ( I already 
settled that I have to do thins like this in multiple passes )

( the problem is at things where things repeat adn I don't know in 
which order they will appear .. I had this problem with parsing something 
like simplified wiki text )
>> a: "start1 1 end start2 2 end start1 3 end"
== "start1 1 end start2 2 end start1 3 end"

>> parse a [ SOME [ [ thru "start2" | thru "start1" ] copy T to "end" 
(print T) ] to end ]
 2
 3
== true

>> parse a [ SOME [ [ thru "start1" | thru "start2" ] copy T to "end" 
(print T) ] to end ]
 1
 3
== true

( to not give impression I have only problems with parse, I used 
parse to solve many things that would be headhurting any other way... 
these and problem upthere are just cases where I got into trouble)

Yes, multiple passes can make the code simpler.

Ah, here it's good to use nested rules to cut down the code.

apiece: [copy T to "end" (?? T)]

parse a [some [thru "start2" apiece | thru "start1" apiece]  to end]

This is basically not a problem , as I solve these things wiht multiple 
passes and it works more than fast enought for me that way also ... 
I think this problem would not exist if in case of [ .. | .. | .. 
] parse would check all options and take the one stat is least characters 
away from current position (that comes true the first) .. but this 
would most probably slow down the parse and you would loose the feature 
that you define "priority" with [ .. | ..  | .. ] now .. so maybe 
if there would be a different | for this

( I have to go to eat... will be back .. thanks a lot for before)

no worries - I must sleep. :)

hm.. interesting solution .. never thought of doing it this way!! 
this would maybe solve these problems I had

hm.. really thanks for this example.. I took it as unsolvable, but 
this is totaly elegant way to solve it .. I will need to think on 
this a little and do some more examples to difest it :) thanks

Not 100% elegant yet !  But glad to help, anyway.

If you need to parse complex structures, like the marup language, 
you should use charsets and not 'to or 'thru commands... for example 
you cannot say that tag starts with < and ends with > because such 
a tag is valid as well:
<input value="<>">

The 'to and 'thru commands are useful, if you, for example, do datamining 
and don't care to parse all page structure to get just a bit of information 
from it.

Oldes, your examples were so far too hard for me to grasp (but I 
am getting there :) ) ... I imagine they are more like what I described 
above as state machines with which you can parse everything even 
structured/nested data. I will need to study charset parsing at some 
point. I agree with your point otherwise but just in this case <> 
& " ' are not alowed in HTML (or at least XHTML) and should always 
be encoded ( but are not always) I think

You are right.. but if you use it with browser, it works.. web is 
full of not validate pages:).. But I agree, that it was not good 
example.

Is there a way to force parse to inclose results in {} instead of 
double quotes "" regardless of length?

never mind I see my prob...

Hello everybody!

I have a problem. I need to extract email addresses from a big text 
like

bla bla [me-:-demo-:-com] bla bla ...  <[you-:-example-:-org]>  etc. [he-:-italy-:-it]

There is possible to obtain a text with all the addresses withou 
the "<" and ">"?

I am not sure I understand what you are upto ....

do you want both emails within the <> and those without?

>> str: "bla bla [me-:-demo-:-com] bla bla ...  <[you-:-example-:-org]>  etc. 
[he-:-italy-:-it]"

>> foreach w parse str none [if find e: to-email load w "@" [print 
e]]
[me-:-demo-:-com]
[you-:-example-:-org]
[he-:-italy-:-it]

or something.

eh, nice :-)

Here's absolutly terrible parser - it does NOT follow RFC, allow 
any combination of alpha chars, dots, one @ char, and the same, once 
again to the next space char ...

space: #" "
mailchar: charset [#"0" - #"9" #"A" - #"Z" #"a" - #"z" ".-"]
at-char: #"@"

email: [

   space
   start:
   some mailchar
   at-char
   some mailchar
   end:
   space
   (print copy/part start end)

]


str: "afadfa adfa asdfasdfa fd [asdfas-:-adfadf-:-adfa-adfadfsda-:-com] adfafaf 
a af"

parse/all str [any [email | skip]]

That eliminates email adresses inside of < >, but maybe it was not 
an intention?

It would be nice if REBOL could LOAD foreign! data.  :)  Hint hint 
wink wink.


And being here in a public REBOL forum I might get in trouble for 
suggesting this one.

$ grep -o -E '\b[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}\b' 
files...

Brian ... you post is broken ... it contains some strange binary 
fragments :-)

Brian, you can probably do that grep with a few CHARSET and PARSE 
in REBOL.

And actually I think it's wrong anyway ... as it should be.  Posting 
regex in a REBOL forum ... shame on me.   ;)

Thank you, I'll try Pekr solution. I don't need the "<" and ">" characters.
However, where I can found some good parse documentation?

Rebol Parse documentation: 
http://www.rebol.com/docs/core23/rebolcore-15.html

http://www.codeconscious.com/rebol/parse-tutorial.html

I'm having trouble parsing the "none" datatype from within blocks.
The following example illustrates my problem (hopefully):
junk: [none [1 2 [3 4]]]

parse/all junk [none (print ["nothing"]) text: (print ["text:" mold 
text]) set b block! (print ["block:" mold b])]

This produces the following output:
nothing
text: [none [1 2 [3 4]]]
== false


Notice that the block doesn't get parsed. It seems that parse ignores 
"none" tokens rather than extracting them from the input stream. 
If I put a number in place of none and parse for "number!", then 
the block does indeed get parsed.

Is this a bug or an oversight? Or am I just confused?

'none isn't a datatype - none! is:

>> parse/all junk [none! (print ["nothing"]) text: (print ["text:" 
mold text]) set b block! (print ["block:" mold b])]              
                           
nothing
text: [[1 2 [3 4]]]
block: [1 2 [3 4]]
== true

I tried that  but it doesn't seem to work.
I'm getting nothing but 'false being returned.

Correction, I tried it in my actual program, rather than the test 
stub, and it seems to work fine.
Thanks.

the difference with your program is that [none] is not containing 
the none value but the none word.
if you reduce your example , it mays work
junk: reduce [none [1 2 [3 4]]]

Ah, forgot to copy that part - I'd done "junk/1: none" to make sure 
it was a none value

Steeve: that seems to have done it. thanks for clarifying.

or use #[none] instead

Gabriele what #[none] really does/means? I've seen it few times having 
no clue about its functionality.

Pavel, try:

mold/all none

it's just a serialized version of none!, so you can load it as a 
real none value instead of a word.

Pavel, this also works with datatypes.  For example:

>> mold/all string!
== "#[datatype! string!]"


This is useful if your loading values from a file.  This way your 
sure to set a value to a string datatype! when desired.

#[none] is the value of the word 'none. It is the literal representation 
of the value of type none!.

THX for description to all

Hi, I have one question .. can you somehow break out of some loop 
by rebol code .. for example


parse [ aa zzz cc ]  [ some [ set W word! ( ?? W if equal? W 'zzz 
[ break ] ) ] ]  ...  that break doesn't work that way, but is there 
some way to do this? I need to compare W with a runtime value

throw an error?

I solved it in a way that I can just return out of whole function 
(with return) at that point so it's ok .. first I had it thought 
out in a way that I would need to exit the some [ ] loop but continue 
parsing .. error probably wouldn't work that way either? This is 
now my code..match: 

match func [ data rules ] [
	parse rules [ 
		SOME 

  [ 	set L lit-word! ( either equal? L reduce first data [ data: next 
  data ] [ return false ] ) | 
			set W word! ( set :W first data  data: next data ) 
		] 
	]
]