In reading the different posts on whether CLOS should have support for
information hiding or not and how that should be implemented a
language with a similar situation comes to mind. That language is
Ada95. Let me explain, and keep in mind that it has been a while
since I have messed with it so I may be getting it wrong, like that
would be a first.
For those who don't know or are only familiar with its older sibling
Ada95 has an object system based on "tagged types" which allow for
single inheritance, dynamic dispatch and all the standard OO features.
However, there is no concept of information hiding included in these
types. All of the issues of information hiding and accessibility are
controlled by the package system, which is just a wee bit more
complicated that that in common lisp ;-). A package has an exported
interface and a private implementation, nothing too unusual there.
Packages are also arranged in a hierarchy where children have special
access privileges with respect to their parents. Using this system
you can get the private, protected, and public slots of C++ by simply
constructing the class-package hierarchy properly. In addition all of
the ugliness of friend classes is removed. This does not even scratch
the surface of what can be done with the Ada package system, but I
haven't the space to ramble on forever...
Back when I was reading the stuff coming from the Ada95 people about
this it really seemed to make sense and provide an elegant solution.
It is interesting how the solutions that have come out of the
different programming communities (Lisp, Ada and C) to OOifying there
languages all reflect their original strengths and basis. Ada has
always had a strong concept of code modularity and information hiding,
so they were simply able to fit classes into their old framework with
little problem. I won't say anything about C++ as this is a family
newsgroup. But it is clear how all was sacrificed at the alter of
execution speed (on a PDP-11). And the Lisp crowd went the route of
dynamicism and flexibility. We all have something different to show
for our efforts and we should look closely at the others and see what
they may have hit upon, and STEAL IT!
In my opinion, I think that the Lisp community may actually benefit
more from a revamped package system with more of the power and
convenience of Ada's than introducing the concept of private slots
into CLOS. Because that really addressees the problems that we are
concerned with, Information Hiding and Code Modularity, which is
really orthogonal to issues of polymorphism and inheritance.
Another benefit of such a system is more but smaller packages. For
instance I was recently working on a grapher and I would have loved to
be able to just use the GRAPH:DISPLAY:GIF package which only exported
the symbols relevant to generating the gif file and not all the other
stuff that is really important to someone but not me. (I know that I
can import the symbols one at a time but that isn't the point.)
I understand that there are several issues surrounding implementing
such a thing but does anyone else think such a system may be worth the
effort? Or have I just gone off my rocker?
-Eric
From: Scott L. Burson
Subject: Re: A different package system? (was Re: Hiding in CLOS)
Date:
Message-ID: <3549810A.13728473@ricoqchet.net>
Barry Margolin wrote:
>
> Zetalisp (aka Lisp Machine Lisp) had a hierarchical package system.
It did? Odd -- I don't recall anything about this. Maybe I never
noticed. Anyone have a Chine Nual?
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
In article <·················@ricoqchet.net>,
Scott L. Burson <·····@ricoqchet.net> wrote:
>Barry Margolin wrote:
>>
>> Zetalisp (aka Lisp Machine Lisp) had a hierarchical package system.
>
>It did? Odd -- I don't recall anything about this. Maybe I never
>noticed. Anyone have a Chine Nual?
Amazingly, I still do! Section 23.10 Subpackages describes this. It gives
an example of two packages under GLOBAL (the predefined, top-level
package): MACSYMA and OWL, and each has its own INPUT subpackage.
However, Zetalisp didn't have the distinction between internal and external
symbols. It looks like the package hierarchy served this purpose in a
limited fashion -- a package inherits everything from its parent, but can
shadow locally (the function INTERN-LOCAL would intern in the current
package, ignoring the superpackages). There was the concept of "externing"
a symbol in a subpackage; this is a declaration that the subpackage will
redefine the symbol, but the superpackage is expected to intern it in the
first place (e.g. the declaration of the SYSTEM-INTERNALS package might
contain (EXTERN CAR CDR CONS ...)
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Scott L. Burson
Subject: Re: A different package system? (was Re: Hiding in CLOS)
Date:
Message-ID: <354A1EA1.500F9F30@ricoqchet.net>
Barry Margolin wrote:
> (the function INTERN-LOCAL would intern in the current
> package, ignoring the superpackages). There was the concept of "externing"
> a symbol in a subpackage; this is a declaration that the subpackage will
> redefine the symbol, but the superpackage is expected to intern it in the
> first place (e.g. the declaration of the SYSTEM-INTERNALS package might
> contain (EXTERN CAR CDR CONS ...)
Ah yes, okay, I do remember this very vaguely now. There was
INTERN-LOCAL and INTERN-LOCAL-SOFT.
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
As far as I understand the ADA95 package system, it seems to me that
it would be a rather trivial extension to CL to support a similar
concept of hierarchical packages. Right now you can
already simulate hierarchical packages in CL as far as you accept some
naming conventions. E.g. you can write the example in Eric Dalhman's
post as
graph.display.gif:show-gif
or
graph/display/gif:show-gif
where "SHOW-GIF" is the actual symbol in the "GRAPH.DISPLAY.GIF"
package, and you have the following set of definitions
(defpackage "GRAPH" ...)
(defpackage "GRAPH.DISPLAY" (:use "GRAPH")
(:export <symbols inherited from "GRAPH">) ...)
(defpackage "GRAPH.DISPLAY.GIF" (:use "GRAPH.DISPLAY")
(:export <symbols inherited from "GRAPH.DISPLAY">) ...)
of course you are missing a lot w.r.t. a true hierarchical package
system like ADA95 or Java. But the two major problems are, IMHO,
- reader support. You cannot easily say
(use-package "GRAPH")
(display.gif:show-gif ...)
without some major automatic symbol consing.
- automatic inheritance and selective exporting (i.e. "protection") of
symbols across package 'use' hierachies.
The reader problem is IHMO the most serious one.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Marco Antoniotti <·······@galvani.parades.rm.cnr.it> writes:
> As far as I understand the ADA95 package system, it seems to me that
> it would be a rather trivial extension to CL to support a similar
> concept of hierarchical packages. Right now you can
> already simulate hierarchical packages in CL
> ..of course you are missing a lot w.r.t. a true hierarchical package
> system like ADA95 or Java. But the two major problems are, IMHO,
> - reader support. You cannot easily say
> (use-package "GRAPH")
> (display.gif:show-gif ...)
> - automatic inheritance and selective exporting (i.e. "protection") of
Without support for these problems, I don't see much point of having
a hierarchical package system.
I want to have a package with user-accessible code in it,
and then a package that is the administrator-accessible code,
which inherits ALL the user-accessible code.
The big problem with the package system is that it operates
at "read time", which produces unexpected behavior since
the state of the package system is changed before any code
is actually executed or compiled.
The only reliable way to deal with packages is to set them all up
in a static way before doing anything.
One learns quickly to reboot the lisp whenever working with packages.
This just doesn't seems like the right way to operate.
-kelly murray ···@franz.com
Kelly Murray <···@franz.com> writes:
> Marco Antoniotti <·······@galvani.parades.rm.cnr.it> writes:
> > system like ADA95 or Java. But the two major problems are, IMHO,
> > - reader support. You cannot easily say
> > (use-package "GRAPH")
> > (display.gif:show-gif ...)
> > - automatic inheritance and selective exporting (i.e. "protection") of
>
> Without support for these problems, I don't see much point of having
> a hierarchical package system.
>
> I want to have a package with user-accessible code in it,
> and then a package that is the administrator-accessible code,
> which inherits ALL the user-accessible code.
>
> The big problem with the package system is that it operates
> at "read time", which produces unexpected behavior since
> the state of the package system is changed before any code
> is actually executed or compiled.
>
> The only reliable way to deal with packages is to set them all up
> in a static way before doing anything.
> One learns quickly to reboot the lisp whenever working with packages.
> This just doesn't seems like the right way to operate.
I agree. I never muck with packages in my code (at least I never
found it necessary to do so). I.e. I set up my packages "statically".
There is no free lunch. I'd be contented with an extension to the
reader in order to support a limited version of hierarchical packages,
than to work out a fully dynamic solution.
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it