On Thu, 03 Sep 2009 14:53:23 -0400, John Cowan <[email protected]> wrote:
> This is a proposal for 43 new identifiers and 7 new lexical-syntax
> features to be added to the "small Scheme" language beyond those of R5RS.
> I am publishing this document to invite wide comment. There is nothing
> official about it. I acknowledge the kind help of Taylor Campbell and
> Alex Shinn in the discussions that led up to this; however, I retain
> sole responsibility for it, including all errors. I give the sources of
> the identifiers and features in square brackets.
I'm already suspicious here. Why do we need to add all this stuff in?
> This proposal is biased toward things that cannot be implemented
> portably,
> or cannot be implemented well, in plain R5RS. Thus, large and important
> libraries like SRFI-1 have been omitted; this does *not* mean that small
> Scheme implementations shouldn't provide them.
I'm not convinced that it makes a difference whether a feature is
implementable or not in the Small Scheme. If we create a standard feature
or library of things that aren't easily implemented in Small Scheme, why
should we then put them in Small Scheme? I don't see the goal of Thing One
as being the lowest set of features through which all other features might
be implemented. It might be nice to distinguish core features or Small
Scheme features as being those which usefully permit the creation of many
other features, or which form a small, minimally useful basis for
programming, but I don't see why we should add things in here just because
they are hard to implement in Thing One.
> New syntax (11 identifiers):
>
> [SRFI 8] receive
Why would we need to do this? This is easy to implement.
> [SRFI 9] define-record-type
I want to say no to this, but I agree that it would be nice to have the
ability to create new types. I'm just not sure this is the best way to do
it.
> [SRFI 11, R6RS base] let-values, let*-values
These can also be portably implemented.
> [SRFI 16, R6RS control] case-lambda
I really don't see why this should be necessary. I use it plenty, and like
it, but I don't understand putting it into a *small* Scheme.
> [SRFI 39] parameterize
Parameters are nice, but also easily implemented. I don't see a reason to
put them in the base.
> [SRFI 45] lazy
Eh....Again...I'm not seeing why this belongs in a core Scheme?
> [R6RS base] letrec*
This...maybe. Yeah.
> [placeholder for module system] component, import, include
I want any module system introduced in core Scheme to be absolutely
compatible with a larger module system used as the standard everywhere.
> New procedures (32 identifiers):
>
> [SRFI 6] open-input-string, open-output-string, get-output-string
> [SRFI 23] error
> [SRFI 27] random-integer, random-real
> [SRFI 39] make-parameter
> [SRFI 98] get-environment-variable, get-environment-variables
> [SRFI 74 augmented with R6RS bytevectors]
> blob?, make-blob, blob, blob-ref, blob-set!
> blob-length, blob=?, blob-fill!, blob-copy!, blob-copy
> [R6RS base]
> finite?, infinite?, nan?, div, mod, div0, mod0,
> exact-integer-sqrt, call/cc
> string-for-each, string-foldcase
> vector-map, vector-for-each
> [R6RS command] command-line, exit
>
> New lexical syntax (7 features):
>
> [SRFI-30, R6RS] #| ... |# for block comments
> [CLHS, similar to SRFI-58] #nA for heterogeneous arrays
> [SRFI-62, R6RS] #; for datum comments
> [R6RS]
> #vu8 list for literal blobs
> +inf.0, -inf.0, +nan.0 for IEEE non-rationals
> escape sequences in strings
> [various implementations] #cs, #ci for case sensitivity control
>
> Instances of #nA datum are replaced by (construct-array-from-lexical
> n datum), which is not defined by small Scheme but may be provided by
> implementations. The name is deliberately ugly, but only implementers
> should have to type it.
You're adding a lot of stuff here. Do we really need all of this stuff in
the Foundational Scheme?
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
