Email list hosting service & mailing list manager

A couple of remarks Marc Nieper-Wißkirchen (11 Jul 2017 19:55 UTC)
Re: A couple of remarks John Cowan (11 Jul 2017 20:14 UTC)
Re: A couple of remarks Marc Nieper-Wißkirchen (11 Jul 2017 20:32 UTC)

A couple of remarks Marc Nieper-Wißkirchen 11 Jul 2017 19:55 UTC

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)".

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.

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".

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).

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).

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.)

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.

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.

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).

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.

--

Marc

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).