Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore-2!bellcore!mbr
From: mbr@flash.bellcore.com (Mark Rosenstein)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp Package System Considered Harmful
Message-ID: <MBR.90Oct19073520@ponape.flash.bellcore.com>
Date: 19 Oct 90 11:35:20 GMT
References: <271CDC30.1E54@wilbur.coyote.trw.com>
	<2865200060@ARTEMIS.cam.nist.gov>?<2298@heavens-gate.lucid.com>?<271BA6D1.5B83@wilbur.coyote.trw.com>
	<271E0D40.451E@wilbur.coyote.trw.com>
Sender: news@bellcore.bellcore.com
Reply-To: mbr@breeze.bellcore.com (Mark Rosenstein)
Organization: Bellcore, Morristown, NJ
Lines: 89
In-reply-to: scott@wiley.uucp's message of 18 Oct 90 20:14:56 GMT

In article <271E0D40.451E@wilbur.coyote.trw.com> scott@wiley.uucp (Scott Simpson) writes:

   From: scott@wiley.uucp (Scott Simpson)
   Newsgroups: comp.lang.lisp
   Summary: I'm not convinced.

   I agree that the intent that I intended to use packages for and the
   intent they were designed for are probably quite different. I don't
   know what packages were designed for. I have been told that they are
   to be used for separating large subsystems of code. The point I have
   been trying to make is that the information hiding granularity of
   packages is way too coarse and no other mechanism in Lisp can give me
   the granularity I want (i.e., class based) easily. I don't find
   packages very useful and I wouldn't cry a tear if they were simply
   removed from the language.
Well, I'd be major depressed. Ain't you never had name conflicts in C
when you try to load multiple big subsystems? It's sort of hard to 
imagine running in a world with flavors, CLOS and PCL all present
without packages, much less CLIM, CLM, CLX, and half a dozen user
packages. They can mostly all coexist, call each other, without much
fuss. [If one object system is good, two must be better, and three
well, you know, the old code that wouldn't die]. I tend to run a given
lisp world for weeks. By the end, I have metering loaded and this and
that, and suprise, suprise they don't interfer with each other. I shudder
to think what would happen if all their symbols were in the user package.
I expect one uses packages to avoid conflict with other subsystems that
you have no control over as well as to segment your program. I don't 
know that there is a good treatment, or even if one is possible on how
to segment functionality along package lines. For small systems one will
do and bigger stuff, I've used up to say a dozen, but that might have been
a few too many.

   Yes. I hate this. The double colon is way too similar to the single
   colon. 
They don't seem that similar to me. Everytime I use a double colon,
the good code fairie comes into my office and smacks me on the side
of the head. Unless of course, I'm calling some system function
that isn't documented, but I need. Then I just pay for it in the
next release when it changes under me. But I know. I do it to myself
of my own volition. I honestly have never mistakenly used a double
colon.
   I can concede that for efficiency reasons or some such it is
   non unreasonable to have back doors that can break the abstraction
   barrier. C++ does this with its ugly friend functions. However, I do
   think that they should be discouraged and if used, should be quite
   noticeable. It is said that they put gotos in Ada (especially for
   automatically generated Ada programs) but that they discourage their
   use and make them stick out like a sore thumb. Ada's labels look like
   <<label>>.
This is lisp, not Pascal. This is why all good little lisp programmers
read Abelson and Sussman or Allen.

   Exactly. Strength of will and extraordinary discipline. You hit the
   nail on the head. This is *exactly* what I am trying to avoid.
   Besides, if we didn't cherish information hiding, language protection
   and ease of uses why don't we all go back to programming in assembly
   language? They all are Turing machine equivalent anyway. Right? I
   don't think that the difference between external and internal
   functions should just be that one is documented and the other isn't.
   We need language features to help in providing protection and ease of
   use.

   Scott Simpson			TRW	scott@coyote.trw.com


Wow. Strength of will and extraordinary discipline. Heck, here I thought
it was plain economics. Well designed code is cheaper over its lifetime
than poorly designed code. [Go ahead do a study on that. Step 1: get
a definition of well designed code. (you don't need step 2, step 1
will never return)].

Ok. I've actually lost the thread of this information hiding stuff. Keene's
book on CLOS has many excellent examples of the use of CLOS to insulate
interfaces from underlying implementation. It isn't a firewall. For
debugging, for quick hacks, for system code, lisp has always given you
at least ten ways to screw yourself to the wall (redefine cons with your
more efficient version, say). 

This is not to say that I don't want my compiler or my environment to
warn me when I am doing something unusual (like when two packages
have the same nickname---waaaah), but I never want my lisp to think it
is smarter than me. It can ask "Do you really want to screw yourself?",
but it darn well better let me, when I answer "Yes, thanks." And certainly
runtime checking on array bounds, say, is a major win. I guess fundamentally
good design isn't easy. I want major support from my language and from my
environment, but sometimes a programmer's got to do what a programmer's
got to do.

Mark.