Minor comments on SRFI 128
Sudarshan S Chawathe
(27 Oct 2015 00:57 UTC)
|
Re: Minor comments on SRFI 128 John Cowan (27 Oct 2015 02:19 UTC)
|
Re: Minor comments on SRFI 128 John Cowan 27 Oct 2015 02:19 UTC
Sudarshan S Chawathe scripsit: > I found SRFI 128 interesting. Here are some minor comments based on a > quick reading of Draft #1 (2015/10/26). Caveat: I have not caught up > with the discussion of SRFI 114, which is obviously relevant. The intention is that SRFI 128 should be clear without reference to SRFI 114, so that it can replace it. > * There is a partial sentence at the end of the second paragraph of > the Rationale section. Fixed. > * There is an extra "p>" at the beginning of the Specification > section. Fixed. > * For the comparator returned by make-pair-comparator: It is > probably obvious, but is it correct that the returned comparator > implements equality as conjunction of car and cdr equality predicates, Yes, that's correct (and implied, I think). > and similarly for the type-test? This is a genuine issue that hasn't been raised. Historically the type test for a container data type has looked only at the container: thus, it verifies that a vector is a vector, not that it is (for example) a vector containing numbers. If it did the latter, the type test would imply recursing all the way down. I'll add this to the issues: it applies equally to list-comparator and vector-comparator. > * I believe that the text uses "result of that comparison" (e.g., in > the description o make-list-comparator) to denote the result of the > ordering predicate. If true, using "result of the ordering predicate" > may be clearer. > > * An observation similar to the above also applies to > make-vector-comparator. I use "comparison" to refer to both the equality and the ordering predicate, which must be consistent and must represent a total order. > * Missing space in "functinonumber-hash" (7th item in > make-default-comparator's description). Fixed. > * In the "Comparison predicates" section: I think the intent is > clear, but the description does not explicitly refer to the equality > and ordering predicates of 'comparator' and uses 'comparison > procedure' instead. Left over from SRFI 114. Fixed. > * Earlier (in Constructors), is the note "..., since comparators are > pure and functional". Is it true that the bundled procedures are > therefore explicitly prohibited from causing side effects? A more > explicit statement either way would be useful. I did not intend that, but it's a good idea. Added. -- John Cowan http://www.ccil.org/~cowan xxxxxx@ccil.org So they play that [tune] on their fascist banjos, eh? --Great-Souled Sam