r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Parse] Discussion of PARSE dialect

BrianH
1-Nov-2005
[660x4]
f: open/direct file
a: copy/part f 4096

parse a [some [rule1 | rule2 | b: if (if a: copy/part f 4096 [b: 
join b a]) :b]]
With the IF workaround applied, if you can.
Well, I submitted the entry when you all said it was OK (I forgot 
to mention). Now we get to see how it all turns out. I like RAMBO 
much more than feedback - more public.
Later all!
Graham
1-Nov-2005
[664]
Keep us informed on the outcome :)
Gabriele
1-Nov-2005
[665]
btw, my compile-rules.r implements IF (i don't recall if exactly 
as noted above, but i think so, or very close). i had a rep with 
this and other things too.
Ladislav
1-Nov-2005
[666]
http://www.compkarori.com/vanilla/display/TO, THRU And NOT PARSE Rules 
implements IF too, but using IF [...] instead of IF (...) , which 
is the only difference as far as I can tell
BrianH
1-Nov-2005
[667]
Gabriele, I recall that it didn't work the same, but have no way 
of checking that right now because I couldn't find your compile-rules.r 
on rebol.org and you didn't provide a link just now.
Gabriele
1-Nov-2005
[668x4]
it's different, as i made it as:
| 'if set val1 paren!                        ; NEW: apply rule only 
if condition is true
            element

      | 'either set val1 paren!                    ; NEW: choose rule based 
      on condition
            element
            element
i think there are pros and cons to both approachs.
i admit i haven't used if and either much though, what i used a lot 
was DO.
BrianH
1-Nov-2005
[672]
I prefer the continue-if-true version. I particularly like that there 
is a workaround now that the backtrack-through-paren bug has been 
fixed since I first suggested an IF clause.
Ladislav
1-Nov-2005
[673]
BrianH: see the above link, it is an IF as you proposed, except that 
it uses a block instead of paren!, because that was simpler to implement, 
but it doesn't matter much, can be transformed
Graham
4-Nov-2005
[674x2]
How do get parse out ^?
>> caret: charset [ #"\^" ]
** Syntax Error: Missing " at caret: charset [ #"\^" ]
** Where: halt-view
** Near: caret: charset #"a"
Volker
4-Nov-2005
[676]
^^
Graham
4-Nov-2005
[677x2]
oh :(
I thought \ was the escape char.
Volker
4-Nov-2005
[679]
I like it. easier to include javascript in strings, no need to escape 
its escapes.
Graham
4-Nov-2005
[680]
What do you like?
Volker
4-Nov-2005
[681]
that rebol uses a different escape-char.
Graham
4-Nov-2005
[682x4]
ok
>> caret: charset [ #"^^" ]
== make bitset! #{
0000000000000000000000400000000000000000000000000000000000000000
}
>> obx: {OBX|1|ST|Hb^ Hb:^L||135|g/L|120 - 155|N|||F^/}
== "OBX|1|ST|Hb Hb:^L||135|g/L|120 - 155|N|||F^/"
>> parse obx [ "OBX" "|" digits "|" "ST" "|" thru caret to end ]
** Script Error: Invalid argument: make bitset! #{
0000000000000000000000400000000000000000000000000000000000000000
}
** Where: halt-view

** Near: parse obx ["OBX" "|" digits "|" "ST" "|" thru caret to end]
>>
BrianH
4-Nov-2005
[686]
Is that with the caret as an escape char, or as a value?
Volker
4-Nov-2005
[687x2]
that is thru with a charset. any caret
no, grrr, lack of smarter thru is annoying.
BrianH
4-Nov-2005
[689]
Because it looks like the carets in your data are registering as 
escape characters. That ^H is registering as a backspace character, 
not the sequence "^H".
Volker
4-Nov-2005
[690]
any non-caret caret  ;?
Graham
4-Nov-2005
[691x2]
It's ^spaceH
ok, parse enhancement proposal .. allow one to change the escape 
character.
BrianH
4-Nov-2005
[693]
If you loading your data like you do when you type it on the interpreter 
command line, carets are treated as escape characters. If you are 
getting it from the read command, they aren't.
Volker
4-Nov-2005
[694]
that you have to escape all the ^ to ^^ in strings is true too, but 
not the error-reason. the rule should fail, not error.
Graham
4-Nov-2005
[695x3]
the data is medical HL7 formatted data.
It's being read in from a file.
so, it shouldn't be escaped in the data itself.
BrianH
4-Nov-2005
[698]
So if you copy your test data to the clipboard, you would assign 
it to a variable like this:
obx: read clipboard://

If you are reading it from a file with the read or open functions, 
there is no escaping.
Volker
4-Nov-2005
[699]
then it should be no problem. only when load sees it in strings. 
if you 'read it, no escaping is needed. and mold auto-escapes.
Graham
4-Nov-2005
[700]
Ok, I am testing on the command line.  May be that is the problem.
BrianH
4-Nov-2005
[701x3]
Try reading from the clipboard directly like I suggested for that.
Note: The form native doesn't escape on output like mold does.
Oh wait, the error in his parse statement isn't because of escaping. 
It's the thru bitset that isn't supported. Try this:
caret: charset "^^"
non-caret: complement caret

parse obx ["OBX" "|" digits "|" "ST" "|" any non-caret caret to end 
]
Graham
4-Nov-2005
[704]
does that return true ?
Volker
4-Nov-2005
[705]
should work like thru.  "any non-caret" is like "to caret", then 
skipping it is like "thru caret". without caret it would go to end, 
and then the final skip fail.
Graham
4-Nov-2005
[706]
>> obx: {OBX|1|ST|Hb^ Hb:^L||135|g/L|120 - 155|N|||F^/}
== "OBX|1|ST|Hb Hb:^L||135|g/L|120 - 155|N|||F^/"
>> caret: charset "^^"
== make bitset! #{
0000000000000000000000400000000000000000000000000000000000000000
}
>> non-caret: complement caret
== make bitset! #{
FFFFFFFFFFFFFFFFFFFFFFBFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
}
>> parse obx [ "OBX" copy test some non-caret caret to end ]
== false
>> test
== "|1|ST|Hb Hb:^L||135|g/L|120 - 155|N|||F^/"
>>
Volker
4-Nov-2005
[707x3]
Yes, so it works
remember the "^" in your string are no "^", else they would be molded 
as "^^"
i would really get the data from outside. put them in a file and 
use obx: read %data.txt, or use clipboard.