> I think first of all that the timelines set forth in the working group
> charters are too short by at least half.  It is not reasonable to
> think that both consensus and consistency may be achieved in this
> timeframe, especially since WG1's charter includes a "proof of
> implementability" which at this time can only be interpreted to
> mean an implementation.

I interpret proof of implementability as allowing us to point to
existing implementations that already have whatever feature is being
discussed.  That should be a much easier goal than providing a
complete implementation from whole cloth.

You may be right about the time frame.  Nevertheless, I hope we'll
shoot for the time frame that the Steering Committee has recommended.
Eighteen months is a long time, and we should be able to make
substantial progress in that much time.  If Scheme users and
implementers who are interested in the standards process can agree on
goals, i.e. the charters for the two working groups, then we have a
much better chance of making quick progress.

> Secondly I suspect that the requirement that the language of WG1 must
> be a subset of the language of WG2 will cause difficulties more
> serious than those who drafted the charters now suspect, for reasons
> I have explained on the R6RS-discuss list.  I see the desires of
> those who want a "small scheme" as being qualitatively different
> than what can be achieved by subsetting a larger scheme which serves
> the needs outlined in the WG2 charter.  The subset language will not
> under these rules be permitted to be consistent and unconstrained
> enough to avoid the need for the additional things required by the
> full language, thus it really will be "part of a language" instead
> of "a language so consistent and unconstrained that it can remain
> small."

I'm not convinced.  I'll point out that there's a difference between
asserting that WG1 Scheme will be a subset of WG2 Scheme and asserting
that it must be possible to implement all of WG2 Scheme strictly in
terms of WG1 Scheme.  (You're probably not making the latter
assertion, but I want to make that clear anyway.)  There may very well
be features of WG2 Scheme that depend on infrastructure that is not
provided by WG1 Scheme, either because there was no consensus on how
to standardize such infrastructure or because people were convinced
that the infrastructure didn't belong in WG1 Scheme.  That's okay as
long as what is, in fact, in WG1 Scheme is not inconsistent with WG2
Scheme.

I think I've found the message on <r6rs-discuss> where you made the
argument about the difficulties of reconciling WG1 Scheme and WG2
Scheme.  Is it the message from 23 Sep with the subject line "What's
under the hood?"  I'll quote from that message:

  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.

But the WG1 charter, as it stands now, says this:

  The language's target uses include education, programming language
  research, embedded systems, embedded scripting languages, and as a
  platform on which other languages can build.  For these uses a
  language that is "lightweight" at the semantic and/or implementation
  level is appropriate.

The draft WG2 charter describes its language thus:

  ...a language in the Scheme family that is large enough to address
  the practical needs of mainstream software development.

So WG1 Scheme, not WG2 Scheme, is intended to be a minimal language
that can, among other things, work on embedded systems.  But WG1
Scheme isn't intended to be a systems programming language, just one
that is small enough and simple enough at the conceptual level and
easy enough to implement that it is suitable not only for embedded
systems, but also for education, research, and embedded scripting
languages.  Those goals don't conflict with the language also being
the core of more complex implementations that support WG2 Scheme.  If
they do, then we should adjust the charters, since an explicit goal of
both charters is that the working groups "...must work together to
produce specifications that are consistent with one another."  Do you
have any specific suggestions for improving the charters?

Please forgive me if I have misunderstood your argument.

> It would not have been necessary to have more than one working
> group in the first place if subsetting were a viable approach.
> Rather, it would be appropriate for the working group to produce
> a document specifying some constraints as "optional", as was done
> in past RNRS reports. Indeed, this will be the net effect of the
> current effort if the draft WG charters are ratified and executed.
>
> At any rate, the effort will be interesting.

Yes, I'm sure that will be true!

Thank you very much for being the first person to publicly comment on
the revised charters (as far as I know).

We are eager for feedback.  The better the charters, the better chance
the two working groups have of making proposals that will please a
large part of the Scheme world.  The more successful we are at that,
the easier it will be for us all to share Scheme code with each other
-- to understand each other's code, and even to run each other's code.
Those are, to me, the most exciting things about the whole
standardization process.