I often find myself wanting to use a macro with an evaluated value for
the argument, e.g. :
(eval `(defpackage ,some-computed-name))
As I'm writing a program that builds and executes code based on pieces
provided by the user, I guess it's normal that I find myself drown in
evals, but sometimes I find this cumbersome. I keep wondering why some
standard macros are made this way, rather than taking a "normal"
argument, which it's not a burden to quote when needed.
Am I missing something?
Philippe Lorin wrote:
> I often find myself wanting to use a macro with an evaluated value for
> the argument, e.g. :
> (eval `(defpackage ,some-computed-name))
By the way, *never* invoke DEFPACKAGE without a :USE argument.
Otherwise, the code is not portable.
Paul
Paul F. Dietz wrote:
> By the way, *never* invoke DEFPACKAGE without a :USE argument.
> Otherwise, the code is not portable.
I'm not sure I understand what the :USE argument is for. If my package
is not an "extension" of another one, I'd think I don't need it to
"inherit" any symbols; do you mean I should add something like "(:use
)"? The examples from CLHS use "(:use common-lisp)", but I don't
understand how this can be useful.
Philippe Lorin <············@gmail.com> writes:
> If my package is not an "extension" of another one, I'd think I
> don't need it to "inherit" any symbols;
You'd most likely want to program in common lisp, so you'd want the
symbols from the COMMON-LISP package.
> do you mean I should add something like "(:use
> )"?
An empty use-list would mean you need to prefix every standard symbol
with "COMMON-LISP:". Very tedious in the long run.
> The examples from CLHS use "(:use common-lisp)", but I don't
> understand how this can be useful.
This ensures that the _only_ symbols imported into your package are
the standard common-lisp symbols.
If you omit the (:use common-lisp), the use-list of your package will
be implementation dependent. That usually means it will include more
packages in addition to those of COMMON-LISP, but it _could_ mean you
end up with the empty package list.
If your code was written in an implementation that includes
COMMON-LISP in the default use-list, it will break immediately if
someone tries to use it in an implementation that defaults to the
empty list.
More commonly, you can happen to use implementation dependent
functionality in your code without realizing it, by using unadorned
symbols that are not in the COMMON-LISP package. Your code will again
break if compiled (or even loaded) on another implementation with
different defaults.
These problems go away if you always include (:use ...) in your
defpackage forms, even if you only use COMMON-LISP.
...Peder...
--
Sl�v uten dop.
Peder O. Klingenberg wrote:
> You'd most likely want to program in common lisp
Who doesn't? ;)
I believe I was mislead by the word "inherit" in defpackage's CLHS
description:
"The arguments to :use set the packages that the package named by
package-name will inherit from.".
I thought that meant that external symbols from the inherited packages
would become external symbols of the new package. But I guess it
actually works as with USE-PACKAGE:
"use-package causes package to inherit all the external symbols of
packages-to-use. The inherited symbols become accessible as internal
symbols of package."
Then I don't understand why the word "inherit" was chosen here; for me
it causes confusion with the classic OOP scheme, where the visibility of
members is usually passed as is to the children. Why not something like
"import"? Or have I been deformed by too much Java?
Philippe Lorin wrote:
> Paul F. Dietz wrote:
>
>> By the way, *never* invoke DEFPACKAGE without a :USE argument.
>> Otherwise, the code is not portable.
>
>
> I'm not sure I understand what the :USE argument is for. If my package
> is not an "extension" of another one, I'd think I don't need it to
> "inherit" any symbols; do you mean I should add something like "(:use
> )"? The examples from CLHS use "(:use common-lisp)", but I don't
> understand how this can be useful.
The problem is that if you omit the :use parameter, the meaning
is implementation-dependent. Omitting :use is not the same
as including (:use). So, yes, if you don't want to inherit
symbols from another package, use (:use).
Paul
Philippe Lorin <············@gmail.com> writes:
> I often find myself wanting to use a macro with an evaluated value for
> the argument, e.g. :
> (eval `(defpackage ,some-computed-name))
> As I'm writing a program that builds and executes code based on pieces
> provided by the user, I guess it's normal that I find myself drown in
> evals, but sometimes I find this cumbersome. I keep wondering why some
> standard macros are made this way, rather than taking a "normal"
> argument, which it's not a burden to quote when needed.
> Am I missing something?
There are probably some cases where you need to use EVAL because the
underlying functionality is not directly exposed. (Computing args to
TRACE might be an example.) So I won't tell you this phenomenon doesn't
happen.
But on the other hand, it also happens, as with your example, that there
is a functional substrate and that you're not realizing that the macro is
a convenient way to access it for some things but should not be used for
others. e.g., for your example:
(make-package some-computed-name)
would be preferred. DEFPACKAGE is really for doing declarational
stuff, and is not intended to be used by functions in code.
On the other hand again, if the computation can be done at definition time,
perhaps you want:
(defmacro define-generated-package ()
`(defpackage ,(gensym)))
(define-generated-package)
In this case, EVAL will effectively be called, but not explicitly. The
interpreter or compiler will process your form, macroexpand it, then get
(defpackage #:G0001) and will further process that.
That is, a certain class of macro errors can be avoided by instead of
calling EVAL, putting the form that is computed back into the place where
execution will naturally occur. But that really only applies to things
that are computed at compile time. (You didn't way when your computation
was occurring.)
Does that help?
There is some subtlety I'm not sure I understand here, about when
computation occurs. The eval defpackage is evaluated when the user
clicks on some button, after having written the package's contents in a
text area. I need to create the package to execute another bit of code
in its context. The name of the package is not known when I launch the
program.
The reason I didn't use make-package is that it causes an error when
used twice with the same "package designator". Of course I could catch
the error and discard it, but I thought eval + defpackage was a little
less ugly. I wouldn't want to track which packages were already created
and which were not. In light of this, should I still prefer make-package?
Philippe Lorin <············@gmail.com> writes:
> I often find myself wanting to use a macro with an evaluated value for
> the argument, e.g. :
> (eval `(defpackage ,some-computed-name))
> As I'm writing a program that builds and executes code based on pieces
> provided by the user, I guess it's normal that I find myself drown in
> evals, but sometimes I find this cumbersome. I keep wondering why some
> standard macros are made this way, rather than taking a "normal"
> argument, which it's not a burden to quote when needed.
> Am I missing something?
MAKE-PACKAGE
--
"You question the worthiness of my code? I should kill you where you
stand!"