In article <··········@ARTEMIS.cam.nist.gov> ······@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 ·····@coyote.trw.com
In article <·············@wilbur.coyote.trw.com> ·····@wiley.UUCP (Scott Simpson) writes:
>In article <··········@ARTEMIS.cam.nist.gov> ······@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 ·····@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
-John Waters
In article <·····················@hellgate.utah.edu> ··················@cs.utah.edu (Tim Moore) writes:
[...] I think it's great that data structures are exposed in Lisp,
if only to satisfy my own curiosity. [...] Strict information
hiding insures that only the original developers can debug and
improve the code.
There is another, more basic, reason that lisp folks have not in
general gone in for strict information hiding, i.e. with no escape
hatches like the double-colon. That is because lisp has been almost
exclusively used with interactive programming environments for quite a
while now. Code trying to access a non-exported variable of some
package may be due to a programmer "cheating" on the modularization of
the program, but it MAY simply be a programmer typing to a
read-eval-print loop trying to figure out what is happening with his
program. The only way a programmer has to interact with his running
system is to cause expressions to be eval'ed. If there is no way for
an *expression* to access something, then there is no way for the
*programmer* to access it during debugging. (I know, accessing stack
frames in Common Lisp appears to be an exception, but that was a
compromise for the sake of allowing a variety of underlying
implementation methods.)
--
Lou Steinberg
uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
internet: ···@cs.rutgers.edu
In article <·····················@hellgate.utah.edu> ··················@cs.utah.edu (Tim Moore) writes:
>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)) :-)
I don't think that back doors aren't useful, I am just concerned about
them being the default.
>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.
I don't think grep is a great way to discover name collisions! Surely
we can come up with something better. Browsers perhaps?
>Because of "ease of use and language protection". Ease of use and
>information hiding are orthogonal (and in my biased opinion, inversely
>proportional).
Not necessarily. I see your point but I am not so black and white on
the issue.
In article <···@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>If you expect packages to give you the same capabilities you
>have in Eiffel or Ada, you are bound to be disappointed.
Yes. I have come to this conclusion. Since I don't want to beat a dead
horse, I will drop this thread after this message.
--
Scott Simpson TRW ·····@coyote.trw.com
From: Bruce R. Miller
Subject: Re: Common Lisp Package System Considered Harmful
Date:
Message-ID: <2865277201@ARTEMIS.cam.nist.gov>
In article <·············@wilbur.coyote.trw.com>, Scott Simpson writes:
> In article <··········@ARTEMIS.cam.nist.gov> ······@cam.nist.gov writes:
> ...
> 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.
As far as I know, that's exactly what they're for.
> 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.
Just because packages doesn't solve the particular problem of the moment
doesn't mean they're not useful. I would miss them.
> I don't know if I agree that CLOS deals
> with information hiding. How do you mean?
Exactly in this sense:
> >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. ...
Well, I dont mind it a bit. Double colons are noticable to me. I surely
notice when I type them in! Ditto slot-value. And although given what
Lisp is, it would surely introduce inefficiencies to try to introduce
firewalls, I seriously doubt that that has anything to do with the lack
of them. Who wants them? (besides you I mean :> )
> >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?
? I ALWAYS use packages -- I just dont find myself needing to use more
than 2 in any given app. I find them useful for just what I said:
separating applications and gross layers within an application.
> > ... 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.
Why? Besides, I like being virtuous!:>
> 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.
FMHT (for my humble tastes), I think you go a bit too far here.
> >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.
Emphasis on ENFORCE. I guess if you REALLY want that much of a barrier,
you've just got to use a multitude of packages and a multitude^2 of
exports and not USE the packages within each other. You've got to say
what is OK and not OK anyway -- what's wrong with export?
> I think most Lisp users suffer in the same way.
> Scott Simpson TRW ·····@coyote.trw.com
I'm certainly not `most' but I'm not suffering.
bruce
-
-
-
-
--
-
- dumb posting software
-
-
-
-
-
-
In article <·············@wilbur.coyote.trw.com> ·····@wiley.uucp (Scott Simpson) writes:
From: ·····@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 ·····@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.
From: Daniel A Haug
Subject: Re: Common Lisp Package System Considered Harmful
Date:
Message-ID: <388@shrike.AUSTIN.LOCKHEED.COM>
Last year, we completed a project that involved several hundred thousand
lines of CLOS-intensive Lisp code. Just guessing, I'd say that we had
around 1000 classes, and perhaps 2000 generic functions. We used the
package system to isolate layered functionality. For example, the
CLOS-based window system was in one package, the CLOS-based user-interface
management system was in another package, the CLOS-based communications
system in yet another. You get the idea.
In each system, public class slots were exported. So were public interface
functions. Private slots and functions were not exported. No big deal.
Also, I didn't understand the earlier comment about how defclass generates
all of these other hidden functions (?). I do not know what functions
outside of the CLOS-specified functions are generated.
(defclass a ()
((b :initform nil
:accessor a-b)))
This only generates one new method: a-b. All of the other functions are
part of the CLOS spec (e.g. make-instance, initialize-instance, slot-value).
Now back to how one would use our system: If I were then writing an
application that would use the communications system, the window system,
and the UIMS, then I would create my own application package that uses
those packages:
(make-package :my-application
:use '(:common-lisp
:clos
:window-system
:uims
:communications))
Then my application package would inherit all of the public slots and
interfaces from these subsystems. Then suppose that the window-system
has class BASIC-WINDOW with public slot BACKGROUND-COLOR, and that
all of my application windows will have blue background colors (back
in the old pre-X days of hardcoded display preferences ;-), I would write:
(defclass my-app-window (basic-window)
((background-color :initform :blue)))
Thus, it is fairly easy to generate subclasses based on public (read: exported)
class information. I have not violated object boundaries. My application
window class doesn't interfere with other users of :window-system.
Now, in practice, since we had such a large system, this approach worked
well 99% of the time. Occasionally we had name conflicts arise within
the package. No big deal... find it and resolve it. Also, we would have
occasional package conflicts, two subsystem packages exporting similar
symbol names. Again, no big deal, just choose the desired symbol to inherit,
and shadow the others. Or, don't use :USE-PACKAGE at all:
(defclass my-app-window (window-system:basic-window)
((window-system:background-color :initform :blue)))
To me, there is flexibility to suit many approaches to this.
From article <·············@wilbur.coyote.trw.com>, by ·····@wiley.uucp (Scott Simpson):
>
> [...] 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?
No! We would have DIED in our project without the package system. We
probably had 50 packages in the end. I can't begin to imagine life
without the package system! Having done a substantial amount of work
in C, which has no real namespace support (other than: everyone gets it,
or no-one outside of this file gets it), I am very appreciative of
languages that provide such a facility (e.g. Lisp, Ada, Modula-II,...).
In C, one is forced to use implicit namespace dividers by prepending
a pseudo-system name on each symbol (e.g. Xt, X, Xm, Xaw,...) which
is pretty ridiculous (IMHO).
My only serious gripe about the package system is the inability (within
pure CL) to lock a package. In our project, we had a few inexperienced
engineers who would develop the window-system side of their application
in the window-system package. As their application would be loaded
late into the lisp world, their additions to the window-system package
would suddenly be inherited by all other users of the window-system,
and everyone would indubitably lose. A nice safeguard would have been
to lock the window-system package after that system had been loaded.
Finally, to summarize my posting: We had success by using packages
to isolate subsystems, including class definitions and methods. As we
usually had only one or two people working on a system, name-conflicts
rarely arose. Public vs. Private class information was accomplished
via exporting symbols.
dan haug
--
Internet: ····@austin.lockheed.com
UUCP: ut-emx!lad-shrike!aihaug
Phone: (512) 448-5634
In article <·············@wilbur.coyote.trw.com> ·····@wiley.uucp writes:
>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.
Yup, that's it. To give an example of how packages are so usefull,
look at Interlisp, which had no packages. The convention that everyone
used was, to quote from a truly ancient mail message to 1100Users:
>Date: 18 FEB 84 18:31 PST
>From: ········@PARC-MAXC.ARPA
>Subject: RE: Flame topic: Naming Conventions and Packages
>To: ·········@SUMEX-AIM.ARPA
>cc: ········@PARC-MAXC.ARPA
>
> I would encourage the following convention. Atoms in a package
>used for function names, property names, or as global variables should
>have the form P.FOO or \P.FOO where P is a nontrivial (>= 3 chars)
>prefix.
.
.
.
> Slash with "\" any function name, property name,
>or global variable whose casual redefinition via DEFINEQ, PUTPROP, or
>SETQ (you get the idea) would crash the user.
Read module for package above, since the message predates the current
use of package. Believe me, having packages is a whole lot better than
the other option. Doing an apropos on something like OPEN under Medley
yeilds FB.OPEN, TCP.OPEN, CHAT.OPEN, etc. It's interesting to see that
some people are even using pseudo-packages in Emac's Elisp, by
prefixing their code with package-name:variable (Franz's lisp-emacs
interface comes to mind). Most lisps are really whole environments,
and you really don't want to clobber yourself by redefining something
as innocuous as VERIFY, for example, if it was used by the memory
management system. IL programmers generally went to great pains so
that casual users didn't redefine important symbols, and having a
package boundary with import and export is much simpler. I'd suspect
that most IL programmers have trashed the environment at least once by
not being careful enough, and having to reload and/or recreate your
work isn't fun.
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
·····@cis.ohio-state.edu