World: r3wp

I don't mind at all. :-)

set 'use-rule func [

    "Create a recursion and thread-safe parse rule with local variables. 
    R2/R3 compatible."
    words [block!] "Local word(s) to the parse rule"
    rule  [block!] "Parse rule"
] [
    make object! [

        ; Create a new function context. 'Inner-body refers to a function 

        ; with access to CONTEXT-FN's context without being influenced 
        ; directly by the context.
        spec: copy [/local]
        append spec words
        inner-body: func ['word] [inner-inner-body word]
        context-fn: func spec reduce [:inner-body first words]
        

        ; Bind the rule the caller gave us to the new context we just created.
        inner-inner-body: func [word] [bind/copy rule word]
        bound-rule: context-fn
        

        ; Now define the use rule. Because this is an "active" rule,
        ; with state we need to include some state variables used

        ; by the internal PARSE call ('pos and 'success). They are used to 
        ; "transfer" the inner parse state to the "outer parse".
        pos: none
        success: none
        inner-inner-body: func [word] [

            ; If the parse of the rule succeeds, we set the parse position

            ; to the where the rule match ended, otherwise we don't change

            ; the parse position and use [end skip] to return a false 
            ; result (for R2 compatibility).
            success: either parse pos [bound-rule pos: to end] [
                [:pos]
            ] [
                [end skip]
            ]
        ]
        set 'rule copy/deep [pos: (context-fn) success]
    ]
    rule
]

Typos in comments. Just a minute.

set 'use-rule func [

    "Create a recursion and thread-safe parse rule with local variables. 
    R2/R3 compatible."
    words [block!] "Local word(s) to the parse rule"
    rule  [block!] "Parse rule"
] [
    make object! [

        ; Create a new function context. 'Inner-body refers to a function 

        ; with access to CONTEXT-FN's context without being influenced 
        ; directly by the context.
        spec: copy [/local]
        append spec words
        inner-body: func ['word] [inner-inner-body word]
        context-fn: func spec reduce [:inner-body first words]
        

        ; Bind the rule the caller gave us to the new context we just created.
        inner-inner-body: func [word] [bind/copy rule word]
        bound-rule: context-fn
        

        ; Now define the use rule. Because this is an "active" rule,

        ; with state, we need to include some state variables used

        ; by the internal PARSE call ('pos and 'success). They are used to 
        ; "transfer" the inner parse state to the "outer parse".
        pos: none
        success: none
        inner-inner-body: func [word] [

            ; If the parse of the rule succeeds, we set the parse position

            ; to the point where the rule match ended, otherwise we don't 

            ; change the parse position and use [end skip] to return a false 
            ; result (for R2 compatibility).
            success: either parse pos [bound-rule pos: to end] [
                [:pos]
            ] [
                [end skip]
            ]
        ]
        set 'rule copy/deep [pos: (context-fn) success]
    ]
    rule
]

fine, I used your text, and added some more

Brian, do you think, that a more "seamless" way how to do the above 
in parse shall be considered, or that this approach is good enough 
as it stands now?

Reposting the link:

http://www.rebol.org/view-script.r?script=use-rule.r

Very useful ...

( that was a pun :) )

hmm, I thought that in R3, parse variables are safe for recursion 
rules?

ah, there was USE 1 (BrianH) and USE 2 proposal (Peta). USE 1 was 
assigned for implementation, but deferred along with LIMIT, OF, REVERSE 
and some other proposals ...

Pekr, there are no "parse variables", as far as I know. My above 
code was inspired by BrianH and USE2

I know, but I reacted upon Carl's recent blog, and if Carl dares 
to use the incorrect terminology, then I can too, no? :-)


This function is useful because PARSE rules often store data in variables 
which, depending on how you handle them, can be overwritten by rule 
recursion. (Which is done often in parsing.)

parse rules often store data in variables

 is fine, but that does not mean, that there are "parse variables", 
 those are just variables

ok, as for terminology, how do I refer to following:

start: copy user to "</user>" :end (temp: find blk user)


while the code is not real, I can see three different "variable types":

- start: :end markers
- user parse level variable?
- temp: rebol level word?

Thanks :-)

