As part of Rebol's contention-for-short-names problem, there are many instances where refinements have names like /ALL where they conflict with common natives or lib functions.
When this happens, I tend to do something to name them out of the way and put the lib function back:
foo: function [ bar [block!] /all "foo all the bars" ][ all_FOO: all ; !!! Note: this is proposed to become /all all: :lib/all ... ]
Clearly we need a better pattern. Something that occurred to me today was the idea of being able to name refinements in the spec via a longer path:
foo: function [ bar [block!] /x/all "foo all the bars" ][ ... ]
The concept would be that the interface to the user (e.g. HELP) would still just show /ALL. But you as the function author could clearly see that you were supposed to refer to the refinement as /X/ALL in the body of the function. And the binding of ALL would be left alone inside the function body to whatever it would typically be.
For performance, the name you pick in the path could be set up as an alias for the frame of the function itself. So if you probed the
x above you would see it is a FRAME! with
all inside it. If you wanted to, you could call
x something more meaningful like
this, or if you aren't making recursive calls you could even name it
The same could apply to normal arguments, just with no leading slash:
foo: function [ x/bar [block!] /x/all "foo all the bars" ][ ... ]
So that would leave
bar bound as-it-was in the body, vs. binding it to the