2017-07-25 10:42 GMT+02:00 Shiro Kawai <xxxxxx@gmail.com>:

I do use "cute" time to time. Just grepped a bunch of my source tree to find about a few dozens of uses.
But I agree that having two variations of 'is' in a sense of cut/cute seems too much.

What I'm thinking of is this: Currently, 'is' macro has two functions, namely rearranging infix operators and shorthand of creating a closure, which are orthogonal to each other. Conflating orthogonal features doesn't seem a good idea. Every time a new macro that has additional function of the latter, we would go into the same discussion of cut/cute semantics, which symbol to use for placeholder, etc.

Instead, can we split those two orthogonal functions? So that the latter function is solved once and for all.

I've recently watched a talk by Larry Wall, where he claimed that it is typical
for natural languages to have more irregularities in the most commonly used domains.

Even the language of mathematics has a lot of irregularities. For example,
in mathematics it is completely OK to say "x < y < z" to mean "x < y and y < z",

which is an exception from the normal interpretation rules for operators.

Likewise, I think that currying binary predicates is a particularly common use
case, and as such it makes the special treatment of underscore inside the "is"
form acceptable.

That said, I think you could point to some examples of unorthogonal features
that are already present in Scheme -- for example, the named-let loops, or the
"=>" syntax in the "cond" clauses, or even the "else" keyword of the "cond"

clauses

One way is to define an extension of srfi-26. It only allows <slot-or-expr> in the arguments, so we can't combine it with macros such as 'is'. But the restriction is because of difficulty of coming up a complete general semantics of allowing syntactic keywords in its arguments. It doesn't prevent to define an extension that allows *limited* use of syntactic keywords, e.g. we can define semantics of (cut is ...) or (cute is ...) specifically.

I think this idea is similar to infix definitions that I consciously rejected in SRFI-156.

Making a penetrating non-compatible change in the existing language and practices

is something that I prefer to avoid.

In case if you don't like '<>' as the placeholder, you can delve into yet another sectioning syntax, e.g. Clojure-esque #(is _ < x) etc. In that case, however, I feel it is better to have a separate srfi.

Actually, I prefer not to propose any additional reader syntax when this isn't strictly necessary.

I also understand the reluctance of replacing <> with _. I am myself not a huge fan of SRFI-26,

and my worry is that <> has had a definite and sensible meaning outside of the Scheme community
long before SRFI-26 was announced. The thing with underscore is that it is never likely to have

any definite meaning -- it may refer to something that is ignored or omitted (syntax-rules, for example,

use it in the former case, and SRFI-156 -- in the latter). Since the conflict between ignoring and

omitting is rather unlikely, I believe this is the right choice.