Refinement Arguments at Head of Args List, Not Tail

[hostilefork]

@hostilefork

In many languages, you would write APPEND-DUP-PART as the "maximally configurable" core function with a bunch of arguments. Then you'd make specializations like APPEND-DUP call that function with a default, and probably APPEND in turn by calling APPEND-DUP with a default DUP of 1, etc.

Advantages that come to mind of the refinement approach over this are:

1. You don't have to remember the order of the optional parameters, you just have to remember their names, and you use them in any order (so long as you make your usage order match).
2. One entry point for documentation, and that entry point is the "natural" name of the function where you have discoverability of what the options are.
3. No need to write out the awkward cascade of specializations.

So at least three good things.

Sacrificing (1) might seem harsh...

But there was also resistance to getting rid of multi-argument refinements.

And I think what we learned in general from that was that multi-argument refinements were basically irrelevant. When that was dropped, the system could move ahead by leaps and bounds in terms of FRAME! mechanics and function specialization/composition.

Along those same lines, I think fretting over the sacred cows of overlong refinement-based function call syntax is a big distraction compared to what empowering dialects has to bring to the table.

e.g. it is rather rare to invoke a function with more than one refinement. And if you really are using multiple refinements (with arguments), the more likely you're dealing with a call that's going to be spanning multiple lines. That's where the added boilerplate of APPLY is a benefit and not a drawback... which will also give you the opportunity to pick your ordering.

I'd actually imagine that code quality would improve if there was a rule saying "only one refinement can be used in a CHAIN!-based call, otherwise you have to use APPLY". Not that such a rule needs to be made, but if you only use one refinement unless you apply you worry less about the order.

This is kind of like saying that if you have lots of refinements that might be used together, you're probably doing something that would be better exposed as a dialect. But APPLY is just a way of slipping into that dialected mode.

@hostilefork

It still lets you add the refinements after the fact, and you shouldn't get bitten by any callsites that mix and match refinements that haven't been used together before.

This is a crucial bit. You can add optional parameters to a function and it won't disrupt existing calls. Anything that lined up before will keep lining up.