I don't think you need to worry about implementation being abstract, as far as the spec is clear and easy to remember. In some cases, showing a simple implementation conveys the idea clearly and precisely; in some other cases, a simple and clear spec needs a convoluted implementation just to cover pitfalls. The latter case doesn't need to be taken as a bad sign, imho.

Specializing to common cases is a valid argument. I prefer the consistency to the asymmetry, but opinions may differ. I just think ease of implementation shouldn't be a reason of reducing generality (except the case that there's no known way to implement the given spec efficiently.)

On Fri, Jul 28, 2017 at 10:23 PM, Panicz Maciej Godek <xxxxxx@gmail.com> wrote:

It makes me worried, because the implementation now became
very abstract, and it no longer conveys the intent: it doesn't tell
the reader how the "is" macro is meant to be used, which I think
is a big price to pay -- especially given that the behavior that it enables
is questionable and discouraged and unlikely to be used in practice:
I expect specialization of a single argument of a binary predicate
to be the most common use case, which in my view justifies
the irregular behavior.

It also prompts to consider another interpretation, where "is" would always
be returning a lambda, and so instead of (is x < y), one would need to
write ((is x < y)). I don't think there's any utility in such consistence,
but I'm mentioning it for consideration.
To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=KS2EzWX7QQ4xln4ryZkZneOEVSTjbbUb