World: r3wp

Perhaps I can get around that by instantiating a new hl7object with 
each MSH segment...

Or not ...

Brian, yes! You remind me of that finding, long ago... I now remember 
thinking how it was good because of less syntax.

Romano, I don't think it is an error anymore. Note my examples contain 
the pipe |, which allows the rule to succeed on none input. eg, these 
rules are equivalent:
[copy var "a" | none]
[copy var "a" | ]

Your example, however, looks like an edge case... Probably parse 
checks for the end of the input before trying to match a string.

The 'to position' thing, we talk about in the RAMBO group also works 
with blocks:
>> parse ["string" 123 [me-:-server-:-dagobah]] [to 2 mk: (print mk)]
123 [me-:-server-:-dagobah]
== false


TO also works with datatypes, as explained in the Core documentation:

>> parse ["string" 123 [me-:-server-:-dagobah]] [to email! mk: (print mk)]
[me-:-server-:-dagobah]
== false

(Right brackets are left out just after the email address by Altme.)

geomol, out of curiosity, have you tried those incidents where parse 
will lock up and you need to quit REBOL? Have you tried to keep it 
running for a few minutes and see what happens?

nope

just wondering if that is a known behaviour. it returns to the console 
on its own

Strange and funny. Like it has it's own personality. ;-)

after about 5-7 minutes or so...

it's in one of the examples in the wikibook group

It an almost infinite loop then. Takes all the cpu.

Yes, it reply == false after some time here too.

good, then I'm not crazy :-)

wondering if there is some sanity limit on a billion loops or something

:-) Maybe integer overflow?

possibly if there is something that needs counting...

Anyway, parse works in a certain (and you could say special) way, 
when dealing with strings:
>> parse "a" [char!]
== false
>> parse "a" [string!]
== false
>> parse "a" [#"a"]
== true
>> parse "a" ["a"]
== true

So parsing a string for [any string!] maybe doesn't make much sense.

And parsing strings and chars within blocks give more meaning, when 
looking for datatypes:
>> parse ["a"] [char!]
== false
>> parse ["a"] [string!]
== true
>> parse [#"a"] [string!]
== false
>> parse [#"a"] [char!]
== true

using datatypes as rules, I think only work with blocks, not strings, 
which is why it returns false in the first two cases with "a"

Sadly, in string mode you can't use -- to charset!

Be great if you could:
>> chars: charset "ab"
== make bitset! 64#{AAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAA=}
>> parse "1234ab" [to chars]

** Script Error: Invalid argument: make bitset! 64#{AAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAA=}
** Near: parse "1234ab" [to chars]

You can with a little trick:

>> no-chars: complement charset "ab"
== make bitset! #{
FFFFFFFFFFFFFFFFFFFFFFFFF9FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
}
>> parse "1234ab" [some no-chars mk: (print mk) to end]
ab
== true

Yep, that's the workaround I use, but it can get complex...

I seem to remember Carl S. saying something about adding a safety 
check to parse to jump out of infinite loops...

Hi, I am checking the example in the parse chapter, section 7.3 copying 
the output , but I don't get it !!

parse {<h1>title</h1>}  [copy heading ["H" [ "1"  |  "2"  |  "3" 
]] (print heading)]

the text seems to imply that heading should contain the "title" string, 
but it doesn't work for me. any ideas ?

It's not a good example. You could do something like:


>> parse {<H1>A heading</H1>} [copy heading ["<H" ["1" | "2" | "3"] 
">" to "</"]]
== false
>> heading
== "<H1>A heading"

yes,  this makes sense but it doesn't handle opening and closing 
tags as the example seems to imply. I'll report to rambo so the docs 
get updated

thanks

Something I will never understand about parse:  

digit: charset [#"0" - #"9"]
parse "123" [ any [ digit | end ] ]

I hit the end of the damn string, SO QUIT!  *&(%@$(*&($#*%

NM...  I got it.  Parse is tricksy.

solution?

parse "123" [ any [ digit | thru end ] ]

yeah, each rule stop at a position, not going past it. that way you 
wouldn't be able to reach the tail of the series. THRU will get you 
to the tale

tail

The problem wasn't really that I wasn't so much not hitting the end 
as it was figuring out how to keep all of my data.  I'm breaking 
up some text using a semi-dynamic set of recursive rules and I kept 
loosing my last bit of data or hanging the interpreter...

Ah, recursive rules. :) I pushed my variables onto a stack when recursing, 
then popped them off when returning.

That tends to bloat the code a fair bit. ( push-vars [a b c] recursive-rule 
pop-vars [a b c] )

so then you get to thinking to generate this code automatically with 
a make-recursive-rule function, which takes a 

parse rule, looks for recursion in it, then surrounds it with push-vars 
and pop-vars for you (kind of macro expansion).
Or I did something like that, anyway.

I would be very interested in seeing this code of yours.  I'm planning 
on going further down the rabit hole of parse than anyone has gone 
before over the next couple of months.  ;-)

http://www.lexicon.net/antonr/rebol/library/make-recursive-rule.r

(Mmm.. it says it has a big flaw, but I know I'm using it successfully 
in a program. Maybe my input never trips the flaw, or I fixed it 
and forgot to write that down... Anyway, it gives you an idea how 
the user interface can look.)

Kewl, thanks!  I'll dig right into it. ;-)  (I'll be back, Wahahahaha!)

Mmm... I think only the old commented code has the problem. I would 
have to test that, though...

I'm forced to work with regular expressions now and I must say that 
PARSE is shining sun compared to that terrible black magic called 
regular expressions. They suck!

:-)

but they are said being powerfull tool, once you master them of course 
...

I always hear that if you need to use a UNIX OS, you need to learn 
them. So far I've done fairly well without them, but have been configuring 
procmail once, which was a complete nightmare. :-)