Hi,

sorry for the delay and a little mess in threads, but I wasn't subscribed to the mailing list and didn't get a notification.

Hi,

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

1) The SRFI says that "(is x < y <= z)" is syntactic sugar for "(and (<
x y) (<= y z)". However, it should be syntactic sugar for "(let ((%y y))
(and (< x %y) (<= %y z)))" because evaluating "y" may have side effects
(or just be costly). In case of the former expansion, "(is x < y < z)"
would be something different than "(< x y z)".

Good point. I'll fix that in the next revision.

2) As for the "pronounciation" of "(< x y)" and so on: It is in the
report in 6.2. The report talks about (a list of) "monotonically
increasing" numbers. This makes very much sense because "<" is not a
binary predicate but an n-ary predicate for any n greater or equal 2.

I am aware of this. One can read (< x y z) as "x, y and z form an ascending sequence",
but the "<" sign is generally pronounced as "less than", which is confusing in the prefix syntax

On the other hand, I agree that it is less obvious for a predicate like
"divides?" (although it makes as much sense as for "<" to make
"divides?" an n-ary predicate because, mathematically, "divides?"
defines just another (non-total) order).

However, "(is x divides? y)" doesn't follow the English grammar rules.
One would first have to redefine "divides?" to, say, "divisor-of".

Yes. I expect this macro to impact the way people come up with the names for their predicates.

3) For consistency, it would be nice if SRFI 26 and this SRFI use the
same placeholder, so either "<>" or "_". If people agreed on "_", we
would need another SRFI amending SRFI 26 (and SRFI 148, which reuses
SRFI 26's identifiers for consistency). In the latter case, one would
have to cope with the identifier "<...>" of SRFI 26 as well. One
possibility would be to use ". _" (because "<...>" only appears as the
last element in a list in SRFI 26).

I agree that this may seem controversial. It's hard to go beyond the point of personal preference here.

I personally don't find the SRFI-26 macro particularly compelling.

4) Being a mathematician, I don't understand why "(is _ < x < y)" is
allowed, while "(is x < y < _)" is not allowed It seems like an
artificial restriction complicating the spec (while the implementation
would still be straight-forward).

(is _ < x < y) is allowed, but it is bad programming style: within the scope of this expression,

(< x y) already has a definite value which doesn't have to be evaluated every time the function

is called.

If you think that it is possible to provide a straightforward implementation for underscore

in any position, I'd be eager to see it

5) From a user's point of view, "(is _ + 1)" looks like a valid use
case. I understand why you discourage its use, namely because the word
"is" simply does not make sense with respect to addition. Why don't you
use an otherwise unused symbol? E.g. "$"? Then writing "($ x < y)", "($
x taller-than? y)", "($ x divides? y)", "($ _ + y)" each makes a lot of
sense. (I don't want to say that "$" is a particularly good choice;
consider it as a meta-identifier for the moment.)

Because this SRFI is intended to work with binary predicates. I quite intentionally made a distinction

between binary predicates and infix arithmetic syntax, because I believe that in the case of the

former, having infix syntax isn't a sheer whim. Of course, it doesn't matter when your predicates

are symmetrical -- for example, it doesn't matter whether you write (equal? x y) or (equal? y x),

because they both mean the same thing.

So what I want to say is that one of Scheme's selling points is that its
primitives are very orthogonal and the few concepts it provides are not
unnecessarily restricted. Now, SRFI 156 seems to restrict its own
applicability for natural language reasons. There should be a solution
to this problem.

I agree with you. In a way it does seem strangely restricted, and I think it has to be shipped

with some guidelines with regard to the way it is intended to be used.

6) Does this SRFI provide enough reasons for people to switch from "(< 1
2)" to "(is 1 < 2)"? If not, Scheme code would possibly become harder to
read because one will have to know both conventions when studying other
people's source codes.

This is a good question, but I'm afraid answering it is beyond my capabilities.

I can only say from my experience that:

- it does make the conventional order of arguments to binary predicates something more than sheer convention

- the optional ability of currying first and second argument has been very useful in practice

I do agree that the fact that one needs to know that (is x < y) is the same as (< x y) can be an obstacle

for learning. On the other hand, I think this is not very different from the let and let* forms.

Let me give two examples to demonstrate my point: Scheme has the
named-let and the do-construct as the primary means to write loops.
Do-loops are easily rewritten into named-let-loops. However, they add a
bit of meaning. A do-loop (with a non-trivial body) is an imperative
construct, which I can so mark in my Scheme code. At the moment, I don't
see any meaning that is added when using the "is" form proposed in this
SRFI (as much I don't see any meaning added when using the square
brackets of the R6RS as opposed to the round brackets).

With regard to square brackets, I can only say that I've found them helpful when writing

my master thesis, because I could use them to typographically mark certain expressions

that I could refer to in the text, while still having a valid piece of code. But I agree that it

is problematic that it may cause unnecessary entropy in the Scheme code base.

However, I don't see any benefits whatsoever of having the "do" loop in Scheme

(as well as case expressions, and even named lets for that matter)

The syntactic sugar "(define (f x) ...)" for "(define f (lambda (x)
...))" does not add any meaning, but it shortens the code, so people use
it (somewhat) consistently.

I think that the value of the syntactic sugar for "define" in Scheme is that it makes it

clearer that, say, when you (define (square x) (* x x)), it actually means that, say,

(square 5) is (* 5 5).

P.S.: I am willing to help you with the sample implementation if you
want to incorporate some of my suggestions (e.g. "_" is position 3 or
later, or to code the "let"-wrappers) and if you don't like macro
programming too much (or take a look at SRFI 148, which makes
programming or powerful macros very easy).

I think can deal with "let" wrappers rather easily, but I'd love to see a straightforward

solution for "_" in position 3 or later (I have an idea how to do this with syntax-rules,

but it would require an auxiliary macro to decide whether the "_" symbol appears
anywhere in the expression. It's not very complex, but I'm not sure whether it is

actually worth it)