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.