Re: Scheme convergence [Was: Re: 3.99.3]
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: <199710062041.QAA07958_at_lambda.ai.mit.edu>
Reply-to: shivers_at_ai.mit.edu
From: Olin Shivers <shivers_at_lambda.ai.mit.edu>
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.,
Bigloo
Chez Scheme
EdScheme
Gambit
Guile
MzScheme
RScheme
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
compilers.
* 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
point.
- 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?
-Olin
------- 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