Path: utzoo!utgpu!watserv1!watmath!att!att!dptg!ulysses!andante!mit-eddie!mintaka!olivea!samsung!uakari.primate.wisc.edu!sdd.hp.com!usc!trwind!gumby!wiley!scott
From: scott@wiley.uucp (Scott Simpson)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp Package System Considered Harmful
Summary: I'm not convinced.
Keywords: Packages, CLOS, Object-Oriented Programming, Common Lisp
Message-ID: <271E0D40.451E@wilbur.coyote.trw.com>
Date: 18 Oct 90 20:14:56 GMT
References: <271CDC30.1E54@wilbur.coyote.trw.com> <2865200060@ARTEMIS.cam.nist.gov>?<2298@heavens-gate.lucid.com>?<271BA6D1.5B83@wilbur.coyote.trw.com>
Sender: news@wilbur.coyote.trw.com (News Software)
Reply-To: scott@wiley.UUCP (Scott Simpson)
Organization: TRW Inc., Redondo Beach, CA
Lines: 76

In article <2865200060@ARTEMIS.cam.nist.gov> miller@cam.nist.gov writes:
>I think that CLOS & Packages are two mechanisms with different scales
>and intents.  And although they both seem to deal with `information
>hiding' they deal with it in quite different ways.  

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. I don't know if I agree that CLOS deals
with information hiding. How do you mean?

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

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

>On the other hand, it  is my impression that  with CLOS (I haven't  done
>much CLOS yet, but I have done a  lot with Flavors --- I think it's  the
>same as far as this discussion is concerned) one differentiates  between
>the `external' and `internal' interface to a class of objects simply  by
>saying so!  That is, the developer announces that these are the routines
>to use.  Any other routines are for internal use only.  Packages help in
>so far as it helps (loosely)  enforce that distinction to users  outside
>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. 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.

>As you've seen,  using too  many packages  within the  same program gets
>hairy.  But, I dont think that CLOS really attempts to enforce any  kind
>of barrier, and packages  seems to be  at the wrong  level for what  you
>want --- lisp itself isn't really into firewalls in any case.

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.

>A trick  I've  used  with  some  satisfaction  --  as  a reminder, NOT a
>firewall -- is  to document,  literally, the  `documented interface'  by
>giving a  documentation  string  (where  appropriate).   If I'm in doubt
>about invoking a function in a particular piece of code, If m-sh-D gives
>me documentation, I  figure it's  OK, otherwise  probably not.   --- OK,
>it's far from perfect, just an idea.

I think most Lisp users suffer in the same way.
Scott Simpson			TRW			scott@coyote.trw.com