Finished section on shadowing.
This commit is contained in:
Gerd Heber
parent
7df5bb41ab
commit
ef2b97c65a
@ -1624,3 +1624,424 @@
|
||||
The function [[http://clhs.lisp.se/Body/f_shadow.htm][=shadow=]] takes a symbol name (or a list of symbol names) and a
|
||||
package name, allocates a symbol with this name if it is not /present/ in
|
||||
this package, and records it in the shadowing list of the package.
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(shadow "SYMB6" "P1")
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(package-shadowing-symbols "P1")
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(export (intern "SYMB6" "P2") "P2")
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(eq 'symb6 'p2:symb6)
|
||||
#+END_SRC
|
||||
|
||||
Once the symbol =p1::symb6= is on the shadowing-list of ="P1"= the existence
|
||||
of a different external symbol with the same name in the used package ="P2"=
|
||||
does not generate a name conflict. The last =eq=-test proves both symbols are
|
||||
really different. Along the same lines, the function [[http://clhs.lisp.se/Body/f_shdw_i.htm][=shadowing-import=]], as
|
||||
clearly indicated in its name, imports a symbol and immediately adds it to
|
||||
the shadowing list, which could resolve a possible name conflict. For example
|
||||
the *different* symbols =p2:symb4= (external in ="P2"=) and =p3::symb4=
|
||||
(internal in ="P3"=) are in our environment; the package ="P1"= uses both
|
||||
packages ="P2"= and ="P3"=, but =p3::symb4= is internal in ="P3"= and
|
||||
therefore not in conflict with =p2::symb4=. Remember also the current default
|
||||
package is ="P1"=. A simple importation of =p3::symb4= in ="P1"= generates a
|
||||
conflict, while a =shadowing-import= adds the imported symbol to the
|
||||
shadowing list, shadowing the symbol =p2:symb4= and resolving the name
|
||||
conflict.
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list (find-symbol "SYMB4" "P2"))
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list (find-symbol "SYMB4" "P3"))
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list
|
||||
(ignore-errors
|
||||
(import 'p3::symb4 "P1")))
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(shadowing-import 'p3::symb4 "P1")
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(package-shadowing-symbols "P1")
|
||||
#+END_SRC
|
||||
|
||||
If necessary, =p2:symb4=, shadowed by the internal =symb4= in ="P1"=, remains
|
||||
accessible via the colon notation. The evaluations of the following
|
||||
expressions assign the same symbol value to both symbols as is confirmed by
|
||||
the subsequent '=' form. Evaluating the next =eq= expression proves that
|
||||
both /symbols/ are different. In contrast, because =p1::symb4= was imported
|
||||
from ="P3"=, the last =eq=-test is affirmative.
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(defvar symb4)
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(defvar p2:symb4)
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(setf symb4 (setf p2:symb4 111))
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(= symb4 p2:symb4)
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(eq 'symb4 'p2:symb4)
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(eq 'symb4 'p3::symb4)
|
||||
#+END_SRC
|
||||
|
||||
It is even possible to add an /inherited/ symbol to the shadowing list, maybe
|
||||
to declare a precedence with respect to another future competing symbol in
|
||||
another package intended to be used later. This experiment assumes three
|
||||
different packages, where one of them is not yet used. We first "detach" for
|
||||
example the package ="P3"= from ="P1"=, leaving ="P2"= used by ="P1"=.
|
||||
(Remember ="P1"= is the current default package.)
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(unuse-package "P3" "P1")
|
||||
#+END_SRC
|
||||
|
||||
We then install two new external symbols with the same name in ="P2"= and
|
||||
="P3"=:
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(export (intern "SYMB7" "P2") "P2")
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(export (intern "SYMB7" "P3") "P3")
|
||||
#+END_SRC
|
||||
|
||||
As we have seen already with essentially the same example, if ="P1"= now
|
||||
decides to use ="P3"=, the two ="SYMB7"= symbols collide:
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list
|
||||
(ignore-errors
|
||||
(use-package "P3" "P1")))
|
||||
#+END_SRC
|
||||
|
||||
In some context, it could happen that ="P1"= has no reason to use =p3:symb7=
|
||||
directly, and instead would like to give precedence to =p2:symb7=. This can
|
||||
be achieved with a shadowing import.
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list (find-symbol "SYMB7" "P1") )
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(shadowing-import 'symb7 "P1")
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(use-package "P3" "P1")
|
||||
#+END_SRC
|
||||
|
||||
The =shadowing-import= refers to =p2:symb7= implicitly, which is external in
|
||||
a package used by ="P1"= and therefore inherited by ="P1"=. We see how the
|
||||
use of =shadowing-import= solves the name conflict, which otherwise would be
|
||||
raised by =use-package=. Let us review our symbols as seen now from our three
|
||||
packages:
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list (find-symbol "SYMB7" "P1"))
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list (find-symbol "SYMB7" "P2"))
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(eq 'symb7 'p2:symb7)
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(multiple-value-list (find-symbol "SYMB7" "P3"))
|
||||
#+END_SRC
|
||||
|
||||
#+BEGIN_SRC lisp :session pcl :package "P1" :exports both :results value verbatim
|
||||
(package-use-list "P1")
|
||||
#+END_SRC
|
||||
|
||||
The statuses of =symb7= have not changed in ="P2"= and ="P3"=, but seen from
|
||||
="P1"=, the symbol is now /internal/. This is to satisfy the rule that any
|
||||
shadowing symbol in a package must be internal or external in this package,
|
||||
and also a consequence of the implied importation.
|
||||
|
||||
* A mathematical definition of the packaging system.
|
||||
|
||||
We recall that there are three general sets we must study:
|
||||
|
||||
- The set $St$ of /strings/
|
||||
- The set $P$ of /packages/
|
||||
- The set $Sm$ of /symbols/
|
||||
|
||||
There is one important difference: the set $St$ is the /infinite/ set of all
|
||||
the possible strings, while $P$ and $Sm$ are /finite/ sets made of the
|
||||
packages and symbols previously /allocated/ in the current Lisp session.
|
||||
|
||||
We use the notations $pn$ to denote the function =package-name=
|
||||
$pn: P \rightarrow St$ and $sn$ to denote the function =symbol-name=
|
||||
$sn: Sm\rightarrow St$.
|
||||
|
||||
The map $pn$ is /injective/ for the packages; the function
|
||||
$pn: P \rightarrow pn(P)$ defines a 1-1 correspondence between the packages and their respective names. Here, we ignore the potential nicknames of a package, which is not essential for our discussion.
|
||||
|
||||
Every package $P$ contains four /fundamental/ lists:
|
||||
|
||||
- The list $InS(P)$ of its internal symbols
|
||||
- The list $ExS(P)$ of its external symbols
|
||||
- The list $ShgS(P)$ of its shadowing symbols
|
||||
- The list $U(P)$ of its used packages
|
||||
|
||||
More precisely, these lists are lists of /pointers/ to the mentioned objects,
|
||||
or, if you prefer, of the machine addresses of these objects. It is important
|
||||
to understand these lists are made of (pointers to) /symbols/, not of their
|
||||
names. Each of these lists is /without any duplicates/.
|
||||
|
||||
The fundamental lists defined in a package are the source of a relatively
|
||||
extensive terminology, which is detailed now. The set of symbols /present/ in
|
||||
a package $p$, denoted by $PrS(p)$, is defined as the union
|
||||
$PrS(p) := InS(p) \cup ExS(p)$: a symbol is present in a package if it is
|
||||
internal or external in this package. This union is /disjoint/, the
|
||||
intersection $InS(p) \cap ExS(p)$ must be empty. Also the relation
|
||||
$ShgS(P) \subset Pr(P)$ is required. A shadowing symbol of the package $p$
|
||||
must be internal or external in this package, i.e., a shadowing symbol is
|
||||
present.
|
||||
|
||||
Let $q$ be a package used by the package $p$. The symbols of $q$ /shadowed/
|
||||
by a symbol of $p$ are:
|
||||
$$
|
||||
ShdS(q, p) = \{sm \in ExS(q)\;\mathbf{\underline{st}}\;\exists sm' \in ShgS(p)\;\mathbf{\underline{st}}\; sn(sm) = sn(sm')\}
|
||||
$$
|
||||
|
||||
In other words, a /precedence/ relation is defined by the list $ShgS(p)$: if
|
||||
ever a symbol $sm' \in ShgS(p)$ and a symbol $sm\in ExS(q)$ have the same
|
||||
name, then, with respect to the package $p$, $sm'$ takes precedence over
|
||||
$sm$, which means $sm$ is /shadowed/. If $sm'$ is present in $p$ but not
|
||||
shadowing, with $sm'\neq sm$ and $sn(sm') = sn(sm)$, then a name conflict
|
||||
would be raised, which is forbidden.
|
||||
|
||||
The inherited symbols of a package $p$, denoted by $InhS(p)$, are defined as:
|
||||
$$
|
||||
InhS(p) := \Big\{ \bigcup_{q\in U(P)}(ExS(q) − ShdS(q,p)) \Big\} − PrS(P)
|
||||
$$
|
||||
|
||||
A symbol is inherited in a package $p$ if it is external in a /used/ package
|
||||
$q$, not shadowed by a shadowing symbol of $p$, and not present in $p$. The
|
||||
union in the preceding formula is not necessarily disjoint: a symbol can be
|
||||
external in several packages simultaneously, and without causing a name
|
||||
conflict. A symbol could be simultaneously present in $p$ and external in a
|
||||
package $q$ used by $p$. That is why the the last term, $−PrS(P)$, is
|
||||
necessary to define unambiguously what an inherited symbol is.
|
||||
|
||||
Finally the accessible symbols $AccS(p) := PrS(p) \cup InhS(p)$ are the
|
||||
symbols which are present or inherited. The very definition of $InhS(p)$
|
||||
implies that this union is disjoint. In this way, the /status/ of a symbol
|
||||
with respect to a package $p$ via which it is accessible is unambiguously
|
||||
defined as a keyword =:internal=, =:external= or =:inherited=. For a package
|
||||
$q\neq p$ there is no relation whatsoever between the status of some symbol
|
||||
$sm$ with respect to $p$ and its status with respect to $q$.
|
||||
*Exercise:* Show that the sixteen pairs of possible status combinations can
|
||||
be realized!
|
||||
|
||||
It is important to be clear about possible intersections (overlaps) between
|
||||
the lists defined above. Let $p$ be some package and $q$ another package used
|
||||
by $p.$ If $sm\in ExS(q)$ is an external symbol of $q$, the symbol $sm$ /may/
|
||||
also be present in $p$, in which case its status is internal or external, but
|
||||
not inherited. In particular, this does not generate a name conflict, because
|
||||
it is the same symbol which is visible in two different packages via the same
|
||||
name, and a symbol has only /one/ name! Nevertheless its status /with respect
|
||||
to/ $p$ is not inherited. The status of a symbol is so defined
|
||||
deterministically, even if it is present in two interacting packages by one
|
||||
using the other. Of course the same symbol has status external in $q$.
|
||||
|
||||
Following the same logic, if $q,q'\in U(p)$, the intersection
|
||||
$ExS(q)\cap ExS(q')$ is not necessarily empty.
|
||||
|
||||
The Lisp system maintains the /coherence/ of these lists, which is defined as
|
||||
follows:
|
||||
|
||||
*Definition.* A set of packages is /coherent/ if, for every package $p$, the
|
||||
function =symbol-name= defines a 1-1 correspondence
|
||||
$sn: AccS(p) \rightarrow sn(AccS(p))$.
|
||||
|
||||
This map is by definition surjective; it is injective if two different
|
||||
symbols accessible via $p$ have different names. In this way the function
|
||||
=find-symbol= is free of ambiguity. It searches first in the present symbols,
|
||||
and finally in the external symbols of the used packages. It is not necessary
|
||||
to compute the list of shadowed symbols since a shadow/ing/ symbol, which is
|
||||
also a present symbol, is found first. The main purpose of the coherence rule
|
||||
is to prevent users from designing too contorted situations in name scopes,
|
||||
wich are frequently the source of subtle and difficult to find bugs.
|
||||
|
||||
Several symbols with the same name may coexist in an environment. The most
|
||||
common way to access a symbol consists in using its /name/, but /different/
|
||||
symbols may have the /same/ name. In fact, its symbol name is not sufficient
|
||||
to access a symbol, a package must also be specified. This can be the default
|
||||
package, in which case the direct notation without any colons is possible, or
|
||||
the package name can be explicitly used to prefix the symbol name using the
|
||||
one- or two-colon notation. Of course, the symbol so accessed must be defined
|
||||
in a /deterministic/ manner. The definition just given says that a /unique/
|
||||
symbol of some name is accessible from some package.
|
||||
|
||||
The main function in the packaging organization is a map:
|
||||
$$
|
||||
\rho:P \rightarrow [St \rightarrow ((Sm\cup\mathtt{nil})\times Stt)]
|
||||
$$
|
||||
where $Stt$ is a constant set of four symbols, the Lisp symbol =nil=, and
|
||||
three keywords, the possible statuses of an accessible symbol:
|
||||
$$
|
||||
Stt = \{\mathtt{nil}, \mathtt{:internal}, \mathtt{:external}, \mathtt{:inherited}\}
|
||||
$$
|
||||
Because of the assumed coherence of the package configuration, the function
|
||||
$\rho$, an avatar of the function =find-symbol= of a package $p$ and a string
|
||||
$st$, determines a /unique/ symbol named $st$ and accessible via $p$, and
|
||||
also its status. It is possible that the search fails, in which case the
|
||||
function returns the pair =(nil,nil)=. (More precisely =(values nil nil)=.)
|
||||
The second =nil= is a kind of a null status: "There is nothing accessible via
|
||||
$p$ under the name $st$." The relation
|
||||
$\rho(p)(s) = \mathtt{(find-symbol}\;p\;st\mathtt{)}$ is always satisfied.
|
||||
|
||||
It is now relatively simple to understand the various Lisp functions for
|
||||
handling packages and symbols, in particular what name conflicts might be
|
||||
generated.
|
||||
|
||||
** (intern $st\;p$)
|
||||
|
||||
This function first evaluates =(find-symbol= $st\; p$=)=. If a symbol is
|
||||
found, /both/ values of =(find-symbol ...)= are returned.
|
||||
|
||||
If no symbol is found, then Lisp /allocates/ (creates in memory) a new
|
||||
symbol without any value or function value. The =symbol-package= is
|
||||
initialized to $p$ and this symbol is added to $InS(p)$. In this case,
|
||||
=(values= $sm$ =nil)= is returned, the second value =nil= being a code for
|
||||
saying a new symbol has just been allocated.
|
||||
|
||||
No name conflict can be created this way.
|
||||
|
||||
This function is used implicitly by the Lisp reader when it encounters a
|
||||
symbol in an expression. If the colon syntax is not used, the default
|
||||
package is used for $p.$ Otherwise the (capitalized) package name of $p$
|
||||
preceding the colon(s) is read, followed by the (capitalized) =symbol-name=
|
||||
$st$ after the colon(s). Finally, =(intern= $st\; p$=)= is evaluated, which
|
||||
yields the symbol so /read/ by the Lisp reader. In this way, the symbol can
|
||||
be either a pre-existing one or one freshly allocated as a consequence of
|
||||
this reading.
|
||||
|
||||
|
||||
** (unintern $sm\;p$)
|
||||
|
||||
A symbol $sm$ is /interned/ in a package $p$ if it is present in this
|
||||
package. It is /present/ in package $p$ if
|
||||
$sm\in PrS(p) = InS(p) \cup ExS(p).$ Uninterning a symbol asks for this
|
||||
membership to be "revoked."
|
||||
|
||||
If $sm\notin PrS(p)$, nothing is changed and =nil= is returned. Otherwise
|
||||
$sm$ is removed from $InS(p)$ or $ExS(p)$, and also from $Shg(p)$ if $sm$
|
||||
was shadowing with respect to $p$; in this case, =unintern= returns =t=. In
|
||||
the last case, when uninterning a shadowing symbol, a name conflict can be
|
||||
generated: it is possible for symbols $sm'\in ExS(q)$ and $sm''\in ExS(q')$
|
||||
to have the same name while being /different/ symbols in the respective
|
||||
packages $q$ and $q'$ used by $p$, and that this collision was resolved by
|
||||
the symbol $sm$ shadowing both. If this happens, the =unintern= request is
|
||||
rejected.
|
||||
|
||||
Also, if a symbol $sm$ is uninterned from a package $p$ and $p$ is the home
|
||||
package of $sm$, then the home package of $sm$ is modified and becomes
|
||||
=nil=, that is, the symbol becomes homeless. This is the only case where the
|
||||
symbol itself is modified by =unintern=. The same symbol could be external
|
||||
in another package used by $p$, in which case the symbol /remains/
|
||||
accessible via $p$. Otherwise, if the home package was =nil= or another
|
||||
package, it is not modified.
|
||||
|
||||
** (import $sm\; p$)
|
||||
|
||||
This is a request for the symbol $sm$ to be added to $InS(p)$. Lisp first
|
||||
looks for a possible name conflict. This happens only if a /different/
|
||||
symbol $sm'\neq sm$ with the same name ($sn(sm) = sn(sm')$) is already
|
||||
accessible via $p$. If so, the importation is rejected.
|
||||
|
||||
If no name conflict is detected, Lisp proceeds as follows: If the symbol is
|
||||
already /present/, it is left /unchanged/ in $InS(p)$ or $ExS(p)$. Else, if
|
||||
the symbol is /inherited/ because of a package $q$ used by $p$, $ExS(q)$ is
|
||||
left unchanged and $sm$ is added to $InS(p)$ (not $ExS(p)$!). If $sm$ is not
|
||||
accessible via $p$, it is simply added to $InS(p)$.
|
||||
|
||||
In the specific case of an imported homeless symbol, the =symbol-package= of
|
||||
the symbol is updated to $p$. This is the only case where a symbol object is
|
||||
modified by an importation. If the imported symbol is already owned by a
|
||||
package, whatever its home package, it is not modified.
|
||||
|
||||
If the importation succeeds, the symbol will always be /present/ in the
|
||||
target package, even if it was previously accessible only via a used
|
||||
package.
|
||||
|
||||
** (export $sm\; p$)
|
||||
|
||||
The terminology "export" is not really appropriate, "externalize" would be
|
||||
more precise. The user of an =export= expression asks Lisp to record the
|
||||
symbol $sm$ in $ExS(p).$ This is allowed only if $sm$ is accessible from
|
||||
$p.$ In other words, the =export= function cannot /add/ an accessible symbol
|
||||
to $p.$ In view of the rule $InS(p)\cap ExS(p) = \emptyset$, if present in
|
||||
$InS(p)$, the symbol $sm$ is also erased from that list. If $sm$ is external
|
||||
in a package $q$ used by $p$, its status in $q$ remains unchanged, but $sm$
|
||||
is nevertheless added to $ExS(p)$.
|
||||
|
||||
Remember that the =use-package= relation is not transitive. The fact that
|
||||
$sm\in ExS(q)$ makes $sm$ accessible via $p$ using $q$ but not via $p'$
|
||||
using $p$. If it is desired that $sm$ be accessible via $p'$, it is possible
|
||||
to make it external in $p$ by an =export= expression. Another solution would
|
||||
be to import $sm$ in $p'$, an operation which doesn't involve $p$.
|
||||
|
||||
After exporting it, the symbol $sm$ becomes accessible from any package $q$
|
||||
using $p$, that is, if $p\in U(q)$. This can generate a name conflict with
|
||||
a possible /different/ symbol $sm'$ of the same name, which is present in
|
||||
$q$ or accessible via $q$ in another package $p'\in U(p)$, that is, if
|
||||
$sm'\in ExS(p')$. If this happens, the /export/ request is rejected.
|
||||
|
||||
** (unexport $sm\; p$)
|
||||
|
||||
The symbol $sm$ must be accesible via the package $p.$ If the status of
|
||||
$sm$ is /external/, it is downgraded to /internal/. Otherwise it remains
|
||||
unchanged, even if it is /inherited/.
|
||||
|
||||
** (shadow {$sm$ or $st$} $p$)
|
||||
|
||||
It is intended to /import/ the symbol $sm$ in $p$, to record it in the
|
||||
shadowing list $Shg(p)$ of the package $p$, and also to /resolve/ any name
|
||||
conflict possibly raised by the importation.
|
||||
|
||||
This time the first argument must be a /symbol/, a pre-existing one or a
|
||||
symbol just allocated because of its presence in the source statement. The
|
||||
symbol is imported (See the function =import=.) and added to the shadowing
|
||||
list $Shg(p)$ of $p$ if not yet present in this list. This addition to the
|
||||
shadowing list solves the possible name conflicts with symbols inherited
|
||||
from packages used by $p.$ It is possible that a /different/ symbol /sm'/
|
||||
with the same name was /present/ in $p$ beforehand. If so, such a symbol is
|
||||
/uninterned/ from $p$, that is, erased from the lists $InS(p)$, $ExS(p)$ and
|
||||
$Shg(p)$.
|
||||
|
||||
The difference between =shadow= and =shadowing-import= is clarified by the
|
||||
following toy example. We start a new Lisp session, allocate a package
|
||||
="P"= and experiment with symbols named ="A"= and ="B"= in the packages
|
||||
="CL-USER"= and ="P"=.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user