Re: Scheme convergence [Was: Re: 3.99.3]

From: Jim Blandy <>
Date: 07 Oct 1998 14:54:36 -0500

This might be a good time to re-post what I thought was a grand idea.
I don't know what replies Olin received, if any, to this post.
Apparently the idea is still in search of an organizer.

------- Start of forwarded message -------
Message-Id: <>
From: Olin Shivers <>
To: ... various members of the Scheme elite ...
Subject: System Scheme
Date: Mon, 6 Oct 1997 16:41:52 -0400 (EDT)

* Invitation

I would like to propose a little language-development effort, to be
titled "System Scheme." The purpose of the effort will be to make
the extensions to Scheme that are necessary to write useful systems
in Scheme that are portable across implementations.

Scheme today is one of the most un-portable languages in existence.
This has completely hamstrung the development of the language for
doing real programming. Instead of being able to profit from each
others' work, we must constantly reinvent and reimplement basic
system functionality.

In short, I would like to be able to write a Web browser in my Scheme
-- something that does socket TCP/IP, parses incoming data into interesting
data structures, accesses the file system, forks processes, raises
exceptions -- and have you be able to run my code, or modules of it,
in your Scheme.

I would like the implementors of the major Scheme systems out there, e.g.,
    Chez Scheme
    Scheme 48
to contribute to the development of the standard, and to sign up to
make compliant environments for their systems when we are done.

* Attitude plays a part

Development of the language has ground to a halt in the last decade
because of internecine disagreements, contentious standards efforts, and
extreme conservatism. We must avoid this.

If we are to successfully develop a standard, we must structure the
decision-making process with forward progress in mind. Our design
is not going to be R6RS. It is not going to be IEEE ratified. It
doesn't have to be perfect. It just has to be reasonable.

People must be willing to passionately defend their viewpoints, and
then bow to the voice of the majority once all arguments have been
aired and votes cast.

I propose a practical, pragmatic approach to development. Appeals to
as-yet non-existent optimising compiler technology not permitted.
Compatibility with existing implementations will, other things equal,
count for something. Minimalism and elegance will guide design, but
we should bear in mind the dictum that "things should be made as simple
as possible, but no simpler." Lambda is not a universally sufficient
value constructor.

* Considerations

The standard should permit a wide array of efficient implementations,
from embedded interpreters and byte-code machines, to native-code

* Components

I believe we need to settle on a standard for the following items:

- Language extensions
    - Exceptions
      There have been a couple of proposals, and much discussion.

    - Records
      There was almost agreement once upon a time on an extension to
      Scheme to allow new, disjoint record types to be defined. This
      should be resurrected as a starting point, and possibly a finishing

    - Modules
      A simple module system needs to be defined. There are already
      several possibilities put forth.

      On the subject of module systems, I have an additional remark.
      We will be able to avoid a great deal of petty syntactic issues
      if the module language allows a module to specify that a file
      providing a component of a module should be read and converted
      to s-expression data using a given procedure as the parser.
      This will allow modules using varying syntaxes (e.g., standard R5RS,
      scsh case-sensitive Unix scripts, Algol-like infix) to interact.

    - Strings and characters
      + ASCII no longer suffices; Unicode must now be considered.
      + R4RS doesn't even cover full ASCII. There is no string syntax
        for newlines, for example.
      + Primitives need to be defined for interconverting between
        characters and their representations (e.g., ASCII and Unicode).

- Libraries

    A module system will help factor these things.

    - A Unix API
      I submit scsh's syscall library as a draft proposal.
      Note that scsh's process notation, regexp package, AWK
      macro, filename manipulation and other machinery can be
      considered separately from the core OS library. The syscall library
      is what is primitive.

    - Binary I/O
      Scheme has no way to read and write bytes. It also lacks the
      means to compactly *represent* simple byte sequences. Many
      Scheme implementations provide non-standard 8, 16, and 32-bit
      byte vectors, or cheat and use strings as byte vectors, on a
      char=byte assumption. This assumption is going to break hard
      as we move into a Unicode future.

    - A Win32 API
      Rice? Is it too early? Doing a coherent job on Unix took me years.
      Is someone working on this one seriously?

- Command line interfaces
    A portable way to access command-line arguments

- C interfaces
    This, I believe, is too much to ask. C interfaces are extremely
    implementation specific. Elk and Scheme 48, for example, place
    radically different requirements upon their C interfaces. If someone
    has a good story to tell here, I would love to hear it.

- Threads
    Threads would be nice. But perhaps we might punt this in favor
    of getting something done with dispatch.

* Organisation

I propose a small working group, comprised mainly of implementors --
people with experience implementing real Scheme systems, who will doing the
work of providing the standard if it is successfully developed. These
people vote. Discussions will take place on a mailing list or other
Internet-mediated forum. Non-voters will be able to read the discussions
and contribute their opinions.


What are your thoughts?

------- End of forwarded message -------
Received on Wed Oct 07 1998 - 21:55:20 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST