On Wed, 2009-09-23 at 18:10 -0700, Brian Harvey wrote:
> I expect people who are very concerned with efficiency to be WG2 customers.
> WG1 customers are going to be more interested in expressiveness, simplicity,
> and clarity.
I think at this point we may actually have a case for three working
groups. The distinction between WG1 and WG2 seems to be defined
from the point of view of R6RS supporters; WG1 is for people who
had reasons to vote against R6, and WG2 is for people who want to
extend it.
But this was a false dichotomy, because people who did not (and do
not) support R6 actually want at least two very different things.
One is the pedagogical language; expressiveness, simplicity, and
clarity, as Brian wrote above. Large implementations are fine here
if they abstract details in a nice way. The "minimal" I/O requirements
are all character-oriented. Nobody has to worry about issues like
encoding because that's all taken care of in the implementation, and
blobs can be implemented as general vectors holding u8 values, etc.
This camp is occupied by those who thought R6 was specifying too many
grotty details.
The other (or at least another) is the embedded-systems language;
simplicity, clarity, and expressiveness are important, but the
implementation needs to be fast and small (possibly skipping parts
of the numeric tower for the sake of being small) and the "minimal"
I/O requirement is byte-oriented. Reading/Writing characters is
secondary and may be supplied by a library implemented in terms of
bytes. Blobs are *the* most important datatype, and have to be
handled with blazing speed. Strings are secondary and may be supplied
by a library implemented in terms of blobs. In fact there probably
needs to be a way to designate that a blob has a particular system
address, or that parts of it are to be considered "volatile" or
writable by other processes, or else you can't write device drivers
or reliable FFI's. This camp is occupied by those who want a
systems programming language, and thought R6 was loaded with
irrelevant stuff that didn't address their needs and made the
implementation too large and not flexible enough for the systems
they're targeting.
I'm going to say straight up that WG1, pedagogical language, and
WG1, embedded-systems language, have conflicting needs that will be
at best difficult to reconcile in a single standard. They are the
"same" working group only if classified by R6RS supporters as "those
who had reasons to vote against R6." WG1, pedagogical and WG2
probably have more in common than either has in common with WG1,
embedded-systems. In fact WG1-P can reasonably be expected to
be a proper subset of WG2. WG1-ES cannot.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
