Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!swrinde!sdd.hp.com!apollo.hp.com!lf.hp.com!news.dtc.hp.com!hplntx!hplntx.hpl.hp.com!gjr
From: gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas)
Subject: Re: R5RS?
Sender: news@hpl.hp.com (HPLabs Usenet Login)
Message-ID: <GJR.96Mar6110051@hplgr2.hpl.hp.com>
In-Reply-To: blume@zayin.cs.princeton.edu's message of 05 Mar 1996 16:14:07 GMT
Date: Wed, 6 Mar 1996 19:00:51 GMT
Reply-To: gjr@hpl.hp.com
References: <4gc83r$617@news.simplex.nl> <4gfrfi$m7u@camelot.ccs.neu.edu>
	<leavens.824995212@larch> <4gi3p0$kvh@agate.berkeley.edu>
	<leavens.825012724@larch> <GJR.96Feb22191305@hplgr2.hpl.hp.com>
	<BLUME.96Feb27152646@zayin.cs.princeton.edu>
	<GJR.96Feb28133746@hplgr2.hpl.hp.com>
	<BLUME.96Feb29105552@zayin.cs.princeton.edu>
	<GJR.96Mar4102338@hplgr2.hpl.hp.com>
	<BLUME.96Mar4160207@zayin.cs.princeton.edu>
	<GJR.96Mar4191050@hplgr2.hpl.hp.com>
	<BLUME.96Mar5111407@zayin.cs.princeton.edu>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Lines: 140

In article <BLUME.96Mar5111407@zayin.cs.princeton.edu> blume@zayin.cs.princeton.edu (Matthias Blume) writes:

|   In article <GJR.96Mar4191050@hplgr2.hpl.hp.com> gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas) writes:
|
|   I am not trying to take away anything.  And even if I did I wouldn't
|   have to powers to do so.

OK, I'll accept that.  I just feel besieged by the proponents of less
dynamic solutions.

|   Well, in the end the consumer cannot choose, no matter what.  The
|   consumer is likely to not know either Scheme or ML, so all this
|   discussion is moot.

Not really.  It is a matter of how much and in what circumstances.

|   Or are you saying that carmakers are fascist, because they don't
|   provide hooks so the customer can choose between gasoline, diesel,
|   methanol, hydrogen, electic batteries, solar power, wind power, ... to
|   propel their vehicle?!

No, but remember, we started talking about opaque types.  To my
knowledge no car manufacturer produces opaque engines, even though
they certainly produce abstract ones.  I can take a newly-bought BMW
to Dinan (sp?) motors and have them replace the timing microprocessor,
increase the capacity of the cylinders by boring them out, and add a
turbocharger.  This certainly violates the engine abstraction provided
by BMW, and as such, it voids the warranty I would get from BMW.
However, many people find this an attractive option because of the
added performance.

With physical objects it is difficult to produce opaque objects, and I
don't tnink we would really like a world where the objects we bought
were opaque and we could not modify their guts.  Yes, this is done
rarely and by few, but it is an advantage, not a disadvantage.  Those
who choose to observe the abstraction and choose not to play with the
guts (although many people take apart broken old objects to try to fix
them) do not really give anything up.

The crux of the argument is this: I strongly believe in abstract
types.  By and large, their implementation is best left alone.  On the
other hand, I believe that there are certain circumstances when the
implementation must be breached.  They are few and rare.  For those
that do not breach the implementation, the existence of (perhaps
cumbersome) facilities for doing so poses no problems.  However, their
absence presents huge problems for those who (feel they) need them.

A similar situation occurs with "sealed" module systems.  By and
large, I believe that other programmers will leave the internals
alone.  Occasionally, however, some will (feel they) need to get
inside.  The existence of (perhaps cumbersome) facilities for opening
the module does not in any way diminish their abstraction for those
who do not open them.

I'm even willing to make such access rather inconvenient and
prominently flagged.  If I'm not mistaken, Ada has something like
"using unsafe_programming_practices" or some such.  I am just
defending the existence (not the abuse) of such facilities.

|   I have written large programs in Scheme, but I tried to make sure that
|   nobody else modified my code, because I wouldn't be able to understand
|   it anymore.  But as programs grew (and VSCM's compiler was getting
|   quite big in the end) I found myself not being able to hold it all in
|   my head at once.  The situation became similar to the multi-developer
|   case, even though I was still only a single person.  (I hope I am,
|   even now. :)

I am not disputing the desirability and need for proper design and
modularity.  Don't get me wrong.  By and large I abide by advertised
interfaces and try to write my programs in a modular manner and
encourage others to do so.  The issue is not disagreement on
large-scale methodology, but on some simple back doors that I feel are
occasionally necessary.

|   At this point I decided to design and implement a rudimentary module
|   system for Scheme.  Even though it was quite crude it has proved
|   itself to be very, very helpful.  At the same time I also realized
|   that some things in Scheme just aren't right, because they get in the
|   way of a module system that works correctly in all cases.  This is
|   when my departure from the Scheme camp started, because there is so
|   much resistence against fixing these design bugs.  (And I am not even
|   talking about types here!)

I'm glad that we are not talking about types.  I agree that Scheme
needs a good module system.  I just happen to think that people are
too gung-ho in making it impenetrable with insufficient reason behind
such a decision.

I'm curious, what things do you think should be changed in Scheme?

In my ideal world, there would be a suite of optional (but often used)
tools for Scheme programs to perform type checking (with some degree
of inference and some declarations for those cases that the inference
algorithm was inadequate), code maintenance, etc.

I am willing to believe that Scheme could make the job of writing such
tools easier by changing in some details.  As such, I won't
necessarily agree with every change, but I'm willing to consider them.
In every case I will have to balance the benefit obtained from making
the tool's creation and operation simpler from the drawback of
diminished expressive power (if any).  I will also have to consider
whether the requested change is an inherent requirement of all such
tools or simply a requirement of the current stage in the
technological development of such tools.  Even if the latter, some
tools are useful enough that I may be willing (although less likely)
to change the language in that respect.

At any rate, rather than talking in the abstract, I would very much
like to see what the issues are that you think get in the way of the
large-system construction tools that you feel are invaluable.
Perhaps there is common ground.  I'm certainly hopeful.

|   Perhaps.  But a spel cheker iss inkredibli yusefull. :)

Absolutely.  However, it is neither mandatory, nor does its addition
limit the semantics of the underlying language.

After all, if it were mandatory, you would not have been able to type
the sentence above!

|      That is an exaggeration and you know it.  I would no more trust a
|      controller because it was written in ML than if it was written in
|      assembly language, and I doubt you would too.
|
|   Yes I would.

Interesting, but I think you are being naive.  I can't see anything
being a substitute for thorough testing.  Almost all the bugs that I
spend more than a few seconds fixing are of the category "something
was computed but it was the wrong thing".  A type checker would not
have caught them, and lack of testing would have produced a
non-properly working program.

|      Right, which is rather silly, isn't it?  I claim that for any
|      moderately complicated program half of the code would be of the sort
|      that you find above.
|
|   Not in my experience.

You must be much smarter than I am.
