[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Scheme pre-R6RS Workshop at ICFP - What is the Point?
Date: Wed, 27 May 1998 15:34:36 -0400
From: Matthias Blume <blume@CS.Princeton.EDU>
From: email@example.com (Michael Sperber [Mr. Preprocessor])
Subject: Re: Scheme pre-R6RS Workshop at ICFP - What is the Point?
Date: 27 May 1998 20:35:46 +0200
> >>>>> "Alan" == Alan Bawden <Alan@lcs.mit.edu> writes:
> Alan> A little example. Sometimes I'd like to be able to open a file
> Alan> and read it as a sequence of 8-bit bytes.
> An issue finally. Has this been talked about or could one safely post
> a strawman proposal?
Actually, I'd like to just make a note and then postpone the
discussion of binary I/O. Here is why:
Most reasonable languages
for varying values of "reasonable"
(and here I include C, C++, etc. along with
my more favored ML etc.),
I/O has been deliberately left out from the core language design.
I/O has been deliberately left out by some of us, not by others.
This non-decision is a decision. The assymetry of understanding
what constitutes a "decision" about this language is why some people
end up having to "agitate for change" while others see that as "unnecessary".
At the very least, have the polite courtesy of acknowledging that the
status quo is a "decision" and that "NOT doing something" has the same
negative impact on the langauge to some of us that "doing something" has
on others of us.
Some of us could dig ourselves out of the hellish state Scheme is in if
I/O were standard. But by omitting it, you assure we must wait for the
Scheme designers to tell us how it will be done.
Instead, it is provided by a "standard library".
The nice thing about standards being that there are so many of them.
Who's going to define these if not us? If not us, or a forum designated
by us, how is it standard?
Now, some may say that standard library design is also language
design, and I would agree with this to some extent. But there still
is a distinction.
Before we are able to talk about library design, we must first come up
with a standard way of dealing with libraries in general. And _that_
will have to be reflected in the design of the language itself. What
I am talking about, of course, is a module system.
My understanding of "modules" is lexically partitioned namespaces. That
seems an utter red-herring except insofar as you want to use these
unrelated issues of I/O and call-out as forcing functions for getting a module
system. Scheme could live forever without a lexical module system and still
have the ability to do foreign-function call and I/O. I'm not trying to
diminish the importance of a module system--I'm jsut saying that the fact
that you find these to be tangled is a CHOICE you are making and trying to
thrust upon us. I don't see it.
Once we have a module system, many of the apparent conflicts can be
reconciled: Libraries can be specified, features can be properly
grouped, and individual implementations can safely provide their own
Would you like to explain how the addition of a module system will give you
the ability to open a file in 8-bit mode? Seems to me that it's going to
also require you to deal with binary formats SOMEWHERE so that foreign
function call can be explained.
An example for the latter: The "Standard ML of New Jersey"
implementation of "Standard ML" has finally come around to cluster all
(well, most) of its language extensions in one module: the structure
called "SMLofNJ". This includes trivial things like access to the
command line as well as more tricky issues such as first-class
continuations, timers, control of the garbage collector, profiling,
and weak pointers. None of this stuff has any bearing on "The
Definition of Standard ML" or the specification of the standard
library. Those who don't need to use it don't need to know about it.
And what of USERS who want to provide extensions? They have to wait for
a friendly implementor? You don't see it as part of the core language
to allow for extensions?
"Above all," I would like to urge everyone, "if you want to make Scheme a
better language, the first you need to do is provide adequate support
(SML has gone the same way: 1990 there was only the module system and
hardly any library. The initial basis in the 1990 definition was a
joke as far as serious programming is concerned. Seven years later,
people then got their act together and agreed on a "Standard Basis"
Look, I'm not even trying to push for an FFI per se, though I think it's
not a bad idea. What I'm trying to say is that you hae a definite theory
of how you want the language design to go and it does not follow that the
others of us have that theory. What troubles me is not that you have a theory;
it's that you talk in terminology like as if there is no other theory.
A big step forward would be for you to admit that you do not have a unique
lock on how things must be done and that ways exist that are incompatible
with what you want which would lead to interesting, useful, and elegant
languages. I certainly will agree to that statement. If you find you cannot,
you should think about that.
And once you have admitted that your way is not the only way, then you need
to question the things you are regarding as premises (like that "modules are
necessary to libraries" or that "libraries are the only reasonable way to
provide for 8-bit I/O").
I'm frankly not comfortable with a language that purports to be on the cutting
edge and can't do 8-bit i/o because it wants to leave it up to implementors
to decide if this is "a useful extension". Anyone who doesn't see it as
absolutely necessary to all material data processing has not been studying
file formats recently and has a very limited view of what kind of data is
being passed among programs. Short of fancy UIs (and I don't see those
standard in Scheme either), a language needs to lean heavy on program
interfaces. When it can't interface, it's lost.
And frankly, saying the words "it's up to implementors to decide if 8-bit I/O
matters" is tantamount in my mind to saying "I don't know for sure myself if
8-bit I/O matters" and THAT is something I'm not sure I can say. Come on.
Even ISLISP (the standard for which isn't much longer than Scheme) specifies
how to do 8bit i/o.