Is GROUP! in PATH! for function invocations worth it?

Back in the day, I thought it would be neat to allow you to put GROUP!s in paths. So you could do things like this:

append/(if condition ['only]) [a b c] [d e]

It turned out to be of fairly limited use. Really you could only use it with refinements that didn't take parameters, because it changes the "shape" of the execution stream. Consider how you would make the following sensible:

append/(if condition ['dup]) [a b c] [d e] ???

When the condition is true you want something in the ??? spot. When it's false you don't. How can your code cover both cases?

We actually have some tools these days that could use opportunistic invisibility to solve this. But then you're testing the condition twice, and getting involved in some pretty wild mechanics for something trivial.

It also raised a lot of annoying questions about NULL/blank tolerance. I didn't like NULL being allowed in the generic pathing, but it was ugly to require BLANK! for this task:

append/(try if condition ['only]) [a b c] [d e]

append/(if condition ['only] else [_]) [a b c] [d e]

Now we have a modern APPLY

It bends some of the raw frame rules, and lets you use LOGIC! for parameterless refinements:

apply :append [[a b c] [d e] /only condition]

It's a bit longer. And we haven't really firmed up questions like whether you need the GET-WORD! or if it's soft quoted by default. Or if there might be some clever shorthand:

($ append [a b c] [d e] /only condition)

I'm In A Mood To Kill Off Lesser-Loved Features :hocho:

All things being equal, it might seem nice to support. But every feature has a cost!

You'd still be able to put GROUP!s in paths for your own purposes, but refinement dispatch in functions wouldn't use it.

You could also use DO of COMPOSE'd code if you really wanted to:

do compose/deep [
    append/(if condition ['only]) [a b c] [d e]
]

So if anyone has a good argument for keeping the function dispatch behavior, speak up now!

2 Likes

I wrote a short hack of a compatibility-APPLY for bootstrap, and changed all the GROUP!-in-PATH! cases for refinements to use APPLY.

It's just better, in most of these cases.

But...An Argument For Keeping It

When you think about dialects like UPARSE, they don't have an APPLY operator out of the box.

Being able to leverage the evaluative tool could be helpful, to someone who is running a GET on the PATH! and wanting a function back with the proper specialization. :-/

I'll let it stick around for now, for that reason. But let's try to avoid using it, and give APPLY some exercise.

2 Likes