[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
general comments re SRFI-114
- To: srfi-114@xxxxxxxxxxxxxxxxx
- Subject: general comments re SRFI-114
- From: David Banks <amoebae@xxxxxxxxx>
- Date: Thu, 4 Jul 2013 23:42:47 +0100
- Delivered-to: srfi-114@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=it8EOPJQy/F0XfytNs2cwbud5UKJlYwgtTaJ9avCy2E=; b=Vz60ZsIINVyHxVNgJ6aRmu039EaAohSaNTZkIMeGBNoKmDw5Kaz/9CEtnBp0mi8kQF MymGJd/aSdYPgZZPrjkoG+3oupMeQX2pjnntPhE/iain4g2NyzSqrSYdYS0hQCXXrw4S lNQhDVOq8c+e3EP19mNj0ksYonQgzmbfLv7ESC6QdPBgpks6xXi+q5q42B5GR9iTxXZi zVYQMfC6DmLrnDB3PUHcvqwqhTWb2jLmbeCUvAl2sn0notJDy0KTbg9XBSan34Gt2zOx 5XTQw6qcZx/C3a+Uu1KqIZDsU32TIdlJzVWQmS+Tt9aKTHy3K915229MHpZyYyqsHKHf 990g==
Overall this is an amazingly rich API and I look forward to using it
when it is standardized. I hadn't ever clocked the existence of the
previous SRFI, so this is a nice surprise.
A few miscellaneous comments:
I find it strange initially that I'm forced to specify the various
arguments for 'make-inexact-comparator'. I would like to have
optional arguments that simply use the default behaviour of the =
operator (for instance) if I don't specify the argument for 'epsilon'.
I guess the intention is that if I want a less specific behaviour I
can use the numeric comparators under the 'Standard atomic
comparators' section, or 'default-comparator'.
Why not let the user specify the actual rounding procedure to use for
the rounding parameter of 'make-inexact-comparator', instead of using
a symbol? Performance?
I don't really see the need for the procedures under 'Primitive
applicators'. They are just sugar, I guess, unless the results of the
accessor procedures are intended to be totally opaque. (except for
comparator-check-type which has additional semantics). i.e. can the
semantics of (comparator-hash comparator obj) differ from
((comparator-hash-function comparator) obj) in any way?
I'm a little worried that the binary comparison predicates look too
similar to the existing base comparison predicates. (=? c x y) is
fairly visually similar to (= c x y).
Also not sure of the use case for allowing ((=? cmp) x y) as part of
the same procedure, I see that this is useful for expressions like (<?
cmp) where the resulting procedure is not identical to the result of
'comparator-compare-procedure', but maybe bundling this neat currying
behaviour under general comparison is muddying the waters.
David Banks <amoebae@xxxxxxxxx>