Right Literal Args vs. Left Literal Args... Fight!

Well, so much for that, it no longer applies because...

Branches Are Now "Hard Literal" (for good reasons)

:thinking:

This doesn't necessarily mean the feature needs to be thrown out.

But the argument for having some weird edge case in the system is greatly diminished.

The Feature Deviates @arg and @(arg) w.r.t. Infix

My impulse is to kill the feature specifically because it seems like it gives you an unintended consequence when you change a literal argument between being escapable and not.

You might think "oh, it took arguments literally before and didn't take GROUP!s as a legal type. I changed it to take escapable literals and so this should not make any difference to the code until I add groups."

But if there's this other behavior then that's not true. Suddenly it's injecting evaluator sublevels for literal arguments to do infix "lookback".

Also, this is a performance hit. It's better if you just take the slot literally in step one, and then evaluate the group in step two, and consider yourself done.

At Least Three Strikes, And I Think It's Out

  • No Longer Has Any Use Cases I Know Of
  • Creates Undesirable Deviations Between Literal And Literal Escapable Args
  • Slower and More Complex Code

This thread can serve as a memory of what the feature did. And maybe some super-compelling case to resurrect it will come along someday. But when it's resurrected, it should probably be its own special weird parameter flag, instead of being implied merely by the escapability of a literal parameter.

Here Was A Comment on What's Being Deleted...

:bomb:

// Left literals from the right already "win" over rightward literals,
// in a case like `help grab-left` where they point at teach other.
// But there's also an issue where something sits between quoting
// constructs like the `x` in between the `else` and `->`:
//
//     if condition [...] else x -> [...]
//
// Here the neutral `x` is meant to be a left argument to the lambda,
// producing the effect of:
//
//     if condition [...] else (x -> [...])
//
// To get this effect, we need a different kind of deferment that
// hops over a unit of material.  Soft literals are unique in that they
// mean we can do that hop over exactly one unit without breaking
// the evaluator mechanics of feeding one element at a time with
// "no takebacks".
//
// First, we cache the literal argument into the frame slot.  This is
// the common case of what is desired.  But if we advance the feed and
// notice a literal infix construct afterward looking left, we call
// into a nested evaluator before finishing the operation.