Re: package frenzy

Joris Bleys <jorisb@xxxxxxxxxxxxxx> writes:

> Hi Peter,
>
>> For starters, presumably you're using READ not READ-LINE as the latter
>> returns a string, not a symbol. Or you're using READ-LINE and then
>> INTERN to create a symbol, which is arguably a better plan that using
>> READ so you don't have to worry about READ reading some other kind of
>> object.
>
> Actually I'm using (read-from-string "COMMAND extra stuff which ain't
> important" NIL NIL) which returns COMMAND as a symbol. I initially
> mispelled this as I thought this was not of major influence on my
> problem at hand).
>
>> At any rate, the problem you're having is that READ and INTERN
>> both use the runtime value of *PACKAGE* to determine how to
>> find/intern symbols. So it doesn't matter that ep-internal-fn happens
>> to be defined in a file that is read with a particular *PACKAGE*--what
>> matters is what *PACKAGE* is when it is called.
>
> Ok, I agree to you this indeed is the problem and the solution. I just
> find it a bit difficult for a programmer to make sure symbols are
> created in the right package. I wonder when calling an internal
> function, the *package* is not automatically changed to the package to
> the one in which it was defined.

So one nit-picky, but actually quite important point, is that's it
doesn't really make sense to talk of the package in which a function
was defined. For instance, in what package is this function defined:

(in-package :foo)

(defun bar::baz () 'hello)

The value of *PACKAGE* when this file is read will be the package
"FOO" but the name of the function BAZ will not be interned in
"FOO"[1]. So, in your dream Lisp, should *PACKAGE* be bound to the
package "FOO" or the package "BAR" when BAZ is called? That's a
rhetorical question--I'm sure you could come up with an answer and
maybe even make a case for why it makes more sense than the other
answer. But the fact of the matter is, that functions aren't "in"
packages--just their names. It's worth getting this straight in your
head because once you realize that packages are *just* a scheme for
managing names, and only indirectly the things they name, the package
system will make a lot more sense.

-Peter

[1] Well it could, if the "FOO" and "BAR" packages had the appropriate
relationships established. But leave that aside for the moment.


P.S. If you really want to define packages that rebind *PACKAGE* at
runtime to the package that was current when the function was defined,
you could define this macro:

(defmacro defun/package (name (&rest args) &body body)
`(defun ,name ,args
(let ((*package* ,*package*))
,@body)))

And if you want functions that bind *PACKAGE* to the HOME package of
the name of the function, you could define this one:

(defmacro defun/package (name (&rest args) &body body)
`(defun ,name ,args
(let ((*package* ,(symbol-package name)))
,@body)))

I'm not sure that either of these are particularly useful--it's
probably better to be explicit about what package you are using at
runtime to lookup/intern names.

--
Peter Seibel peter@xxxxxxxxxxxxxxx

Lisp is the red pill. -- John Fraser, comp.lang.lisp
.

Relevant Pages

  • Re: Symbols - when are they garbage collected?
    ... home package is often considered to be interning it (certainly it is ... I agree that the CL function INTERN does not do this. ... string as its primary input, ... among Lisp practitioners. ...
    (comp.lang.lisp)
  • Re: trying to understand packages
    ... >> The big gotcha is that the reader will intern a symbol or try to resolve ... In particular, I see strings, symbols, and ... does the defpackage form convert the string usage to ... > doing so in another package because the package ...
    (comp.lang.lisp)
  • Re: how to generate function names
    ... FIND-SYMBOL can't find them in any package. ... INTERN find the symbol if it already was interned, ... (defun defun-my-functions (root) ... taking the package of the root ...
    (comp.lang.lisp)
  • Re: how to generate function names
    ... vector of characters that you are expecting. ... with any package. ... for human inspection of machine written code, ... INTERN looks in the variable ...
    (comp.lang.lisp)
  • Re: Sharpsign-colon ... why here?
    ... The root of the issue is the reader interning symbols in uppercase by ... the COMMON-LISP package). ... with the ANSI default and those who want to use a case preserving Lisp ... case preserving reader will intern the symbol in the provided case ...
    (comp.lang.lisp)