Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!scramble.lm.com!news.math.psu.edu!chi-news.cic.net!nntp.coast.net!col.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.96Feb28133746@hplgr2.hpl.hp.com>
In-Reply-To: blume@zayin.cs.princeton.edu's message of 27 Feb 1996 20:26:46 GMT
Date: Wed, 28 Feb 1996 21:37:46 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>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Lines: 37

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

|   From: blume@zayin.cs.princeton.edu (Matthias Blume)
|   Date: 27 Feb 1996 20:26:46 GMT

|   In article <GJR.96Feb22191305@hplgr2.hpl.hp.com> gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas) writes:
|
|      I personally believe that opaque types are a bad idea and very much
|      against the spirit of Lisp/Scheme.
|
|   If opaque types are against the "spirit" of Scheme, then -- perhaps --
|   that "spirit" is the bad idea.  At least that's *my* personal belief,
|   despite of the fact that I once was a big fan of Scheme myself.

Since you no longer are, why should we pay attention to you :)

Now seriously.  I have never understood the reason to prevent access
rather conventions that discourage undesirable access but still make
it possible for the (usually) rare cases when such access is
necessary.

One of the beauties of Scheme and Lisp in my mind has always been the
ability to patch things as they are running -- programs often develop
by evolving rather than by redesign.  Opaque types and module systems
with private variables or procedures often make that difficult and
sometimes make that impossible.  In other words, I don't trust the
providers of abstract types or modules to think of all the uses that I
may give to their software.  Hence I want to have ways to go beyond
their advertised interface, even at the risk that I will void the
warranty of proper operation.

I think GNU Emacs, just to give an example, is far more customizable
precisely because it allows arbitrary mucking around with internal
stuff.  It (GNU Emacs Lisp actually) does have a problem with name
conflicts, but that can easily be solved without adding impenetrable
barriers.  I would hate to see Scheme evolve in a direction that would
make writing something as customizable as GNU Emacs difficult.