Sorry if you find it nitpicking, but I wanted to point out, that 
an assumption that "parse variables are safe for recursion rules" 
should be wrong exactly because there are only variables in REBOL, 
which the interpreter does not have any reason to make "recursion 
safe" unless you specifically do something about it.

Regarding the above "three different variable types" - as far as 
the interpreter is concerned, there is no difference between the 
'start 'end and 'copy variables. You used them in a specific way, 
but, later, you can very well use another expression, where you write:

user: copy start to "whatever" etc.


So, you can easily see, that neither the 'start nor the 'user variable 
has any "variable type" you could infer based upon their usage in 
one specific expression.

err, I meant the 'start 'end and 'user variables

if you call 'temp a "rebol level variable" in the above example expression, 
how would you call it in the expression below?

(temp: either 1 > 0 [none] [[end skip]]) temp

So, generally speaking, it may be useful for you to use some some 
variables only as "markers", but that "variable type" is something 
you impose just to make the things easy for you to handle. The interpreter 
does not (and should not) make such distinctions.

temp is "rebol level variable", whose value is bound to parse dialect 
:-)

Hmm, what does the "bound" word mean?

As I said, you can use some variables for specific purposes only, 
but that is your decision, and is not supported by any interpreter 
property, and certainly is not useful for all purposes. I may want 
to use some variables in more "roles" than you want to.

hmm, then maybe not. Temp following the paren simply refers to the 
rule, resulting from previous paren expression evaluation ....

and hence is probably a regular rebol level word, just used inside 
the parse dialect?

In my opinion, all of the above 'start 'end 'user and 'temp words 
are "regular" REBOL words, while e.g. the 'copy word above is actually 
a parse dialect keyword

corret ...

and - it was not nitpicking on your part - using the correct terminology 
where possible is important, as it helps to correctly interpret the 
way in which the language works. It is just lack of knowledge on 
my part, that I confuse the terms ... exactly because I often don't 
understand the internals ...

start: :end and temp: would just be called set-words and get-words, 
either within the Parse dialect or the Do dialect (Do dialect being 
"rebol level")

To be even more precise;

The 'copy word above is also a "regular" rebol word (it just happens, 
additionally, to be interpreted by PARSE as a keyword in the PARSE 
dialect).

Re start: and :start e.g. - they are values of different datatypes, 
but can be seen as just one variable.

http://www.rebol.org/view-script.r?script=use-rule.rupdated. Changes: 
now it implements both USE-RULE variants as described in http://www.rebol.net/wiki/Parse_Project
.

Hi, I rewrote http://www.fm.tul.cz/~ladislav/rebol/evaluate.rto 
contain slightly more comments and to use the USE-RULE function, 
so that it now became a more complex example of its usage.

I hope everyone struggling with local variables in PARSE to find 
this a much more comfortable way.

On the other hand, I expect the %evaluate.r to have a value of its 
own, since it shows how to handle expressions using PARSE, while 
being able to respect different priority/associativity rules sets.

The funny thing about it is, that just one local variable per parse 
rule was quite sufficient in this case, although the example isn't 
trivial in my opinion.

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Local_variables_in_parse_rules
, a new subsection in the REBOL Programming wikibook.

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Local_variables_in_parse_rules

a new section in the REBOL Programming wikibook

wowo, most awesome Ladislav!

Pekr, knowing that you were interested in the subject as well, I 
sincerely hope, that you read the wikibook subsection, run the examples, 
and let me know what you are missing in the doc and in the functionality.

thanks, Janko

hi, i would you to parse a string like this {number: 123456 name: 
abcd message: i like rebol}

i would like to use parse to do it

something like this way parse mystring ["number:" number: "name:" 
name: "message:" msg:]]

a get number, name and msg . is that possible ? and how ?

is the data guaranteed to be rebol compatible?  (you can use 'LOAD 
on it and it will never return an erro)

but mystring is like this {Number : 10017
Name       : Disable Message Partner
Application: MXS
Severity   : Info
Type       : Alarm Event
Date-Time  : 20/09/10 12:39:43
GMT        : Mon Sep 20 10:39:43 2010}

i start to use => parse mystring [thru "Number  :"  number: to end]

i would like to do => parse mystring [thru "Number :" number: to 
"Name    :" ] but this don't work !!!!]

using 'TO or THRU rules is garanteed to make you life a nightmare 
for arbitrary string parsing, unless its very linear in content.