Scheme pre-R6RS Workshop at ICFP - What is the Point?

[Kent Pitman <kmp@harlequin.com>]

   Date: Wed, 27 May 1998 15:34:36 -0400
   From: Matthias Blume <blume@CS.Princeton.EDU>

   From: sperber@informatik.uni-tuebingen.de (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'll resist.

   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
   extensions.

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
   for modularity!"

   (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"
   library.)

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.