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

[Matthias Blume <blume@CS.Princeton.EDU>]

From: Kent Pitman <kmp@harlequin.com>
Subject: Scheme pre-R6RS Workshop at ICFP - What is the Point?
Date: Wed, 27 May 98 16:05:21 EDT

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

Kent is greatly misrepresenting what I said.  I do not claim to have
"the only theory".  I am not trying to "thrust" anything on anybody. I
have not "purported" myself as "cutting edge".  I have not uttered the
words "it's up to the implementor...".

I do have certain views, though, and I think I have a right like
everyone else to try and explain them.  If you don't like to hear
them, fine.  There certainly is a "delete" button in your mail reader.

We seem to get into this every time I make a suggestion.  Maybe it is
my poor command of the English language that makes Kent think I am
trying to be impolite.  I am not!!! (Except right now.)

Frankly, I find Kent's language much more disturbing than whatever I
may have said, because his personal attacks are downright insulting.


I have in no way suggested that I can't do 8-bit I/O.  In fact, I have
started out saying that I'll POSTPONE this question.  I did not say
that I DISMISS it.  As far as I understand it, there is a difference
between these two.

My example (Standard ML) shows exactly what I mean. In the case of
SML'97, the language consists of two parts.  One is the language
proper -- syntax plus semantics of the syntactic elements.  The second
part is the basis library.  The library is _also_ part of the
standard.  But it's definition is based upon the syntax and semantics
of the underlying language.  (This is not to say that everything in
the library could already be defined in terms of the basic elements
from the core language.) Any implementation that claims to be SML'97
must provide both the core language implementation as well as the
basis library.

I did not claim that 8-bit I/O should be left out of a language
standard.  I was merely suggesting that one should understand such a
language standard as a combination of a standardized language core
plus a standardized basis library. For the benefit of the latter, I
would like the former to have a standardized module system.

I do understand that "not doing something" has "negative impact" on
progress.  I have not tried to say anything to the contrary.  It does
not take any "polite courtesy" from me to "acknowledge" one thing or
another.

I would be greatly relieved if in the future I am not again being
portrayed the way Kent is portraying me.  Please, don't put words in
my mouth that I never said, and don't extrapolate from what I actually
said to what you think of as being offensive or impolite!

-Matthias