World: r3wp

The best way to do the local variables is to put the PARSE call and 
the rules in a function, and if you have to use recursive rules, 
recursively call that function in an IF (...) operation. It really 
works well, in a roundabout sort of way.
 - this is too much of a roundabout for most cases, I have to add

Fork, that won't work on some return types, and that would lead to 
runtime errors. But in theory, yes.

Ladislav, true. But since PARSE doesn't really recurse, the only 
direct way to have local variables would be to BIND/copy the parse 
rules for each level of recursion. Doing the function recursion method 
is actually more efficient and easier than that.

I guess, that it is the time to propose a reasonable and efficient 
method

I defined a USE-RULE function yielding a rule with local variables. 
Now I wonder where to publish it.

REBOL.org, or perhaps your own site for now? Or as a wiki page linked 
from PARSE docs?

http://en.wikibooks.org/w/index.php?title=REBOL_Programming/Language_Features/Parse&stable=0#USE_rule

Thanks Ladislav. 

What do 'fni and 'fnii stand for?


I would certainly add a comment or doc string that USE-RULE is recursive/thread 
safe, which is why it's not much simpler.

FNI is just "fixed guts" of the CONTEXT-FN put in the CONTEXT-FN 
function body as a function to not intefere with the context. FNII 
is "dynamic guts" of CONTEXT-FN. By assigning different functions 
to the FNII variable we adjust what the CONTEXT-FN is actually doing.

Sorry, I meant to ask what the words were abbreviations for.

FN - internals (aka "guts")

Ah, thanks.

So, something like 'inner-body.

And 'inner-inner-body. :-)

yes, I wanted to have a FNII variable referring to a function having 
access to the CONTEXT-FNs context without being influenced directly 
by the context

...and yet influencing what the CONTEXT-FN is actually doing

It's another great example of bending REBOL to your will with a great 
deal of control.

If I wanted to do it just in R2, it could have been simpler, but 
R3 is more picky about what it allows

(in R2 you can directly modify the CONTEXT-FN, which is protected 
in R3)

Does it look like I understand it, based on these comments?

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

Quite precise, except for the fact, that SUCCESS and POS are mainly 
used to "transfer" the inner parse state to the "outer parse"

Thanks. I'll note that. I usually have to analyze your code bit by 
bit to understand it. :-)

I am glad you added your notes. I hope you do not mind me using your 
comments to make the code more understandable for others?

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