Is it possible to override rebol path operator?

Question

It is possible to overide rebol system words like print, make etc., so is it possible to do the same with the path operator ? Then what's the syntax ?

Answer 1

Another possible approach is to use REBOL meta-programming capabilities and preprocess your own code to catch path accesses and add your handler code. Here's an example :

apply-my-rule: func [spec [block!] /local value][
    print [
        "-- path access --" newline
        "object:" mold spec/1 newline
        "member:" mold spec/2 newline
        "value:" mold set/any 'value get in get spec/1 spec/2 newline
        "--"
    ]
    :value
]

my-do: func [code [block!] /local rule pos][
    parse code rule: [
        any [
            pos: path! (
                pos: either object? get pos/1/1 [
                    change/part pos reduce ['apply-my-rule to-block pos/1] 1
                ][
                    next pos
                ]
            ) :pos
            | into rule    ;-- dive into nested blocks
            | skip         ;-- skip every other values
        ]
    ]
    do code
]

;-- example usage -- 

obj: make object! [
    a: 5
]

my-do [
    print mold obj/a
]

This will give you :

-- path access --
object: obj
member: a
value: 5
--
5

Another (slower but more flexible) approach could also be to pass your code in string mode to the preprocessor allowing freeing yourself from any REBOL specific syntax rule like in :

my-alternative-do {
    print mold obj..a
}

The preprocessor code would then spot all .. places and change the code to properly insert calls to 'apply-my-rule, and would in the end, run the code with :

do load code

There's no real limits on how far you can process and change your whole code at runtime (the so-called "block mode" of the first example being the most efficient way).

Answer 2

You mean replace (say)....

print mold system/options

with (say)....

print mold system..options

....where I've replaced REBOL's forward slash with dot dot syntax?

Short answer: no. Some things are hardwired into the parser.