[scheme-reports-wg1] John Cowan's votes on the sixth ballot John Cowan (12 Jul 2012 22:09 UTC)

[scheme-reports-wg1] John Cowan's votes on the sixth ballot John Cowan 12 Jul 2012 22:09 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