<astyle="font-size: 120%"href="https://www.udemy.com/course/common-lisp-programming/?couponCode=LISPY-XMAS2023"title="This course is under a paywall on the Udemy platform. Several videos are freely available so you can judge before diving in. vindarel is (I am) the main contributor to this Cookbook."> Discover our contributor's Lisp course with this Christmas coupon.</a>
<p>Continuing our example: in the REPL, be sure to be in <code>my-package</code> and not in <code>CL-USER</code>. There you can call “hello” directly:</p>
<li>exporting <code>:hello</code> without the sharpsign (<code>#:hello</code>) works too, but it will always create a new symbol. The <code>#:</code> notation does not create a new symbol. More precisely: it doesn’t <em>intern</em> a new symbol in our current package. It is a detail and at this point, a personal preference to use it or not. It can be helpful to not clutter our symbols namespace, specially when we import and re-export symbols from other libraries. That way, our editor’s symbols completion only shows relevant results. It is not useful for us at this point, don’t worry.</li>
<p>Now you can call <code>regex-replace</code> from inside <code>my-package</code>, without the <code>ppcre</code> package prefix. <code>regex-replace</code> is a new symbol inside your package. It is not exported.</p>
<p>Sometimes, we see <code>(:import-from :ppcre)</code>, without an explicit
import. This helps people using ASDF’s <em>package inferred system</em>.</p>
<p>You can also use the <code>import</code> function from outside a package definition:</p>
<h3id="importing-all-symbols">Importing all symbols</h3>
<p>It is a better practice to carefully choose what symbols you import from another package (read below), but we can also import all symbols at once with <code>:use</code>:</p>
<p>and now, <strong>all</strong> symbols that are exported by <code>cl-ppcre</code> (aka <code>ppcre</code>)
are available to use directly in your package. However, this should be
considered bad practice, unless you <code>use</code> another package of your
project that you control. Indeed, if the external package adds a
symbol, it could conflict with one of yours, or you could add one
which will hide the external symbol and you might not see a warning.</p>
<p>To quote <ahref="https://gist.github.com/phoe/2b63f33a2a4727a437403eceb7a6b4a3">this thorough explanation</a> (a recommended read):</p>
<blockquote>
<p>USE is a bad idea in contemporary code except for internal packages that you fully control, where it is a decent idea until you forget that you mutate the symbol of some other package while making that brand new shiny DEFUN. USE is the reason why Alexandria cannot nowadays even add a new symbol to itself, because it might cause name collisions with other packages that already have a symbol with the same name from some external source.</p>
</blockquote>
<h2id="list-all-symbols-in-a-package-do-external-symbols">List all Symbols in a Package (do-external-symbols)</h2>
<p>Common Lisp provides some macros to iterate through the symbols of a
package. The two most interesting are:
<ahref="http://www.lispworks.com/documentation/HyperSpec/Body/m_do_sym.htm"><code>DO-SYMBOLS</code> and <code>DO-EXTERNAL-SYMBOLS</code></a>. <code>DO-SYMBOLS</code> iterates over the
symbols accessible in the package and <code>DO-EXTERNAL-SYMBOLS</code> only iterates over
the external symbols (you can see them as the real package API).</p>
<p>To print all exported symbols of a package named “PACKAGE”, you can write:</p>
<pre><codeclass="language-lisp">(do-external-symbols (s (find-package "PACKAGE"))
(print s))
</code></pre>
<p>You can also collect all these symbols in a list by writing:</p>
<pre><codeclass="language-lisp">(let (symbols)
(do-external-symbols (s (find-package "PACKAGE"))
(push s symbols))
symbols)
</code></pre>
<p>Or you can do it with <ahref="http://www.lispworks.com/documentation/HyperSpec/Body/06_a.htm"><code>LOOP</code></a>.</p>
<pre><codeclass="language-lisp">(loop for s being the external-symbols of (find-package "PACKAGE")
collect s)
</code></pre>
<h2id="package-nickname">Package nickname</h2>
<h4id="package-local-nicknames-pln">Package Local Nicknames (PLN)</h4>
<p>Sometimes it is handy to give a local name to an imported package to
save some typing, especially when the imported package does not
<p>You can also set up a PLN in a <code>defpackage</code> form. The effect of PLN is totally within <code>mypackage</code> i.e. the <code>nickname</code> won’t work in other packages unless defined there too. So, you don’t have to worry about unintended package name clash in other libraries.</p>
;; You can use :nickname instead of :original-package-name
(nickname:some-function "a" "b")
</code></pre>
<p>Another facility exists for adding nicknames to packages. The function <ahref="http://www.lispworks.com/documentation/HyperSpec/Body/f_rn_pkg.htm"><code>RENAME-PACKAGE</code></a> can be used to replace the name and nicknames of a package. But it’s use would mean that other libraries may not be able to access the package using the original name or nicknames. There is rarely any situation to use this. Use Package Local Nicknames instead.</p>
