If a function calls an argument something like /ALL, you end up in an annoying situation of losing access to the default ALL. This ends up with me often writing things like:
foo: func [ bar "some ordinary-named argument" /all "description of this" ; comment with STERN WARNING about rename [integer! block!] ][ all-FOO: :all ; capitalization helps draw attention to the switcheroo all: :lib/all all [... all-FOO ...] then [...] ]
This is ugly, laborious, and failure-prone. Some of the routines that do this are complex, and it's hard to see the whole thing when you've got
/all and "description" as the first thing you see. Hence despite the STERN WARNING, you're still likely to forget and try to reference the parameter via ALL, getting the native instead.
Mechanically this implementation isn't even really ideal...even better would be some way of preserving the definition of whatever ALL was when the function is defined, without having to remember where it came from (or know if it was locally overridden). That requires code to run prior to the execution, e.g. static initialization:
foo: func [bar /all <static> all-saved (:all)] [ all-FOO: :all all: all-saved all [... all-FOO ...] then [...] ]
That's a mouthful, and costs an extra variable for doing the swap. (Note: would be nice if
swap 'all 'all-foo worked, taking WORD!s)
This is a real problem, so can the spec dialect do better?
I'd wondered if having extended paths might be a way of doing this; the first path word is the public name, with the second being the private:
foo: func [bar /all/all-FOO] [ ... all [... all-FOO ...] then [...] ]
One thing that kind of displeased me about it is that if you did this with a normal parameter, it would get a slash in it. But tuples might avoid that. Also, the necessity to draw attention to it is less...because you see it up in the parameter list, so there's less odds you'll overlook it. So the capitalization can probably be dropped:
foo: func [bar.bar-foo /all.all-foo] [ all [... all-foo bar-foo ...] then [...] ]
It might not be the most beautiful thing in the world, but this is a real problem that is very frustrating when it comes up. And when you encourage people to play with words, they shouldn't be afraid to reuse them in refinements if they make sense.
Objections? Better ideas?