2017-07-25 13:15 GMT+02:00 Shiro Kawai <xxxxxx@gmail.com>:
On Mon, Jul 24, 2017 at 11:15 PM, Panicz Maciej Godek <xxxxxx@gmail.com> wrote:

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

Don't take me that I'm forcing orthogonality as a dogma.  It's just a rule of thumb when there aren't other compelling reasons to do otherwise.  The srfi text in the current form isn't clear enough on such reasons (it does mention indirectly, when it says some of most common usage of cut is to specialize one of the arguments of binary predicates, under "SRFI 26 Notation for Specializing Parameters Without Currying".  You can put the usage frequency argument earlier.)

OK, I'll try to fix that
 


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.

It is not non-compatible.  It's a backward-compatible extension, for (cut is ...) is not allowed in the original srfi-26 (unless there's an implementation that extends srfi-26 in its own way to give (cut <syntactic-keyword> ...) a special meaning.)

I think it is problematic nevertheless: the fact that we need to revise old SRFIs to make them work shows that there is a problem with compositionality of the solution.
 
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.
 
By "syntax" I didn't specifically mean reader syntax, but also another layer of macro.  In srfi-26 discussion, for example, '&' or '_j' were suggested, e.g. (& is _ < x).   (Actually, using _ instead of <> was also discussed.)

I did trace the suggestions for using _ instead of <>, but I failed to find any rationale for preferring <> over _ -- neither in the SRFI itself,
nor in the discussion archive.
The problems with both _j and & is that their names really aren't helpful in understanding the code.
 
The good thing to have such syntax is that now if you prefer _ to <>, you can go with this new syntax without being limited to 'is' macro.  Coupling the sectioning notation with infix macro actually restricts the sectioning notation into special occasions.  Again, if you have compelling reasons to do so, it's ok.  I just haven't seen them yet.
 
My observation is that specializing binary predicates is one of the most common and useful applications of trivial specialization.
For non-trivial cases, Scheme already provides a nice operator for creating partially specialized functions, namely -- lambda.

I think the argument that you are trying to make also applies to SRFI-26: the DSL
for creating specialized functions allows, for example, to evaluate all arguments
before specialization (by using cute), and it does allow to delay evaluation of all
arguments to the moment of invocation (by using cut), but it doesn't allow you
to choose some arguments that are meant to be evaluated before specialization,
and leave the others unevaluated.

One could imagine that cut could treat, say, the "paste" keyword to force
evaluation before specialization, thus making this DSL complete, but in my view
this wouldn't be a good idea. I even think that providing "cute" isn't a good idea.

In my view, there is some utility in having infix syntax for binary predicates,
and having this syntax is a good occasion for handling specialization without
cluttering code with additional keywords. I don't think there's any utility in
writing (cut + <> 5) instead of (λ (x) (+ x 5)). I do think that there is some utility
in writing (is x < y) instead of (< x y), and I also think there is some utility
in writing (is _ < y) instead of (λ (x) (is x < y)).

However, this belief is not based on some a priori insight. Rather it is based
on empirical observation that specializing binary predicates is a common case
for trivial specialization.

It could also be tempting to allow the use cases such as (is (square _) < 2),
but since it is non-trivial, I believe it would better be handled with lambda.