[scheme-reports-wg1] John Cowan's votes on the sixth ballot John Cowan (12 Jul 2012 22:09 UTC)
|
Re: [scheme-reports-wg1] John Cowan's votes on the sixth ballot
Alex Shinn
(13 Jul 2012 03:07 UTC)
|
I'm posting these so that if anyone wants to try to change my mind before the end of the month, they have plenty of opportunity to do so. For context, see http://trac.sacrideo.us/wg/wiki/WG1BallotCowan . #460 Semantics of `eqv?` Preferences: r6rs/all, r6rs Rationale: On systems where `0.0` and `-0.0` are mathematically distinct, they should be distinct in the sense of `eqv?` as well. #229 eqv? and NaN #423. Preferences: unspecified Rationale: This is a marginal case which is not worth prescribing. I would have preferred all NaNs to be `eqv?` to each other, but that's probably not achievable. #125 Allow procedures not to be locations (making EQV? unspecified in some additional cases) Preferences: yes Rationale: Although this means that procedures aren't quite first-class (you can't reliably use `memv` to determine if a procedure can be found in a list), I think we don't want to renege on the license to return `#f` that R6RS provided and that optimizing compilers exploit. #393 Defining record equality Preferences: unspecified Rationale: Existing systems shouldn't have to change their `equal?` to conform to R7RS. What's more, record equality is `eqv?` on some systems by default and not on others. #306 What does "full Unicode" support mean in Appendix B? Preferences: at-least-6 Rationale: Requiring the latest major version is reasonable, since R7RS will require at least a refresher release for almost all implementations that adopt it, but there's no reason to huff and pant to keep up with the latest minor version. #458 Remove the formal semantics from the report Preferences: remove Rationale: The formal semantics are broken as written, and even if we patched it up, it would still be less than helpful. We need to let a separate group do a better job. #398 Allow repeated keys in `case` Preferences: leftmost, r6rs Rationale: `Leftmost` is a reasonable compromise between R5RS and R6RS; the latter overspecifies the mechanism. #85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else? Preferences: blob, bytevector Rationale: Neither `bytevector` nor `u8vector` fully captures the idea here, which is of a collection of unstructured binary information. `Blob` does that nicely. Failing that, at least there is R6RS as precedent for using `bytevector` in this vague way. #353 No use before import in libraries Preferences: yes Rationale: This is how Chicken works, and I think left-to-right processing is a Good Thing whenever possible. Note that this has nothing to do with the fact that the library form is read all at once, and everything to do with how it is processed. #359 Limit numbers used in library names Preferences: uint15, int16, uint16, int24, uint24 Rationale: I may change this later when/if Alex explains why negative numbers are useful in library names. We haven't had them up to now. #441 Make sure a program/library loads any imported libraries at most once Preferences: yes Rationale: This is not a case R6RS deals with, but I think it's sensible to require all imports from the foo library into the bar library to come from the same instantiation. #402 Add an export-all form. Preferences: yes Rationale: I think this is very useful for reducing bureaucracy in small libraries. Chicken has it. #448 Add library declaration include-library-declarations Preferences: include-library-declarations Rationale: Though this name is verbose even by Scheme standards, what it provides is very helpful. In simple implementations, it can be the same as include. #449 Clarify library loading rules Preferences: zero-or-more Rationale: I think we should defer to R6RS-based experience here. Those who don't care much can probably live with any of these options, but those who care seem to be passionate about it. #366 Add (log z b) for logarithm of z to the base b Preferences: yes Rationale: This is easy for both users and implementers, but implementers should do it once so users don't have to do it more than once (as well as remembering the order of terms in the division!) #367 Inexact division by exact zero Preferences: error Rationale: The zero is exact and that is what causes the error -- the other arguments are not relevant. #369 Require that - and / allow an arbitrary number of arguments Preferences: required Rationale: It's silly for `(- 1 2 3)` not to Just Work in all Schemes. #370 Log of exact and inexact zero Preferences: r6rs Rationale: R6RS got it right here: the limit of log ''x'' as ''x'' -> 0 is negative infinity, which however is not representable within the exact number system. #407 Dividing exact 0 by an inexact number Preferences: zero, no-nan Rationale: Returning an exact value is good, but propagating NaN is good too. As I've posted, I don't think the NaN exception to the exception is worth fussing about, since it's all optional. #410 Infinity vs. NaN in max and min Preferences: both, unspecified Rationale: If we are going to allow both (as I think we should and must, the arguments on both sides being equally satisfactory), we should say so. #395 Infinite and NaN complex numbers Preferences: overlap Rationale: I don't really care about the R6RS notion that `finite?`, `infinite?`, and `nan?` form a partition (and in R6RS they don't work on complex numbers anyway). Testing against the Scheme suite didn't show much, because most Schemes either don't have complex numbers at all, don't have `infinite?` and/or `nan?`, or don't allow complex numbers as arguments to them. However, Gauche, Chicken with the numbers egg, Vicare, !IronScheme agree that `+inf.0+nan.0i` is both infinite and NaN. Spark says it is neither, SXM doesn't allow NaN in a complex value. #364 truncate, floor, ceiling round should return a non-finite argument Preferences: unspecified, input, error Rationale: Implementations differ. If we must specify, R6RS wins. #392 Exact positive and non-negative integer predicates Preferences: yes Rationale: Natural numbers are an important type, and Scheme should support it directly. #380 Is support of TAB as a whitespace character required or not? Preferences: required Rationale: All Schemes treat tab as whitespace anyway, though some give it special meaning (completion or whatever) at the REPL. #388 Specify what `display` does with circular lists Preferences: labels Rationale: Display should be safe (shouldn't loop), since it's often used as a debug printer. It might be better if it ignored sharing, but not enough to be worth yet another exception. #447 #!fold-case and #!no-fold-case have no final delimiter Preferences: delimiter Rationale: Most of the time case-folding directives will be delimited by newline or space anyway. I see no point in adding yet another class of magic implementation-dependent things to the standards: implementations can do what they will anyway. #442 write procedure is not backwards compatible Preferences: write+simple, write+simple+shared Rationale: `Write` should do the data-preserving thing. I think it's just enough to have a space- and time-efficient `write-simple` alongside it, though I can see why people would want `write-shared`, so I've made that my second vote. #443 Recommend sources of character names Preferences: unspecified, w3c, unicode Rationale: Alex is unhappy with the W3C list because it has case-sensitive names (so under case folding some names are shadowed), and I'm unhappy with the Unicode list because it's huuuuuuge and the names are loooooong. Let's say nothing. #219 Bring back readable boolean literals Preferences: long Rationale: "I meant what I said and I said what I meant / An elephant's faithful, 100%!" --Horton Hatches The Egg #140 Removing `quotient`, `remainder`, `modulo` Preferences: yes Rationale: It's silly to have both sets of names in the base library. #378 Rename GET-FEATURES to just FEATURES Preferences: features Rationale: I don't even know why I made this `get-features` when I proposed it. #384 Merge `bytevector-copy` and `bytevector-copy-partial` Preferences: yes Rationale: This is in conformity with the way we do string and vector copiers now, as well as the destructive `bytevector-copy!`. #385 Merge `write-bytevector` and `write-bytevector-partial` Preferences: offsets-last Rationale: I think the port is less important than the stop/start. #387 Add start/end arguments to string->vector and vector->string Preferences: yes Rationale: Consistency and completeness. #391 Add predicates for R7RS signalled conditions Preferences: yes Rationale: There are only a few situations where errors must be signalled, and we should be able to identify which one we have in an exception handler. I can't think of any reason for providing `file-error` but not the others. #400 Define record? . Preferences: no Rationale: No, no, a thousand times no. The large language may want to introduce opaque records (records that look like primitive types to the outside world) and this would effectively prevent it. Redefining `record?` within a library wouldn't be enough, as it would permit opaque records to be recognized as such as soon as they were passed out of the library. #425 Add read-string, read-string!, write-string procedures to (scheme base) Preferences: yes Rationale: As soon as we voted in `string-copy!`, the goal of immutable strings died a horrible death. We should have all of these for bulk I/O. #433 full conversion cycle for containers Preferences: list+vector Rationale: Conversions between bytevectors and lists/vectors are sensible, but doing Latin-1 conversions isn't a particularly sensible conversion between strings and bytevectors. #444 Add vector-append procedure Preferences: yes Rationale: Consistency and completeness. #451 Add bytevector-append procedure Preferences: yes Rationale: Consistency and completeness. #445 Bidirectional ports and port-open? Preferences: replace Rationale: It's better to keep these separate, even if marginally less convenient. #450 Eliminate default for fill argument in vector-copy Preferences: default Rationale: This routine comes from SRFI-43 and should be kept compatible with it. #404 Make handlers take a raise-continuable? argument. Preferences: no Rationale: Given that Scheme has no way of calling a procedure portably when the number of arguments it accepts is unknown, I have to reluctantly reject this, even though it is clearly the Right Thing. Many handlers will not care, and they should not be required to be retrofitted with a dummy second argument. #373 (exit #t) should be the same as (exit) Preferences: boolean Rationale: `Extended-true` is going too far: 0 means success on many systems, but failure (specifically: failure of unknown origin) on VMS. Portable code should stick with `#t` and `#f`. #375 Add EMERGENCY-EXIT procedure Preferences: yes Rationale: Given that `exit` unwinds thunks, this is needed. It should also call `_exit()` on Posix and Windows, so stdio buffers are not flushed either. #394 Ditching SCHEME-REPORT-ENVIRONMENT and NULL-ENVIRONMENT Preferences: move, remove Rationale: These do no harm in the R5RS-compatibility library, but are actively harmful (because misleading) in the `eval` library where they are today. #413 EVAL accepts DEFINE Preferences: yes Rationale: We've got first-class environments now, we should make use of them. #399 clarify which primitives are allowed to implicitly force Preferences: type-check, unspecified Rationale: The `type-check` rule is sensible and clear. #405 Make promises first-class Preferences: disjoint, yes Rationale: Promises should be disjoint, specifically disjoint from procedures. See DisjointProcedures for which are and which are not. #462 end of line definition Preferences: none, no-return Rationale: The implementation-defined extensions is for the sake of R6RS systems that treat EBCDIC NEL and Unicode LS as line delimiters (a la XML 1.1, both my doing, I fear). Defining "a" as a line ending is a quality of implementation issue; the standard does not need to forbid implementations from being stupid, because nobody will use such an implementation. I agree we could live without `\r`, but it's very standard today in such routines. #452 provide digit-value support for hex-digits Preferences: ascii-hex, keep Rationale: `Ascii-hex` spoils the theoretical purity of `digit-value`, but it's handy to have packaged in the same framework, and we can certainly say it is provided for convenience. Failing that, this procedure will be useful in parsing even if only ASCII digits are expected. #411 Reference implementation Preferences: yes Rationale: Chibi is the de facto model implementation, and we may as well say so. It's small, easy to understand, and does a lot of things directly in Scheme. #463 library naming conventions Preferences: singular Rationale: This is a matter of taste, but I like the singular form and see no reason to change it. -- John Cowan cowan@ccil.org http://ccil.org/~cowan Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape