Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore
From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp Package System Considered Harmful
Keywords: Packages, CLOS, Object-Oriented Programming, Common Lisp
Message-ID: <1990Oct18.152453.7100@hellgate.utah.edu>
Date: 18 Oct 90 21:24:53 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>
Organization: University of Utah CS Dept
Lines: 78

In article <271E0D40.451E@wilbur.coyote.trw.com> scott@wiley.UUCP (Scott Simpson) writes:
>In article <2865200060@ARTEMIS.cam.nist.gov> miller@cam.nist.gov writes:
>
>>One point is that, in Lisp, nothing is REALLY hidden -- some things are
>>just a little less visible than others.  Want a non-exported symbol from
>>a package? Use two colons.  Want to get at an unapproved slot from a
>>clos instance? Just use slot-value.
>
>Yes. I hate this. The double colon is way too similar to the single
>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>>.

I don't see what the problem is. If you don't want to get burned by
using internal functions and data structures, don't use them. I think
it's great that data structures are exposed in Lisp, if only to
satisfy my own curiosity.  One of the first things I do when I use a
Common Lisp implementation for the first time is type (symbol-plist '+)
to see what turns up.  (Maybe that comes after (time (fact 1000)) :-)

Some Lisp implementations go to great trouble to insure that the
source code of any function is available for inspection. That is even
better.

>>On the one hand,  I think that  packages are (very)  useful at a  coarse
>>grain: for  example  at  the  application  level.  I've never written an
>>application with more than  2 packages and  even those were  cases where
>>the one might be  used as a  separate set of  tools.  [I do  often write
>
>If you hardly ever use packages, why do you find them so useful?

That's not what he said at all. The basic idea behind packages is that
it's not too hard to avoid name collisions in your own code, or even
within an "application" (you can use grep, after all), but it is hard
to avoid collisions with other random programs that might be loaded in
the same Lisp image. For one program, one or two packages is about right.

>>[The distinction between "internal" and "external" is in the documentation]
>>...
>>of the application,  but doesn't  help between  modules within  the same
>>package.  You just dont call the internals by virtue of your strength of
>>will and extraordinary discipline!
>
>Exactly. Strength of will and extraordinary discipline. 

It doesn't take extraordinary discipline in anyone with a rudimentary
understanding of software engineering.

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

Because of "ease of use and language protection". Ease of use and
information hiding are orthogonal (and in my biased opinion, inversely
proportional).

>We need language features to help in providing protection and ease of
>use.

Not in Common Lisp. What other language provides DISASSEMBLE as a
standard function?

>
>OK. Here you say that CLOS doesn't enforce any barrier. I agree. Also
>you are right. Lisp isn't into firewalls. This is my complaint.

Strict information hiding insures that only the original developers
can debug and improve the code. That's not a desirable state of affairs.
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters