Revisit use of the name `pass`

[countvajhula]

pass is Qi's values equivalent of filter for lists. It was originally named for "low pass" "high pass" and "band pass" filters that are found in analog electronics, and so as to avoid colliding with the filter function which is frequently used within flows to operate on lists.

But for some time, the potential utility of the name pass to mean _ (the "pass through" flow) has been apparent. There is no English word that quite achieves the meaning of "pass" as simply as "pass" does. And python uses pass in a similar way, to indicate an expression that does nothing.

Almost all of Qi's core forms have a plain-English name even if they sometimes have a symbolic name. For instance, △ is sep, and ▽ is collect, -< is tee and >< is amp. But _ has no plain English name, and it feels as though it ought to be "pass." Having such a name would make it easy to talk about in documentation, where otherwise it is sometimes awkward to refer to the form simply as _ as it does not afford much versatility in phrasing. We'd like to refer to _ as the "pass-through flow," and have that correctly call to mind the pass form, rather than reinforce an invalid association with today's filter-like pass.

Although there don't seem to be many words other than pass that are appropriate here, on the other hand, for the existing use of "pass" as the filter form, there are some options, in particular allow. E.g. (allow positive?). In fact, this arguably reads better than (pass positive?), and also suggests the opposite, (exclude positive?).

Of course, if we did make this change, it would be backwards incompatible, and could be an annoying change to make. It's unusual to rename linguistic forms in this way. But it may be an investment in clarity worth making, and it could be a good proving ground for an automated migration scheme that we hope to offer to users for backwards incompatible changes in the future (see Designing for backwards incompatibility).

To follow a scheme suggested by @jackfirth, we could:

1. Release a version of Qi in which we introduce the new allow form as an alias for pass.
2. Encourage (e.g. via Resyntax suggestions) users to migrate uses of pass to allow.
3. Release the next version of Qi in which pass becomes identified with _.

[benknoble]

While I like allow/deny, have we considered calling _ the "identity" or "do-nothing" flow?

FWIW I think Python's pass is more like ground or void since it returns None.

[countvajhula]

Identity doesn't feel too bad on its own (and I think we do refer to it that way in our heads), but as a specialized term it feels unwieldy, esp. for non-math folks. For example:

(~> (1 2 3 4 5) (== identity
                    sqr
                    identity
                    identity
                    add1) +)

It also collides with Racket's identity but has slightly different behavior (i.e. values), and that could be confusing.

That's true re: pass in python, it's not quite the same.

"do-nothing" flow, usable but also unwieldy and doesn't suggest a simple form name. Would be ideal for it to be a verb.

Another possibility is to use uppercase PASS, the same way and (predicate) and AND (boolean gate) are different in Qi.

One useful thing about changing pass itself is that it would be a convenient and relatively challenging proving ground for our backwards compatibility model, including providing parsers to automatically migrate code, etc. -- not that that's a good reason on its own of course.