experchange > lisp

David Richards (03-04-20, 04:25 AM)
Hello all -
I have looked at two different packages (cl-ppcre and alexandria) and noticed a difference in the way each exports its functions and symbols. The Alexandria package uses #:<symbol name> while the cl-ppcre package exports witha simple :<symbol name>. The hyperspec says:

"#: introduces an uninterned symbol whose name is symbol-name. Every time this syntax is encountered, a distinct uninterned symbol is created."

But if you're introducing a new package aren't your symbols already uninterned within your package? Can someone explain the advantage of using one over the other?
Thanks!
Dave R.
Madhu (03-04-20, 07:30 AM)
* David Richards <8ecc9791-7423-4642-9530-6ca5cfb72d60> :
Wrote on Tue, 3 Mar 2020 18:25:25 -0800 (PST):

> I have looked at two different packages (cl-ppcre and alexandria) and
> noticed a difference in the way each exports its functions and
> symbols. The Alexandria package uses #:<symbol name> while the
> cl-ppcre package exports with a simple :<symbol name>. The hyperspec
> says:
> "#: introduces an uninterned symbol whose name is symbol-name. Every
> time this syntax is encountered, a distinct uninterned symbol is
> created."


I think I've seen statements to the effect that #: "just works" with
allegro's "modern mode" and also happens to work with other lisps.
I've never used allegro's "modern mode" myself

> But if you're introducing a new package aren't your symbols already
> uninterned within your package? Can someone explain the advantage of
> using one over the other?


My preferences are the same as CL defaults. Always case insensitive and
default case is uppercase. Consequently I prefer to see
(defpackage "CL" (:use "FOO") (:export "BAR"))
where the beautiful uppercase strings are syntax-highlighted as strings
with emply """ quotes indicating they are strings.

But I think some people are prejudiced against seeing uppercase and
others are offended by string syntax though I cannot really commiserate
with them
Vladimir Sedach (03-04-20, 07:44 AM)
Symbols like :foobar are keywords. Any time the reader sees one, it
is interned in the KEYWORD package if it is not already there:

--8<---------------cut here---------------start------------->8---
CL-USER> (find-symbol "FOOBAR" "KEYWORD")
NIL
NIL
CL-USER> :foobar
:FOOBAR
CL-USER> (find-symbol "FOOBAR" "KEYWORD")
:FOOBAR
:EXTERNAL
--8<---------------cut here---------------end--------------->8---

They also point to themselves as values. This makes it convenient to
use them as constants and enums. The only problem is they stick
around and take up memory. #: symbols do not, so that is the
preferred way to specify the package export list.

But that can also be done with strings:
(defpackage "ABC" (:export "XYZ"))

Why bother with #:foobar instead of "FOOBAR"? To let the reader
handle the possible case conversion options.



Not a problem for case sensitive implementations like Allegro modern
and CLISP with the -modern option.
David Richards (03-04-20, 01:59 PM)
On Wednesday, March 4, 2020 at 12:44:30 AM UTC-5, Vladimir Sedach wrote:
[..]
> --
> Vladimir Sedach
> Software engineering services in Los Angeles


Good info - thank you very much!
taruss (03-05-20, 07:25 PM)
On Tuesday, March 3, 2020 at 6:25:29 PM UTC-8, David Richards wrote:
> Hello all -
> I have looked at two different packages (cl-ppcre and alexandria) and noticed a difference in the way each exports its functions and symbols. The Alexandria package uses #:<symbol name> while the cl-ppcre package exports with a simple :<symbol name>. The hyperspec says: ....
> But if you're introducing a new package aren't your symbols already uninterned within your package? Can someone explain the advantage of using one over the other?


The question of keyword vs uninterned symbols is answered by others.

But when you are introducing a new package, the DEFPACKAGE form will often be
evaluated in a different package. (Perhaps CL-USER)?. In that case, if you used
interned symbols, you would be adding symbols into that package, when all you
really care about is getting the proper symbol-name for DEFPACKAGE to use.

Using symbols allows the reader case settings to intervene. You just need to be
sure that those settings are the same for all places the DEFPACKAGE form is
used in a single system, including already compiled files.
Ralph Schleicher (03-07-20, 08:11 PM)
David Richards <dnewtonrichards> writes:

> But if you're introducing a new package aren't your symbols already
> uninterned within your package? Can someone explain the advantage of
> using one over the other?


Within your package, you can also say

(export '*foo*)
(defvar *foo* t)

(export 'bar)
(defun bar ()
nil)

Then you don't have to maintain your package's export list.
Similar Threads