>>>>> On 12 May 93 21:07:26 GMT, ········@di.epfl.ch (Fernando Mato Mira) said:
> Isn't this missing from Common Lisp? I mean, in order to
> encapsulate my classes, I enclose each of them in their own
> package. That means you can easily be throwing 300 packages or
> more into somebody else's system. OK, prepend every class package with
> the main package name, and it should be OK, but what about the poor
> fellow when he does (list-all-packages) after loading a couple of
> libraries built this way? Does he want to see all those lines of irrelevant
> implementation-dependent names? (He should be able to, somehow, if he wants).
I agree. Having hierarchical packages would be nice, in particular to
make it easier to integrate software from diverse sources.
In order to make this work, you need some new construct similar to
IN-PACKAGE, but a construct that nests. Maybe BEGIN-PACKAGE and
END-PACKAGE?
Thomas.
In article <·················@arolla.idiap.ch>, ···@arolla.idiap.ch (Thomas M. Breuel) writes:
>
> I agree. Having hierarchical packages would be nice, in particular to
> make it easier to integrate software from diverse sources.
>
> In order to make this work, you need some new construct similar to
> IN-PACKAGE, but a construct that nests. Maybe BEGIN-PACKAGE and
> END-PACKAGE?
>
Hmm. There are other problems also. Maybe tracing them all first would help in defining this...
First, you qualified symbols should be traced to the right package by the reader.
Let's say (for backward compatibility purposes) that all toplevel packages are accesible in
every toplevel package by default.
Let's say we have toplevel packages :FOO and :BAR, and that a symbol Z is in FOO, then
'FOO::Z evaluates in BAR to the :FOO::Z symbol
Now, if we define a subpackage of BAR named FOO (eg: via a (:subpackage t) argument to defpackage), we
would normally want 'FOO::Z to evaluate in BAR to :BAR:FOO::Z. But how do we access the other Z?
Should we say by writing ':FOO::Z? This is not a valid expression under the current CL spec, so it would
cause no problem with old programs. This could be syntactically clean if we think that we are referring
to the external symbol FOO in the null root package (we can think that the symbols
corresponding to all "toplevel" packages are automatically exported from the null root package).
Now, for IN-PACKAGE, according to the current state of things, the argument should be a keyword or a string,
but not a quoted symbol. The "keyword concept" could be generalized to symbols.
(Also, we could use quoted symbols to perform the package search in order to be consistent with
implementations raising only warnings in this case).
When evaluating (in the :BAR package)
(in-package 'foo) will put you in the :FOO package when there is not a subpackage named FOO in :BAR
and
(in-package 'foo) will put you in the :BAR:FOO package when there is a subpackage named FOO in :BAR
If an implementation currently gives an error in the first case, all old correct programs should work
properly becasuse they never use quoted symbols as args to IN-PACKAGE.
If an implementation raises only a warning, but puts you in the appropriate package, old programs should
run unmodified as they do not make use of subpackages, an all incorrect (but accepted) forms are of the
first type.
Of course, for absolute paths, it should be possible to say something like (in-package :BAR:FOO), and if the absolute pathname
extension for symbols is taken, why not (in-package ':BAR:FOO)?
Now, I just realized that the null root package looks like the KEYWORD package, so (in order to be backward
compatible and clean):
:FOO:Z denotes a symbol by an absolute pathname, so it should be equivalent to FOO:Z when there is
not a subpackage FOO at the point of the evaluation. FOO:Z is not a keyword, then
KEYWORDS ARE THE TOP-LEVEL SYMBOLS OF THE HIERARCHY
Then, :BAR:FOO is a symbol, and
(in-package :BAR:FOO) should be legal
as well as (in-package FOO) when a subpackage named foo exists (To be consistent with the symbol search meachanism,
it should also be accepted probably in a toplevel package to refer to :FOO when a subpackage with that name does not
exist. The problem is that it establishes an ugly difference between top-level and non-top-level packages. The
only clean way I see is providing some sort of package mapping inheritance with overriding, for example:
given the packages:
:FOO
:FOO:FOO
:FOO:FOO:BAZ
:BAR
evaluating (in-package FOO)
in puts you in
:FOO :FOO:FOO
:FOO:FOO :FOO:FOO
:FOO:FOO:BAZ :FOO:FOO
:BAR :FOO
Now all that we need is a notation (a la ".." of Unix directories) to refer to the parent in a relative way.
--
Fernando D. Mato Mira
Computer Graphics Lab "There is only one Language
Swiss Federal Institute of Technology and McCarthy is its prophet"
········@di.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed_point_disclaimer(H,DH),
disclaim(T,DT).
fixed_point_disclaimer(Text,fixed_point_disclaimer(Text,_)).