World: r3wp

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

Something like this? (it's not parse based though)

    flatten: func [block] [
        head forall block [
            if block? block/1 [change/part block block/1 1]
        ]
    ]

I have a problem with parse not terminating the parsing. Here is 
my code for parsing CamelCase words:

rebol []

; CamelCase Test


test-text: "FirstWord test. This is a CamelCase test Text. CamelCase2 
is the base idea for a WiKi. CamelcasE"

upper-case: charset "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
delimiters:	charset " .,;|^-^/"
rest-chars: complement union upper-case delimiters

text: ""

parse/all/case test-text [
	some [

   copy camelcase-word [upper-case some rest-chars upper-case any rest-chars] 
   (
		 	if not empty? text [?? text clear text]
		 	print ["CamelCase word found:" camelcase-word]
		)

  | copy flowtext [any [rest-chars | upper-case] any delimiters] (
			append text flowtext
		)
	]
]

halt

Any idea why parse doesn't return?

[any [rest-chars | upper-case] any delimiters] is always true, even 
if there is no char left  at the end. But it does not move the cursor.

rebol []

; CamelCase Test


test-text: "FirstWord test. This is a CamelCase test Text. CamelCase2 
is the base idea for a WiKi. CamelcasE"

upper-case: charset "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
delimiter:	charset " .,;|^-^/"
rest-char: complement union upper-case delimiter

text: copy ""


camelcase-rule: [some [upper-case some rest-char upper-case any rest-char] 
delimiter]

parse/all/case test-text[
	some [ 
			copy camelcase-word  camelcase-rule
				(if not empty? text [?? text clear text]
		 		print ["CamelCase word found: " camelcase-word]
				)
			| 
			copy flowtext upper-case 
				(append text flowtext)
			|
			copy flowtext[any [rest-char | delimiter]] 
				(append text flowtext)
	]
]
halt

what about camelCAse?

Personally I prefer the way mediawiki does it ... using [[ .. ]] 
... instead of having strange cases in words

yes, I was also concerned about  A1CamelCase  but figured Robert 
 just needed to get thru his first question first

Thanks, for the fix. Sometimes it helps to get some distance by asking 
others :-))

I like CamelCase words. Simple to remember and use. IIRC camelCAse 
is not a valid CamelCase word. But anyway, it depends how I teach 
my users :-))

http://en.wikipedia.org/wiki/CamelCase... CamelCase is referred 
to UpperCamelCase, and camelCase is referred to as lowerCamelCase

Tom, your example doesn't terminate, like mine. The thing IMO is 
that the last Word is a CamelCase word and the 'end condition is 
somehow missed. It nevery reaches the halt.

If you do not want to change the parse rules, you can just add
	if not flowtext [halt]
before
	append text flowtext