This is a vision statement for using the new @word, @pa/th, @[bl o ck] and @(gr o up) datatypes for an interesting purpose.
The idea is to have a way to mark an argument conveniently as controlling a refinement--without mentioning that refinement at the callsite, or needing a specialization of the function dispatched through a different name.
Perhaps it's easiest to see by example:
demo: function [@a /mode-a @b /mode-b] [ print ["a:" mold a] print ["mode-a:" mold mode-a] print ["b:" mold b] print ["mode-b:" mold mode-b] ]
Using literal (non-quoted) @-arguments will automatically turn on the associated mode refinement. The argument itself will be the appropriate value for the non-@ version of the argument. (WORD! and PATH! will fetch, GROUP! will evaluate, BLOCK! will be unevaluated).
>> demo 1 + 2 10 + 20 a: 3 mode-a: _ b: 30 mode-b: _ >> demo @(1 + 2) 10 + 20 a: 3 mode-a: /mode-a b: 30 mode-b: _ >> foo: "foo" | demo @[x y z] @foo a: [x y z] mode-a: /mode-a b: "foo" mode-b: /mode-b >> foo: [10 @bar] | demo '@[x y z] second foo a: @[x y z] mode-a: _ b: @bar mode-b: _
The refinements are available to invoke independently as normal. This means that from a specialization or APPLY standpoint the parameter convention would be as-is.
This is provably feasible as it can be implemented today in a somewhat awkward manner.