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

World: r3wp

[Parse] Discussion of PARSE dialect

Steeve
28-Jun-2007
[2122x2]
it's the french touch ;-)
hey Brock , still alive ?
Tomc
29-Jun-2007
[2124x2]
do rules: [
	set 'a "first rule "
	set 'b "second rule "
	set 'c "third rule "
]

rule: [ 
	[end (if empty? erode[here: back tail :here]) :here skip]| 
	[here: erode there: 
	(	all[
			token: copy/part :here :there
			word: find rules token
			word: first back word
			remove/part find erode word 2 
		]

  all[empty? erode not tail? there insert/only erode [] there: tail 
  there]
	)] :there
    rule
]

data: "first rule second rule third rule "
erode: [ a | b | c | a]  parse/all data rule
left expanded for clarity
Steeve
30-Jun-2007
[2126x5]
i would have to discuss what follow before posting it in Rambo
parse "  a" [copy r "a"]
>>r
== " a"
i think it should be r = "a" instead
*i would have speech
Tomc
30-Jun-2007
[2131x5]
>> parse/all " a" [any " " copy r "a"]
== true
>> r
== "a"
I try toi allways yse /all when I give a block of rules
and use pases by itself aith the none rule
r: parse " a" none
["a"]
Steeve
30-Jun-2007
[2136x3]
hi Toms, as always don't focus on the example i give but on the issue 
i suggest, another one example:
>>parse "ld   a  b" ["ld" "a" copy reg ["b" | "c"]]
>> r == " b" 
>> i just think it will be more logic to have r == "b"
(replace r by reg)
i well know how to skip blank chars, but i think it's not logic in 
that case
[unknown: 9]
30-Jun-2007
[2139]
We so need a Wiki for Rebol, and shove every word and example into 
it.  Just Parse needs 100 pages of examples and descriptions.
ICarii
30-Jun-2007
[2140]
lol
Steeve
30-Jun-2007
[2141]
we need a wiki just for parse
ICarii
30-Jun-2007
[2142]
and a new book.. Dialects for The Rest of Us (forget the Dummies 
version..)
[unknown: 9]
30-Jun-2007
[2143]
Exactly!
Steeve
30-Jun-2007
[2144]
books books, scripts in rebol.org are enough for me
[unknown: 9]
30-Jun-2007
[2145]
There is always another trick, and another level to Rebol, the docs 
NEED to be in a Wiki, where we can add to them, let them live, breath...
ICarii
30-Jun-2007
[2146]
there is a rebol wikibooks
[unknown: 9]
30-Jun-2007
[2147]
Yeah, it needs someone to kick it off, get it started, fill it with 
about 50 good words.  Where is a "kid" when you need one?
ICarii
30-Jun-2007
[2148]
playing with their new iphones and parsing text messages internally 
:)
Steeve
30-Jun-2007
[2149x3]
so, spending money to be cool
(but what is the interest to purchase what everyone wants, that's 
not cool at all)
REBOL is cool, and free
Tomc
1-Jul-2007
[2152x2]
Steeve do you have any case where the self modifying recursive parse 
rule above fails?
>> ; insufficent pattern
>> data: "first rule second rule third "
== "first rule second rule third "
>> erode: [a | b | c]
== [a | b | c]
>> parse/all data rule
== false
>>
>> ;;; unused rule before pattern is consumed
>> data: "first rule second rule third rule "
== "first rule second rule third rule "
>> erode: [a | b | c | a]
== [a | b | c | a]
>> parse/all data rule
== false
>>
>> ;;; patterns and rules allowed in any order
>> data: "first rule second rule third rule "
== "first rule second rule third rule "
>> erode: [c | b | a]
== [c | b | a]
>> parse/all data rule
== true
>>
>> ;;; multiple (duplicate) rules allowed
>> data: "first rule first rule second rule third rule "
== "first rule first rule second rule third rule "
>> erode: [a | b | c | a]
== [a | b | c | a]
>> parse/all data rule
== true
>>
Steeve
1-Jul-2007
[2154x2]
no i don't, it's an intersting alternative to my own code
a crazy simple alternative from DocKimbel (non repetitive pattern 
and limited to rules with single char)

>> rule: [(c: charset "ABC") 3 [copy v c (remove/part c v)]]

>> parse "ABC" rule
== true
>> parse "BAC" rule
== true
>> parse "CBA" rule
== true
>> parse "ABA" rule
== false
>> parse "ABCA" rule
== false
btiffin
6-Jul-2007
[2156]
How do you build parse rules?

rule: copy []
word: "abc"

;; Want to compose the block to look like this  ["abc" (print ["found 
word len" 3])] 

insert tail rule compose [(word) (print "found word len (length? 
word))]  no go - obvious

I've tried  compose/deep [(word) (to paren! [print ["found word len" 
(length? word)])]  but length? word doesn't get composed, it gets 
included in the to paren! expression  compose/only/deep same thing


I guess the question is what is the technique to compose something 
that is to include paren! expressions with data inside that needs 
to be composed?  **With binding of course**  :)
Chris
7-Jul-2007
[2157x2]
reduce [word to paren! compose/deep [print ["Found Word of Length" 
(length? word)]]]
compose [(word) (to paren! compose/deep [print ["found word len" 
(length? word)]])]
Tomc
7-Jul-2007
[2159]
was almost there
btiffin
7-Jul-2007
[2160x2]
Thanks gentlemen.  I've struggled with that one on and off for...well 
forever.
compose/deep before the to paren! block, makes so much sense...ummm, 
now.  Now that I've seen it.  :)
Tomc
7-Jul-2007
[2162]
after
btiffin
7-Jul-2007
[2163]
well after  to paren!  before the block  ...in between.  :)   This 
trick is one of those V8 'tok' to the head moments.
Geomol
17-Jul-2007
[2164]
How should string parsing work? I see something peculiar:

>> parse "1 2" [copy a1 integer! copy a2 integer!]
== true
>> a1
== "1"
>> a2
== " 2"
>> to integer! a2
** Script Error: Invalid argument:  2

Doing it this way make a2 different:

>> parse "1 2" [copy a1 integer! opt [copy a2 integer!]]
== true
>> a1
== "1"
>> a2
== "2"
>> to integer! a2
== 2
Gabriele
17-Jul-2007
[2165x3]
when using parse (not parse/all) you can skip spaces putting something 
like "" in the rule
eg [copy a1 integer! "" copy a2 integer!]
i always use /all though.
Geomol
17-Jul-2007
[2168x2]
I ended up doing something similar. I just speculate, if parse can 
be made easier to use, when doing string parsing without /all.


Also string parsing can deal with the integer! datatype. Why not 
other datatypes? Are there deeper reasons for this?
Gabriele, do you know, if there are changes to parse in R3? Maybe 
string parsing without /all should be changed.
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 ?