On Tue, Jul 11, 2017 at 3:55 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

I would like to make a couple of remarks that came to my mind when I
first read your proposal. In no particular order:

I agree with Marc's points 1, 2, and 4.

For point 3, SRFI 26 leaves <> unbound, whereas this SRFI should bind _. We can go with _ and bind it to a syntax-error, but if we want to use <> we need to update SRFI 26.

If "_" is used, it should not be bound by this SRFI to a new transformer but should imported and reexported from (scheme base), so that "(import (scheme base) (srfi 156))" works (and would detect if the meaning of "_" in the importing program is different from either the meaning of "_" in (scheme base) or (srfi 156)).

Point 6 is really out of scope. The rationale for SRFIs is to put forth ideas that people may wish to use. The down side of extensible syntax is that if you don't know what the macro means, you can't understand code that uses it, but that's a price we (usually) gladly pay in Scheme. It's too much to ask a SRFI author to predict whether a new feature will become popular.

That's true. I was just wondering about a compelling reason for many to use this new syntax.

I think you should ask the many.

My thinking is that perhaps there is something about programmers trying to add some infix syntax to Lisp every now and then,

but so far people have been focusing on arithmetics rather than logic.

8) It seems clear to me that (is _ related-to? _) should simply mean `related-to?`. When _ is used as a place holder, it is always assumed that it might mean different things in different places. The interpretation (lambda (_) (related-to? _ _)) violates this assumption.

I agree with this point. This is also more consistent with the use of "<>" in SRFI 26. The whole use of "_" as a placeholder, however, is not consistent with the prior use of "_" in the R7RS, where it does not bind any variables but ignores arguments. (Which would speak for "<>" of SRFI 26.)

I think the contrary: the fact that "_" is usually used as a non-binding symbol minimizes the risk of naming conflicts.

One more point:

9) While the addition of "isnt" is nice, having another primitive to turn the arguments around can also be very helpful. So "(isnt x < y)" is "(is x >= y)". Do you have an idea for naming a syntax S such that "(S x < y)" is (is x > y)", that is "(is y < x)"?

Actually (isnt x < y) is not (is x >= y), but rather (not (is x < y))

(the fact that what you wrote happens to be true is a semantic claim, but "is" is a purely syntactic combiner).

I'm afraid that comming up with a combiner (S x R y) that would map to (R y x) would actually be harmful,

as it would undermine the conventional roles that SRFI-156 is trying to emphasize.