[r6rs-discuss] criteria for including or excluding a library
I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors.
Apart from what can be inferred from status reports and
the draft R6RS, the editors have published no criteria
or rationale for deciding which libraries should go into
the R6RS and which should be excluded. That lacuna
invites all of us to ponder (in private) our own personal
criteria, and to discuss (in private and in public) what
criteria ought to govern.
I'll start.
It seems to me that the following criteria are relevant,
though how much weight to give to each is controversial.
Could be a SRFI?
If the library could be implemented portably, with
reasonable efficiency, using only the rest of R6RS,
then it could be described by a SRFI and provided by
a portable reference implementation instead of being
included within the R6RS.
Usage within R6RS?
If the library is used by other parts of the R6RS,
or something very like it is needed in order to
implement other parts of the R6RS, then the library
should perhaps be part of the R6RS.
Usage in the wild?
If many Scheme programs are using similar features,
in the form of implementation-dependent extensions
or existing SRFIs, then the library should perhaps
be included into the R6RS, as a way of blessing
current practice while reducing or precluding
gratuitous differences that would interfere with
portability.
Consensus on semantics?
If the community agrees on the semantics of a library,
then including it within the R6RS can record that
consensus. In some cases, however, it might be
necessary to include something within the R6RS
precisely *because* there is no consensus choice
between two or more reasonable semantics, each
with its own advantages and disadvantages.
When a choice truly needs to be made, the R6RS
should make it. (That R6RS characters correspond
to Unicode scalar values, not to code points, is
one example of this.) On the other hand, the R6RS
should not make choices that don't need to be made.
* * *
I will now illustrate these criteria by stating my own
subjective impressions of how they apply to the libraries
described within the second part of the draft R6RS.
* * *
(r6rs unicode), section 10 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? none, but is needed for
implementation of the read procedure
Usage in the wild? limited, but demand is growing
Consensus on semantics? excellent (the controversies
belong to sections 9.14 and 9.15)
(r6rs bytes), section 11 of the draft R6RS:
Could be a SRFI? yes, but would be inefficient without
special support from implementations
Usage within R6RS? the i/o libraries; also used by
the reference implementations of (r6rs unicode)
and the various arithmetic libraries
Usage in the wild? extensive use of similar features,
e.g. SRFI 4, SRFI 47, SRFI 63, SRFI 66, SRFI 74
Consensus on semantics? excellent
(r6rs lists), section 12 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? used mainly within examples
Usage in the wild? universal for R5RS procedures,
extensive for others; similar to a subset of
SRFI 1 but different in detail
Consensus on semantics? near-universal for R5RS
semantics, but R6RS restrictions and required
error checking are highly controversial, as
is divergence from SRFI 1
(r6rs records procedural), section 13.1 of the draft R6RS:
Could be a SRFI? no; record types could not be
generated by an R5RS-portable implementation
Usage within R6RS? little or none, but would be
needed for implementation of most R6RS libraries
Usage in the wild? extensive use of similar features,
e.g. SRFI 9
Consensus on semantics? good
(r6rs records explicit), section 13.2 of the draft R6RS:
Could be a SRFI? yes, using (r6rs records procedural)
Usage within R6RS? none
Usage in the wild? extensive use of similar features,
e.g. SRFI 57
Consensus on semantics? good
(r6rs records implicit), section 13.3 of the draft R6RS:
Could be a SRFI? yes, using (r6rs records procedural)
and (r6rs syntax-case)
Usage within R6RS? none
Usage in the wild? extensive use of similar features
Consensus on semantics? good
(r6rs records inspection), section 13.4 of the draft R6RS:
Could be a SRFI? no; tightly coupled to
(r6rs records procedural)
Usage within R6RS? none
Usage in the wild? extensive use of similar features
Consensus on semantics? good
(r6rs exceptions) and
(r6rs conditions), section 14 of the draft R6RS:
Could be a SRFI? no for exceptions, yes for conditions
Usage within R6RS? pervasive
Usage in the wild? some use of similar features,
e.g. SRFI 34 and SRFI 35
Consensus on semantics? some
(r6rs i/o primitive), section 15.2 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? none
Usage in the wild? limited use of similar features
Consensus on semantics? unknown
(r6rs i/o ports), section 15.3 of the draft R6RS:
Could be a SRFI? no; could not be implemented portably
Usage within R6RS? (r6rs i/o simple)
Usage in the wild? extensive use of similar features,
mostly implementation-dependent extensions to R5RS
Consensus on semantics? yes: the consensus is that
its semantics is badly broken
(r6rs i/o simple), section 15.4 of the draft R6RS:
Could be a SRFI? maybe, if (r6rs i/o ports) weren't
broken
Usage within R6RS? implements and enforces syntax
of datums
Usage in the wild? universal
Consensus on semantics? excellent
(r6rs arithmetic fixnum), section 16.3.1 of the draft R6RS:
Could be a SRFI? yes, but requires compiler support
for efficiency
Usage within R6RS? none, but is used by reference
implementation of generic arithmetic
Usage in the wild? some use of similar features,
which are supported by several compilers
Consensus on semantics? good
(r6rs arithmetic fx), section 16.3.2 of the draft R6RS:
Could be a SRFI? yes, but requires compiler support
for efficiency
Usage within R6RS? none
Usage in the wild? some use of similar features,
which are supported by several compilers
Consensus on semantics? good
(r6rs arithmetic flonum), section 16.4 of the draft R6RS:
Could be a SRFI? yes, but requires compiler support
for efficiency
Usage within R6RS? none, but is used by reference
implementation of generic arithmetic
Usage in the wild? some use of similar features,
which are supported by several compilers
Consensus on semantics? good
(r6rs arithmetic exact), section 16.5 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? none
Usage in the wild? none
Consensus on semantics? excellent
(r6rs arithmetic inexact), section 16.6 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? none
Usage in the wild? none
Consensus on semantics? good
(r6rs syntax-case), section 17 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? some syntactic extensions, notably
those in (r6rs records implicit)
Usage in the wild? extensive
Consensus on semantics? good, with some controversy
over details
(r6rs hash-tables), section 18 of the draft R6RS:
Could be a SRFI? no; eq? and eqv? hash tables require
special support from implementations; the rest could
be a SRFI
Usage within R6RS? none, but might be used to implement
(r6rs enum)
Usage in the wild? extensive use of similar features,
e.g. SRFI 69
Consensus on semantics? good
(r6rs enum), section 19 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? file-options
Usage in the wild? limited use of similar features,
mainly in Scheme 48
Consensus on semantics? unclear; new proposal
(r6rs when-unless), section 20.1 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? none
Usage in the wild? common
Consensus on semantics? excellent
(r6rs case-lambda), section 20.2 of the draft R6RS:
Could be a SRFI? yes, but requires special support
for efficiency
Usage within R6RS? none
Usage in the wild? common
Consensus on semantics? excellent
(r6rs promises), section 20.3 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? none
Usage in the wild? some; provided by R5RS
Consensus on semantics? good
(r6rs scripts), section 20.4 of the draft R6RS:
Could be a SRFI? no; requires special support
from implementations
Usage within R6RS? none
Usage in the wild? common
Consensus on semantics? good, but OS-dependent
(r6rs), section 21 of the draft R6RS:
Could be a SRFI? yes; this is just a composite of
other libraries, for convenience
Usage within R6RS? none
Usage in the wild? extensive use of similar sets
of extensions to R5RS
Consensus on semantics? with composite libraries
such as this, most controversies concern what
is included and excluded
(r6rs eval), section 22 of the draft R6RS:
Could be a SRFI? no; requires special support to
approach efficiency of host implementation
Usage within R6RS? none
Usage in the wild? some; traditional feature of Lisp;
provided by R5RS
Consensus on semantics? controversies include the
restriction to expressions and the interaction
with libraries
(r6rs mutable-pairs), section 23 of the draft R6RS:
Could be a SRFI? no
Usage within R6RS? none
Usage in the wild? common; traditional feature of Lisp;
provided by R5RS
Consensus on semantics? controversies include complexity
of required checking of list arguments
(r6rs r5rs), section 24 of the draft R6RS:
Could be a SRFI? yes
Usage within R6RS? none
Usage in the wild? extensive; provided of R5RS
Consensus on semantics? excellent
* * *
The opinions expressed above are just my own personal
impressions. Everyone here is qualified to correct me.
Will
Received on Thu Nov 02 2006 - 14:45:35 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:00 UTC