On Wed, 2009-09-09 at 22:57 +0100, Alaric Snell-Pym wrote:
> On 9 Sep 2009, at 9:18 pm, Eli Barzilay wrote:
> > This obsession with
> > a 50-page limit for the spec is suffocating the language (and the
> > post-r6rs noise is a perfect example of this).
>
> 50 pages is by no means magical! I'm more interested in keeping
> features that aren't necessary for "being Scheme" out of the (core)
> spec, and standardising them elsewhere (SRFIs) or as "optional"
> extensions to the spec.
True. I actually cringed a little bit when I saw WG1's intended
user groups including "50-page purists" -- it is both an epithet
that reflects the resentment and bitterness that the R6 authors
apparently feel about the non-acceptance of their standard by some
parts of the community, and a potentially crippling promise to
keep the WG1 document under a "magical length" of 50 pages. As
an expression of bitterness and resentment towards some hoped-for
collaborators, I think it was an extraordinarily poor start for
a collaborative process.
Here is what I think Thing One ought to be: Some details are
omitted.
A table of contents that includes "How to" entries for things
that programmers learning a new language usually want to know
how to do - define functions, define macros, etc. This might
be separate from the "Categorical" TOC that previous reports
have had, or might be blended with it.
An explanation of basic syntax and semantics, including detail
on function calls, syntax invocations, and continuations. This
should also mention and explain continuations with multiple
returns, (which I dislike but seems needful for continuity now).
I would like to have dynamic environments (and "special" variables)
added to the fundamental language, since that would allow strangenesses
like with-input-from-port, current-output-port, etc, to be moved out
of the core language and into libraries. But I'm not going to insist
on it. And I would argue against it if lexical and dynamic variables
are to occupy the same namespace. For example, I would require all
variable references starting and ending with asterisks to refer to
dynamically scoped variables, and all other variable references to
refer to lexically scoped variables, just to avoid confusion -
effectively making the asterisks into primitive syntax that means
"look this variable up in the dynamic environment."
An explanation of the "primitive forms" or building blocks
of the language - variable reference, define, lambda, eval, apply,
cond, etc.
Basic operations on core data types, including example
implementations in cases where they are simply implementable
in terms of other more-basic operations or primitive forms.
(this implies at least an implicit partial ordering of forms
as to basic-ness). But MANY operations considered to be
"part of the language" now should migrate to a specific
library (including "read" and character I/O).
This list of operations should be interwoven with an
inclusive listing of *ALL* applicable forms defined by the
report, including "see definition in primitive forms"
references to primitive forms like lambda and define and
"see definition in I/O library spec" references to
things like read-char and write-char.
A module system that includes detailed descriptions of
how to define portable modules in scheme,
how to load user-defined portable modules (typically
kept in the same directory as the rest of the project).
how to load implementation-defined portable modules
(scheme modules provided by the implementor, presumably in
a place known to the installation/configuration/registry
database).
how to manage the namespace, with examples.
Mention that implementations are strongly encouraged to
provide and document (unspecified) ways to define "non-
portable" modules that do things not accessible in pure
scheme (such as bitgroveling, file and character I/O,
access the binary format in which scheme's data is held
at runtime, operating sytem calls, etc).
how to load "implementation defined non-portable"
modules.
How to load "user-defined non-portable" modules (modules
provided by the user which use the implementation-defined
means of creating non-portable modules to do things.)
Refer to Thing Two for an exhaustive list of libraries.
Thing One will have a much shorter list of libraries,
including:
A standard file I/O library specification that includes ftell,
fseek, open (for reading, writing, or both), filesize,
directory listing, etc. These routines may signal an error if
unable to perform the requested functions, of course.
A standard commandline library that (at least) allows the scheme
program to submit commands to a command shell, wait for them to
complete, and get the results as a string which it can parse and/or
a numeric error code. Different commands may be needed on unix
or windows or mac, and different error messages or codes may be
returned, but by all Gods we ought to be able to make at least
the functionality of submitting a command to the command line
and getting a result portable, if not the commands and results
themselves.
At least a few "useful" examples of portable libraries -
I nominate extended list library, hashtables and/or red-black
trees as prime examples.
A formally defined syntax that provides read-write syntax and
read-write invariance for core data types, where practical.
Without specifying any method of creating user-defined lexical
extensions.
A detailed formal semantic description. (I find operational
easier to follow than denotational, but as long as it's fairly
rigorous I don't care).
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
