Historically it is not possible to dispatch infix functions from a path. In Ren-C it's very nearly technically possible, with one problem: so long as PATH! can contain a GROUP!, it can't be "sniffed" for whether it looks up to an infix function without potentially having side effects.
Consider, for example:
do/next [1 foo/(print "Hi" 'bar) 2]
Let's say we want to think that if foo/bar looks up to something like infix addition, that should print "Hi" and be 3. If it is some prefix arity one function, it should print nothing and return 1.
The evaluator isn't designed to be able to predict the future in this way; you can't find out what foo/(print "Hi" 'bar) will look up to without evaluating the GROUP!. You don't want pure lookahead to have side effects. And really this is the technical dilemma in having paths dispatch enfixed functions.
One possibility I've suggested is to disallow GROUP! under DO in paths unless you use a GET-PATH! or SET-PATH!. Since a GET-PATH! cannot dispatch a function, the problem goes away. If you needed function dispatch you could still get it with EVAL:
do/next [1 eval :foo/(print "Hi" 'bar) 2]
But since there's only one FUNCTION! type and its only variables that hold enfixedness, that would not be enfix.
Note: We could have an
envaloperation (possibly bad name), which is an enfixed variadic, and would gather its left hand argument and then use its first right hand argument to determine how to interpret its parameters...effectively letting you signal an enfix execution. e.g.1 enval :add 2=> 3
So how bad would it be if you could not--in the DO dialect--use a GROUP! in a path unless it was a GET-PATH! or SET-PATH!? Is it worth it to allow a regular PATH! to honor the enfix bit of its target?