Comments on SRFI 128 Draft 5 (2015-11-08). Sudarshan S Chawathe (09 Nov 2015 16:35 UTC)
Re: Comments on SRFI 128 Draft 5 (2015-11-08). John Cowan (09 Nov 2015 17:37 UTC)
Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). Sudarshan S Chawathe (09 Nov 2015 22:09 UTC)
Re: Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). Sudarshan S Chawathe (10 Nov 2015 15:05 UTC)
Re: Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). taylanbayirli@xxxxxx (10 Nov 2015 15:14 UTC)
Re: Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). Sudarshan S Chawathe (10 Nov 2015 16:03 UTC)
Re: Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). taylanbayirli@xxxxxx (10 Nov 2015 16:57 UTC)
Re: Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). taylanbayirli@xxxxxx (10 Nov 2015 20:40 UTC)
Re: Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). Sudarshan S Chawathe (10 Nov 2015 21:16 UTC)
Re: Partial orders. Re: Comments on SRFI 128 Draft 5 (2015-11-08). Sudarshan S Chawathe (10 Nov 2015 21:17 UTC)

Re: Comments on SRFI 128 Draft 5 (2015-11-08). John Cowan 09 Nov 2015 17:37 UTC

Sudarshan S Chawathe scripsit:

>   * Would it be desirable to relax the restrictions noted under
>     Limitations for comparators created using programmer-defined
>     type-tests, equality and ordering predicates, and hash function?

Only if you don't object to various routines malfunctioning.  If
equality is not transitive, for example, then =? won't necessarily
do what you expect based on your experience of =, string=?, etc.

From here on, if I don't mention a comment I have accepted it and
will add it.

>   * Are comparators that reflect a partial ordering of objects
>     permitted?  The definition of ordering predicate seems to permit it.

The programmer responsibilities rule that out.  If a < b, then it's
forbidden for b < a, by the definition of mathematical asymmetry.

>   * hash function definition: Even though using it is optional, what
>     is the expected interpretation of the second argument as upper
>     bound: inclusive or exclusive?  I would guess the latter based on
>     common convention, but a clarification would be helpful.

Exclusive.  I'll make the next draft say so.

>
>   * comparator-register-default!: What is the behavior if this
>     procedure is used to register two comparators, both of whose type
>     test predicates return true for some objects?

Unpredictable.  I'll say so.

>   * (very minor) Beginning of Specification: I don't understand the
>     significance of the choice of the (comparators) library name
>     instead of (srfi 128), beyond what is stated there.  (I realize
>     this may change when the sample implementation is added/updated.)

Not much, really.  Development convenience for me.  That sentence really
should be in the implementation section, as SRFIs as such do not (or at
least I think they should not) assume a particular library system.

>     In particular, is it true that a horrible hash function that always
>     returns 0 is always technically correct?

Yes.  Indeed, the sample implementation I'm writing can do no better
on procedures and ports.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
LEAR: Dost thou call me fool, boy?
FOOL: All thy other titles thou hast given away:
That thou wast born with.