World: r3wp

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

>> 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"]

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

We so need a Wiki for Rebol, and shove every word and example into 
it.  Just Parse needs 100 pages of examples and descriptions.

lol

we need a wiki just for parse

and a new book.. Dialects for The Rest of Us (forget the Dummies 
version..)

Exactly!

books books, scripts in rebol.org are enough for me

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...

there is a rebol wikibooks

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?

playing with their new iphones and parsing text messages internally 
:)

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

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
>>

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

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**  :)

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)]])]

was almost there

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.  :)

after

well after  to paren!  before the block  ...in between.  :)   This 
trick is one of those V8 'tok' to the head moments.

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

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.

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.

No changes yet. I agree that parse needs some improvements - we've 
written whole papers on that.

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 ?

One of those proposals, brought up in the comments of one of Carl's 
blogs, is to unify the block and string parsing dialects.

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.

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.

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.