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

World: r3wp

[Parse] Discussion of PARSE dialect

BrianH
17-Jul-2007
[2170]
No changes yet. I agree that parse needs some improvements - we've 
written whole papers on that.
Dockimbel
17-Jul-2007
[2171]
AFAIK, datatype matching is reserved for block! parsing. IMHO it 
should report a dialect error! in your example. Is string! matching 
supposed to support datatypes in latest core releases, maybe I missed 
an evolution ?
BrianH
17-Jul-2007
[2172]
One of those proposals, brought up in the comments of one of Carl's 
blogs, is to unify the block and string parsing dialects.
Gabriele
17-Jul-2007
[2173]
doc, integer! works for strings for some reason. it's the only one 
that works, and seems to match a sequence of digits (not sure if 
it does anything more than that). it's been there since a long time 
(probably from the beginning ;) but not documented.
Dockimbel
17-Jul-2007
[2174]
It looks to me more as a bug than as an intended feature (maybe a 
side effect of the block! parsing addition?). Anyway matching REBOL 
datatypes in string! parsing mode could be a useful feature and would 
make a lot of parsing rules shorter.
Tomc
19-Jul-2007
[2175]
I asked Carl at the first devcon for the rest of the datatypes when 
string parsing and he agreed at the time that if integer! was in 
there others should be as well.
Rebolek
26-Jul-2007
[2176]
Is it possible to parse exact integer! value? something like parse 
[1.0][1.0] but with integer!. And something more "elegant" than parse 
[1][set val integer! (equal? val 1)] :)
btiffin
26-Jul-2007
[2177]
parse [1 2 3] [1 1 1 1 1 2 1 1 3]   You have to trick the repeat 
ranges
Geomol
26-Jul-2007
[2178x2]
Alternative:
parse form [1 2 3] ["1" "2" "3"]
Yet another alternative:
>> parse [1 2 3] [1.0 2.0 3.0]
== true
Rebolek
26-Jul-2007
[2180]
thanks for suggestions
Geomol
26-Jul-2007
[2181]
Think, the last alternative only works, because both integer and 
decimal are categories of number. It doesn't seem to work with other 
'number'-like datatypes, like money or tuple.
Rebolek
26-Jul-2007
[2182]
I was just curious how to do pattern-matching in REBOL  with parse
[unknown: 5]
5-Aug-2007
[2183x2]
Anyone know what "^-" is called?
is thta a tab?
Henrik
5-Aug-2007
[2185]
>> tab
== #"^-"

yes :-)
[unknown: 5]
5-Aug-2007
[2186x2]
ok
I'm trying to parse data using that but seem to get it parsing some 
spaces also
Henrik
5-Aug-2007
[2188]
parse/all perhaps
[unknown: 5]
5-Aug-2007
[2189x5]
I'll try it
no that parses every letter
I'm beginning to wonder if it is a bug in parse
Anyone know how to parse a string such that the newlines and tabs 
are parsed?  I'm not getting the results I'm expecting.
Hoping to see someone elses command in case I'm just brain farting 
something.
PeterWood
5-Aug-2007
[2194]
>> a: join "line1" [newline "line2"]
== "line1^/line2"
>> parse a [any [newline (print "newline found") | skip]]
newline found
== true
Steeve
5-Aug-2007
[2195]
yeah, never had problems when parsing tabs and newlines
Geomol
6-Aug-2007
[2196]
When parsing strings without the /all refinement, words are separated 
by space. Example that work:

>> parse "word1 word2^-word3^/word4" ["word1" "word2" "word3" newline 
"word4"]
== true
You can also explicit specify the tab:

>> parse "word1 word2^-word3^/word4" ["word1" "word2" #(tab) "word3" 
newline "word4"]
== true

Actually the #(tab) seems to be ignored, because you can specify 
it anywhere:

>> parse "word1 word2^-word3^/word4" ["word1" "wo" #(tab) "rd2" "word3" 
newline "word4"]
== true

But you get false, if specifying the space (which may be a strange 
thing):

>> parse "word1 word2^-word3^/word4" ["word1" #" " "word2" "word3" 
newline "word4"]
== false
Also you need to specify newlines, they are not seen as space:

>> parse "word1 word2^-word3^/word4" ["word1" "word2" "word3" "word4"]
== false

If you need to parse for tabs at certain places, use: parse/all
I hope, it helps!
Gabriele
6-Aug-2007
[2197x2]
>> b: [#(tab)]
== [# (tab)]
>> length? b
== 2
>> first b
== #
>> type? first b
== issue!
>> second b
== (tab)
>> type? second b
== paren!
so your "tab" is ignored because it's not a tab at all. it's the 
same as doing "" (tab) in the rule, ie empty string (always matches) 
followed by code that basically does nothing.
Geomol
6-Aug-2007
[2199x4]
Aha! :-)
How did I get #(tab) in my head!?

So to explicit specitying the tab, it must be:

>> parse "word1 word2^-word3^/word4" ["word1" "word2" "^(tab)" "word3" 
newline "word4"]
== false

So that doesn't parse, meaning tabs are seen as spaces.
Sorry about any confusion! :-)
And I guess, tab can be specified in the rule-block more simple as 
in::
["word1" "word2" tab "word3" newline "word4"]
Gabriele
6-Aug-2007
[2203]
you need parse/all to be able to parse spaces and tabs.
[unknown: 5]
7-Aug-2007
[2204]
Thanks everyone for your posts on this
Geomol
7-Aug-2007
[2205]
Paul, it could be good to know, if you got it to work!?
Chris
7-Aug-2007
[2206]
G: #"^(tab)"
Geomol
7-Aug-2007
[2207]
Probably.
PatrickP61
20-Aug-2007
[2208x2]
Hi all,
Are there any good references to learn PARSE?
Henrik
20-Aug-2007
[2210]
There is a parse page on the Wikibook.
PatrickP61
20-Aug-2007
[2211]
Found it -- Thanks
Geomol
20-Aug-2007
[2212]
Also this about parsing: http://www.rebol.com/docs/core23/rebolcore-15.html
[unknown: 5]
24-Aug-2007
[2213]
parse/all  and used "^-" for tab
[unknown: 5]
31-Aug-2007
[2214x2]
Ok ran into an issue.  Is there an easy way to parse a string that 
has doublequotes in it together.  Such as {some chars "" some more 
chars"" and more}
I need the quotes to be single just one set and not two together 
and the parse to keep intact the string section because often it 
is a part of an html tag.
Robert
1-Sep-2007
[2216x2]
Paul, do a search & replace upfront. Much simpler than to create 
complex parse rules.
I often use this pattern. Do some basic action on the parse input, 
parse the first round, again do some other processing than using 
parse again. Much simpler and faster to get where you want to go.
Tomc
1-Sep-2007
[2218]
paul what rule are you using for your parse
[unknown: 5]
1-Sep-2007
[2219]
Thanks Robert, I'll look into that further as I did place with replace 
but because they were quotes it seemed that parse/all still wanted 
to break apart at a quote even though I told it only tabs.