World: r3wp

just making it explicit

I should remove those "thru"s I've got there.

this header-rule should now be applied each time I get  a "^/" ...

and if you had a header with a line that did not begin with  'Date, 
From, Subject or To  then you could prematurely break out of header-rule 
 before you got all your bits

How ?

header-rule: [
    "Date:" copy m-date to newline |
    "From:" copy m-from to newline |
    "Subject:" copy m-subject to newline |
    "To:" copy m-to to newline |
    to newline
]
m-subject: m-date: m-from: m-to: none

parse header [header-rule some [ thru "^/" header-rule]]

oh, I see ...

else
Date: ...
X-Something: ...   ; break the rule
To: ...
From: ...

If you are testing "^/" I would think that you need to use parse/all.


You may find my script helpful for visualising the effect of your 
rules:


http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=parse-analysis-view.r

oops - you're right, I missed the big one.

so, is PCRE easier to understand ??

$&^*&#&%(*_&$*@#@

looks like perl

that is just random chars not a pcre for paesing mail headers

Oh :)

I was just attempting to bring the subject back on topic before I 
interrupted it.

that was not an interuprion , more liks exactly what this group is 
for

since I have no idea what pcre was ..

. match any sigle char but newline

* 0 or more of the precedding

()   pit in var $n  [n1,2,3 ...]

/T0: (.*)

$1  has to whom the email is addressed

While we're here .. what this taint thing that Perl has, and is it 
a concern for Rebol ?

tainting forces you to consider the users input  and explicitly allow 
it to pass

I think only people who miss it want it. :)

Taint mode tells Perl that you aren't sure whether your incoming 
data is safe. It's just a shortcut for enforcing commonsense programming.

so, it's to prevent incoming data being executed ?

you can write a well considered script without taint that is far 
more secure than a script that passes taint mode by making a simple 
rule that does not properly catch  problems

you basicky have to weite a regular expression to accept user input

Graham: for your header, like Brett said, parse/all is needed when 
you work on strings with newlines and spaces. last line should be:
parse/all header [header-rule some [ thru "^/" header-rule]]

Graham, yes, but it's also used in other situations: force the programmer 
to escape HTML input before printing it back out, massaging data 
so that it's friendlier for the database, etc.

Yeah, I got that Vincent.  Curiously though it has worked without 
it.

in your example  having a rule more like 
header-rule: [
    "Date:" copy date-rule  |
    "From:" copy email-rule |
    "Subject:" copy some alpha-num  |
    "To:" copy email-rule |
    to newline
]

where email-rule only matched email addresses  
 would more taint like

and being very careful to never  effectivly 

do [ user-input]


without being sure user-input  could not cause unintended side effectd

Not quite sure what to make of the following:
>> rule: [set w 'pubDate (print w)]
== [set w 'pubDate (print w)]
>> parse [pubdate] rule
pubdate
== true
>> parse/case [pubdate] rule
pubdate
== true

First off, would the last result be a bug?

Secondly, I'd like to ensure that whether the block is [pubdate] 
or [pubDate] that 'w stores 'pubDate.  I had hoped that as 'pubDate 
is set in the rule, it might take precedence over pubdate in the 
block :^(

I suppose /case only act on string!

/case only applies to strings. Chris, you can:

>> parse [pubdate] ['pubDate (w: 'pubDate print w)]
pubDate
== true

but i'm not sure you'll like it.

should be something easier than this 

like-i: charset [ #"1" #"l" #"L" #"I" #"i" ]
like-a: charset [ #"a" #"A" #"@"  ]
like-v: charset [ #"\" #"/" #"v" #"V" ]


cialis: [ "c" like-i like-a 2 like-i "s" ]
viagra: [ 1 2 like-v like-i like-a "gr" like-a ]

parse "\/[1-:-gr]@" [ viagra ]
parse "[c1-:-Lls]" [ cialis ]

hmm.. altme converts my double quote to a single quote

maybe use   charset "1lLIi"    to avoid that much typing ;)

Graham, the link width is slightly incorrect, so it obscures half 
of the double quote, so it looks like a single.

flatten: func [b [block!] /local flat][
	flat: copy[]
	rule: [
		some[
			[x: block! (parse first :x rule)] |
			[copy token any-type! (append flat token)]
		]
	]
	parse b rule
	flat
]

without the recursive call to parse

flatten: func [b [block!] /local flat rule x][
	flat: copy[]

 rule: [some[[x: block! :x into rule] | [copy token any-type! (append 
 flat token)]]]
	parse b rule
	flat
]

a flatten  that changed it's block in place would be useful at times