2017-07-29 10:39 GMT+02:00 Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>:
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:

As syntax-rules macros usually have to be written in convoluted ways, I don't think one should every take them as a definition of a new concept.
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.

(is _ < x < _) looks like a sensible application. It is a procedure of two arguments, say a and b, and returns #t if the interval [a, b] encloses x.

OK, I'm buying that :)

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.

For consistency, I think it is very imported that the "is" macro does behave regularly. Either it should always return a procedure or never.

The same argument could apply to cond. One could say that it should
either take expressions, or functions, but not both.
Yet it allows to use both.

Personally I wouldn't mind writing ((is x < y)) too much, but I don't see
any value in this consistency either (just as I sometimes find it useful
to invoke cond with the => operator).

Or, to put it another way, "is" is meant to be a feature that isn't driven
by semantics, but pragmatics (just as cond with expressions -- technically
you could always pass it lambdas; this wouldn't change their expressiveness,
but would make them more cumbersome to use).

Another problem with treating (is x < y) as a thunk rather than application
is that it creates a psychological barrier, because it may create additional
execution overhead.
If you don't want to write ((is x < y)), I suggest to use two different syntaxes. (E.g., as previously suggested, (cute is ...) for the procedure case.

My personal opinion is that (cute is ...) is just terrible. "is" alone
adds enough weirdness to the interpretation of the language.
In my view, the problem with cut and cute is that they're
a crippled replacement for lambda -- they ineptly try to be
a general mechanism for specializing functions; they do not
take into consideration the way the language is actually used.

"is" on the other hand does not try to be a general mechanism,
or provide a general mechanism for specialization. It recognizes
that there is something particular about binary predicates, and that
specialization of binary predicates deserves separate attention.

As I said earlier, I don't see a particular advantage of writing
(cut + <> 1) instead of (λ (x) (+ x 1)) [but I do see some disadvantages].

I made some experiments with the function "partial" borrowed from
Clojure, which performs Haskell-style currying:

(define ((partial function . bound-args) . free-args)
  (apply function (append bound-args free-args)))

It is perhaps slightly less terrible than cut, but I've found that the
code written using it is much more obscure than using explicit
lambdas (because naming your argument allows to document
your code better)

Compare, for example

(filter (partial < 5) numbers)
(filter (is 5 < _) numbers)
(filter (cut < 5 <>) numbers)
(filter (λ (x) (< 5 x)) numbers)

My claim is that the variants using cut and partial are more difficult
to comprehend than the remaining ones, and the variant using "is"
is least confusing (however, my bet is that in real life it would be
more likely written as (filter (is _ >= 5) numbers)).

Back to the ((is x < y)) issue, given that < is a pure function,
there is no notational advantage over (is x < y): there is no
reason for anyone to write such an expression. If < is not a pure
function, that is beyond the scope of SRFI-156, and I would find
it less confusing without "is".

The only practical value of ((is x < y)) is that it perhaps reminds
the readers that "is" can also be used for creating lambdas, which
in my view shouldn't really be necessary.