[Scheme-reports] John Cowan's votes on the sixth ballot

[John Cowan <cowan@x>]

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@x   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

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports