On 1 Sep 2021, at 09:53, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

> Dear Daphne,
>
> thanks for writing this SRFI! I like it!
>
> Here are a few comments:
>
> (1) The second procedure has the same name as the first "make-wrapper-comparator".  I think the second one should have gotten a different name, probably "make-composed-comparator".

Oops, that's an error. It should indeed be called make-composed-comparator. Thanks!

> (2) In the compose-comparator form, it would help a lot if you use the standard way of describing syntax (see the R6RS or R7RS document):
>
> Syntax: (compose-comparator <type-test-expression> (<unwrap-expression> <comparator-expression>) ...)
>
> Semantics: <Type-test-expression>, the <unwrap-expression> and <comparator-expressions> are evaluated in an unspecified order.  It is an error if the resulting value of ... etc... blabla...

Yes, I agree. I’ll revise it as such. I’m also unsure whether compose-comparator should even be syntax in the first place though. It’s a convenience around make-wrapper-comparator and make-composed-comparator, but I’m not sure it’s so convenient that it actually needs to be in the SRFI.

> (3) There are other procedures with a lot of return values, see SRFI 137, for example.  Keyword arguments are not really necessary thanks to Scheme's macros.  Make "comparison-procedures" syntax of the form
>
> (comparison-procedures <comparator-expr> <cmp-identifier> ...)
>
> Syntax: Each <cmp-identifier> is one of the identifiers "<", "<=", "=", ">=", ">".
>
> Semantics: Evaluates <comparator-expr> to obtain a comparator.  Returns as much values as there are <cmp-identifiers>.  The return value corresponding to "<" ("<=", "=", ">=", ">", respectively) is the partial application of the SRFI 128 procedure "<?" ("<=?", ..., respectively) to the obtained comparator.

Hmm. That would mean making <, <=, =, >=, and > auxiliary syntax keywords though, wouldn’t it? Wouldn't that interfere with their use as the names of the numeric comparison procedures? (Here I probably reveal again my weak understanding of how identifier comparison actually works in macro-expansion pattern matching …)

Or by putting double-quotes around them do you mean that they should be literal strings, rather than symbols? That would avoid that issue (if it is indeed an issue), but would be rather un-Scheme-y, imo.

I’m also not particularly happy about the idea of having a syntactic form with no procedural counterpart. Perhaps rather something like the following, implemented in terms of the current comparison-procedures procedure:

(define-comparison-procedures my-date-comparator
  (date<? <)
  (date<=? <)
  …)
and so on.

I’ll give it some thought.

> (4) Can you give a rationale why "comparison-procedures" is a useful abstraction when compared with a version that returns the comparators individually?

I don't understand what you mean by ‘returns the comparators individually’. Could you explain?

> (5) Can you explain your idea about generator comparators?  Generators are generally "use-once" data types and infinite, so how is this supposed to work?

You give it the type test for a data structure and tell it how to convert from that data structure into a generator.
So (make-generator-comparator list? list->generator the-comparator-for-the-individual-items).

But when I mentioned this idea in #scheme in the pre-SRFI stage, consensus seemed to be that the existing make-list-comparator etc. procedures are sufficient. So I might just scrap the idea.

> Thanks,
>
> Marc

Daphne