Is there an easy way to have WRITE write all symbols as if they were
internal, rather than distinguishing the external ones by using ":"
instead of "::"?
For instance,
(write 'some-package::some-external-symbol)
will write:
SOME-PACKAGE:SOME-EXTERNAL-SYMBOL
but I need:
SOME-PACKAGE::SOME-EXTERNAL-SYMBOL
I need this because in my file, I use the symbol before it gets exported
(the symbol is used as a parameter to a function which, as a side
effect, may export it).
When loading the file (in a fresh session), if the reader sees:
SOME-PACKAGE:SOME-EXTERNAL-SYMBOL
it complains that the symbol does not exist. But if it sees:
SOME-PACKAGE::SOME-EXTERNAL-SYMBOL
it creates the symbol happily.
Of course I can think of various workarounds; but nothing pretty.
Philippe Lorin <············@gmail.com> writes:
> Is there an easy way to have WRITE write all symbols as if they were
> internal, rather than distinguishing the external ones by using ":"
> instead of "::"?
>
>
> For instance,
> (write 'some-package::some-external-symbol)
>
> will write:
> SOME-PACKAGE:SOME-EXTERNAL-SYMBOL
>
> but I need:
> SOME-PACKAGE::SOME-EXTERNAL-SYMBOL
(format t "~A::~A" (package-name (symbol-package s)) (symbol-name s))
> I need this because in my file, I use the symbol before it gets
> exported (the symbol is used as a parameter to a function which, as a
> side effect, may export it).
>
> When loading the file (in a fresh session), if the reader sees:
> SOME-PACKAGE:SOME-EXTERNAL-SYMBOL
>
> it complains that the symbol does not exist. But if it sees:
> SOME-PACKAGE::SOME-EXTERNAL-SYMBOL
>
> it creates the symbol happily.
>
>
> Of course I can think of various workarounds; but nothing pretty.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
Pascal Bourguignon wrote:
> (format t "~A::~A" (package-name (symbol-package s)) (symbol-name s))
Of course; that's one workaround, but in the actual program, I don't
write each symbol individually; I just write a big sexp. I wouldn't want
to replace WRITE with custom code that would (attempt to) do the same
thing except for the detail of ":" vs "::".
+ Pascal Bourguignon <····@mouse-potato.com>:
| Philippe Lorin <············@gmail.com> writes:
|
|> Is there an easy way to have WRITE write all symbols as if they were
|> internal, rather than distinguishing the external ones by using ":"
|> instead of "::"?
|
| (format t "~A::~A" (package-name (symbol-package s)) (symbol-name s))
Which will work or not, depending on the current value of
(readtable-case *read-table*) and whether or not the symbol has
unusual case.
Of course, if the OP is happy with a file that must be read in using
(readtable-case *read-table*) = :preserve, or if he uses the default
:upcase and all his symbols have uppercase names, your solution is
fine. (Not at all unlikely, really.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Philippe Lorin wrote:
> Is there an easy way to have WRITE write all symbols as if they were
> internal, rather than distinguishing the external ones by using ":"
> instead of "::"?
The following should do what you want:
(defvar *dummy-package*
(make-package :dummy-package)
(let ((*package* *dummy-package*))
(write ...))
As an alternative, simply:
(let ((*package* nil))
(write ...))
may work. But please wait for a language lawyer to assess the legality
of this second expr.
P.
"Pierpaolo BERNARDI" <·········@gmail.com> writes:
> Philippe Lorin wrote:
>> Is there an easy way to have WRITE write all symbols as if they were
>> internal, rather than distinguishing the external ones by using ":"
>> instead of "::"?
>
> The following should do what you want:
>
> (defvar *dummy-package*
> (make-package :dummy-package)
>
> (let ((*package* *dummy-package*))
> (write ...))
I don't think so. See 22.1.3.3.1 Package Prefixes for Symbols. What
package you're in has an effect on whether the package prefix is
printed but whether the prefix is separated from the symbol name with
one or two colons is a function of whether the symbol is external in
its home package.
>
> As an alternative, simply:
>
> (let ((*package* nil))
> (write ...))
>
> may work. But please wait for a language lawyer to assess the legality
> of this second expr.
I'm pretty sure you're asking for trouble if you bind *PACKAGE* to
something that's not a package.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> writes:
> "Pierpaolo BERNARDI" <·········@gmail.com> writes:
> >
> > As an alternative, simply:
> >
> > (let ((*package* nil))
> > (write ...))
> >
> > may work. But please wait for a language lawyer to assess the legality
> > of this second expr.
>
> I'm pretty sure you're asking for trouble if you bind *PACKAGE* to
> something that's not a package.
I concur.
On those occasions when I want to force the output of package prefixes,
I will usually bind *package* to the KEYWORD package.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <··············@beagle.local>,
Peter Seibel <·····@gigamonkeys.com> wrote:
...
>I'm pretty sure you're asking for trouble if you bind *PACKAGE* to
>something that's not a package.
When should that trouble be detected?
1. When *package* is bound to the non package?
2. When *package* is used by the system to do something?
Thanks,
Mike
--
http://www.mschaef.com
·······@eris.io.com (MSCHAEF.COM) writes:
> In article <··············@beagle.local>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
> ...
>>I'm pretty sure you're asking for trouble if you bind *PACKAGE* to
>>something that's not a package.
>
> When should that trouble be detected?
>
> 1. When *package* is bound to the non package?
> 2. When *package* is used by the system to do something?
As far as I know the standard doesn't really say beyond saying that
the value of *PACKAGE* is a package. And NIL is not a package so a
program that sets *PACKAGE* to NIL is non-conforming. Whether anything
happens as a consequence, and when it happens if it does is, I think,
left up to the implementation.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
·······@eris.io.com (MSCHAEF.COM) writes:
>
> In article <··············@beagle.local>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
> ...
> >I'm pretty sure you're asking for trouble if you bind *PACKAGE* to
> >something that's not a package.
>
> When should that trouble be detected?
>
> 1. When *package* is bound to the non package?
> 2. When *package* is used by the system to do something?
I don't know about detected, but #2 is where problems will occur.
Probably in the form of an error of some sort, that will presumably have
difficulty being printed.
That said, I suppose that so long as no I/O is performed, and you don't
intern anything without specifying the package, you will likely be OK.
Reading will certainly choke, and I would expect writing to die also.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> ·······@eris.io.com (MSCHAEF.COM) writes:
>
> >
> > In article <··············@beagle.local>,
> > Peter Seibel <·····@gigamonkeys.com> wrote:
> > ...
> > >I'm pretty sure you're asking for trouble if you bind *PACKAGE* to
> > >something that's not a package.
> >
> > When should that trouble be detected?
> >
> > 1. When *package* is bound to the non package?
> > 2. When *package* is used by the system to do something?
>
> I don't know about detected, but #2 is where problems will occur.
> Probably in the form of an error of some sort, that will presumably have
> difficulty being printed.
In SBCL, a type error will be signalled when you bind or assign an
inappropriate value to *package*
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
"Pierpaolo BERNARDI" <·········@gmail.com> writes:
> Philippe Lorin wrote:
>> Is there an easy way to have WRITE write all symbols as if they were
>> internal, rather than distinguishing the external ones by using ":"
>> instead of "::"?
>
> The following should do what you want:
>
> (defvar *dummy-package*
> (make-package :dummy-package)
>
> (let ((*package* *dummy-package*))
> (write ...))
>
> As an alternative, simply:
>
> (let ((*package* nil))
> (write ...))
>
> may work.
Of course not. Using : or :: is not a property of the current package,
but of the symbol being in the export list of its home package or not.
> But please wait for a language lawyer to assess the legality
> of this second expr.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
From: Christophe Rhodes
Subject: Re: Making WRITE prefer "::" to ":"
Date:
Message-ID: <sq3bmom96v.fsf@cam.ac.uk>
Philippe Lorin <············@gmail.com> writes:
> Is there an easy way to have WRITE write all symbols as if they were
> internal, rather than distinguishing the external ones by using ":"
> instead of "::"?
> [...]
> Of course I can think of various workarounds; but nothing pretty.
How about this workaround? If you can afford *print-pretty* to be
true while you print your structure,
(defun print-symbol (stream object)
(let ((package (symbol-package object)))
(if package
(format stream "~A::~A" (package-name package) (symbol-name object))
(format stream "#:~A" (symbol-name object)))))
(set-pprint-dispatch '(and symbol (not null)) 'print-symbol)
You may wish to use a non-default pprint-dispatch-table...
Christophe
Philippe Lorin (me) wrote:
> Is there an easy way to have WRITE write all symbols as if they were
> internal, rather than distinguishing the external ones by using ":"
> instead of "::"?
>
>
> For instance,
> (write 'some-package::some-external-symbol)
OK, I can see from several answers I wasn't precise enough; my
apologies. What I need is not a simple function that writes one symbol;
I want to write a big sexp, with symbols from various packages,
including CL. The only clean way I can see how to do this is to wholly
rewrite WRITE, and I don't find this satisfying (even if it may not be a
lot of work, at least for my purposes).
Ideally, only symbols from SOME-PACKAGE would be forced with "::", to
keep the code readable. But this is not necessary.
I'd have expected there to be some variable in the style of
*PRINT-ESCAPE* I didn't know, or some way to override the part of WRITE
that deals with symbols.
From: Christophe Rhodes
Subject: Re: Making WRITE prefer "::" to ":"
Date:
Message-ID: <sq4q73fj7h.fsf@cam.ac.uk>
Philippe Lorin <············@gmail.com> writes:
> Philippe Lorin (me) wrote:
>> Is there an easy way to have WRITE write all symbols as if they were
>> internal, rather than distinguishing the external ones by using ":"
>> instead of "::"?
>>
>>
>> For instance,
>> (write 'some-package::some-external-symbol)
>
> OK, I can see from several answers I wasn't precise enough; my
> apologies. What I need is not a simple function that writes one symbol;
> I want to write a big sexp, with symbols from various packages,
> including CL. The only clean way I can see how to do this is to wholly
> rewrite WRITE, and I don't find this satisfying (even if it may not be a
> lot of work, at least for my purposes).
>
> Ideally, only symbols from SOME-PACKAGE would be forced with "::", to
> keep the code readable. But this is not necessary.
>
> I'd have expected there to be some variable in the style of
> *PRINT-ESCAPE* I didn't know, or some way to override the part of WRITE
> that deals with symbols.
The *print-pretty* solution that I posted has the capability to do
what you want. You can even tweak it, using a satisfies type
specifier, to apply to only those symbols you're interested in;
something like
(defpackage "SOME-PACKAGE"
(:export "FOO"))
(defun some-package-p (symbol)
(eq (symbol-package symbol) (find-package "SOME-PACKAGE")))
(defun output-symbol-with-colons (stream object)
(format stream "~A::~A" (package-name (symbol-package object))
(symbol-name object)))
(set-pprint-dispatch '(and symbol (satisfies some-package-p))
'output-symbol-with-colons)
(write '(foo bar some-package:foo some-package::bar) :pretty t)
Christophe
Christophe Rhodes wrote:
> The *print-pretty* solution that I posted has the capability to do
> what you want.
Oops... sorry, my mistake; I did read it, but somehow I managed to skip
the SET-PPRINT-DISPATCH bit, which was, well, the meat of it actually.
Shame on me; I'll say this is due to my program having been giving me
unusual headaches for a few days... ^^;
Thank you for this elegant solution, it is perfect.
From: Joe Marshall
Subject: Re: Making WRITE prefer "::" to ":"
Date:
Message-ID: <vezjf015.fsf@alum.mit.edu>
Philippe Lorin <············@gmail.com> writes:
> Is there an easy way to have WRITE write all symbols as if they were
> internal, rather than distinguishing the external ones by using ":"
> instead of "::"?
>
>
> For instance,
> (write 'some-package::some-external-symbol)
>
> will write:
> SOME-PACKAGE:SOME-EXTERNAL-SYMBOL
>
> but I need:
> SOME-PACKAGE::SOME-EXTERNAL-SYMBOL
>
>
> I need this because in my file, I use the symbol before it gets
> exported (the symbol is used as a parameter to a function which, as a
> side effect, may export it).
>
> When loading the file (in a fresh session), if the reader sees:
> SOME-PACKAGE:SOME-EXTERNAL-SYMBOL
>
> it complains that the symbol does not exist. But if it sees:
> SOME-PACKAGE::SOME-EXTERNAL-SYMBOL
>
> it creates the symbol happily.
This is a possible indication that you are abusing the package
system. Dynamically exporting symbols as a side effect of calling
some function is usually a bad idea. What is it you are doing?
Joe Marshall wrote:
> This is a possible indication that you are abusing the package
> system. Dynamically exporting symbols as a side effect of calling
> some function is usually a bad idea. What is it you are doing?
I want to save objects as code that regenerates them. Each object has a
name, which is an external symbol of SOME-PACKAGE, so that the user can
easily refer to his objects in his own code. So I write to the file
stuff like:
(make-instance 'some-object :name some-package::some-symbol ...)
Which will create the object as well as export its name.
From: Joe Marshall
Subject: Re: Making WRITE prefer "::" to ":"
Date:
Message-ID: <oe5al07k.fsf@alum.mit.edu>
Philippe Lorin <············@gmail.com> writes:
> Joe Marshall wrote:
>> This is a possible indication that you are abusing the package
>> system. Dynamically exporting symbols as a side effect of calling
>> some function is usually a bad idea. What is it you are doing?
>
> I want to save objects as code that regenerates them. Each object has
> a name, which is an external symbol of SOME-PACKAGE, so that the user
> can easily refer to his objects in his own code. So I write to the
> file stuff like:
>
> (make-instance 'some-object :name some-package::some-symbol ...)
>
> Which will create the object as well as export its name.
I see. Is the intent that someone would call `use-package' on the
package that the name is interned in?
-----
I think I'd probably generate the code this way:
(make-instance 'some-object
:name (intern "SOME-SYMBOL" "SOME-PACKAGE")
...
That way, you won't have problems with the reader expecting the symbol
to be internal.
Joe Marshall <·········@alum.mit.edu> writes:
> Philippe Lorin <············@gmail.com> writes:
>
>> Joe Marshall wrote:
>>> This is a possible indication that you are abusing the package
>>> system. Dynamically exporting symbols as a side effect of calling
>>> some function is usually a bad idea. What is it you are doing?
>>
>> I want to save objects as code that regenerates them. Each object has
>> a name, which is an external symbol of SOME-PACKAGE, so that the user
>> can easily refer to his objects in his own code. So I write to the
>> file stuff like:
>>
>> (make-instance 'some-object :name some-package::some-symbol ...)
>>
>> Which will create the object as well as export its name.
>
> I see. Is the intent that someone would call `use-package' on the
> package that the name is interned in?
>
> -----
>
> I think I'd probably generate the code this way:
>
> (make-instance 'some-object
> :name (intern "SOME-SYMBOL" "SOME-PACKAGE")
> ...
>
> That way, you won't have problems with the reader expecting the symbol
> to be internal.
This is not the problem.
#.(intern "NAME" "PACKAGE")
is strictly equivalent to:
|PACKAGE|::|NAME|
The problem is that the OP wants to write out expressions that will
rebuild the current state of a package in an artificial order.
The normal order, is to start with (DEFPACKAGE ... (:EXPORT ...))
But the OP wants: (DEFPACKAGE ...) (IN-PACKAGE ...) ... (EXPORT '(...))
One dynamic way to do it would be this:
(defun external-symbols (package)
(let ((syms '())) (DO-EXTERNAL-SYMBOLS (s package) (push s syms)) syms))
(defmacro with-internal-packages (packages &body body)
(if (null packages)
`(progn ,@body)
(let ((esyms (gensym)) (pack (gensym)))
`(let* ((,pack ,(first packages)) (,esyms (external-symbols ,pack)))
(unwind-protect
(progn (unexport ,esyms ,pack)
(with-internal-packages ,(rest packages) ,@body))
(export ,esyms ,pack))))))
(defpackage :p1 (:export :e))
(defpackage :p2 (:export :e))
(with-internal-packages (:p1 :p2) (print '(p1:e p1::i p2:e p2::i)))
prints: (P1::E P1::I P2::E P2::I)
and returns: (P1:E P1::I P2:E P2::I)
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Joe Marshall wrote:
> I see. Is the intent that someone would call `use-package' on the
> package that the name is interned in?
I think it is equivalent to that, but I'm not sure I see where you're
coming from.
> I think I'd probably generate the code this way:
>
> (make-instance 'some-object
> :name (intern "SOME-SYMBOL" "SOME-PACKAGE")
> ...
If I'm going to write strings, I think I might as well write
SOME-PACKAGE::SOME-SYMBOL directly ;)
(Part of the problem is that I'd prefer the code that generates the
MAKE-INSTANCE sexp not to worry about how it will be printed; it's
supposed to generate a sexp, nothing more -- it doesn't know how it will
be printed and read back. Thus the place where the special treatment of
external symbols must take place is where that sexp gets written, or read.)
...and it's really MAKE-INSTANCE that's supposed to do the job. Because:
1) it is supposed to always export the symbol, and to check for possible
conflicts
2) it is used elsewhere in the program too (factorisation);
3) the user may call it too (simpler interface);
4) the code in the file should be as friendly as possible to hand
modification.
Currently I'm using Christophe Rhodes' solution, and it does the job nicely.
From: Joe Marshall
Subject: Re: Making WRITE prefer "::" to ":"
Date:
Message-ID: <acgs1az2.fsf@alum.mit.edu>
Philippe Lorin <············@gmail.com> writes:
> Joe Marshall wrote:
>> I see. Is the intent that someone would call `use-package' on the
>> package that the name is interned in?
>
> I think it is equivalent to that, but I'm not sure I see where you're
> coming from.
I guess that it is because I feel a vague uneasiness about it rather
than having a concrete example.
> ...and it's really MAKE-INSTANCE that's supposed to do the job. Because:
> 1) it is supposed to always export the symbol, and to check for
> possible conflicts
> 2) it is used elsewhere in the program too (factorisation);
> 3) the user may call it too (simpler interface);
> 4) the code in the file should be as friendly as possible to hand
> modification.
When I write code, I have a file that sets up the various packages and
I load it first both during development and during deployment. None
of my other code makes changes to the package system (although each
file has an `export' clause at the top, so there are some changes made
at initial load time). While the program runs, no changes are made.
I'd be unhappy having symbols being exported as a result of calling
make-instance. If a package were to USE the package that the symbols
were being exported from, then the identity of an interned symbol
would be different depending on whether the instance had been created
or not.
> Currently I'm using Christophe Rhodes' solution, and it does the job nicely.
Well, if it works, then I guess that I'm worried about nothing.
Joe Marshall wrote:
> I'd be unhappy having symbols being exported as a result of calling
> make-instance. If a package were to USE the package that the symbols
> were being exported from, then the identity of an interned symbol
> would be different depending on whether the instance had been created
> or not.
Good point. The use I'm making of this specific package is certainly a
bit unorthodox. I'll try to document it properly enough. Maybe I'll
forbid USE-ing the package; the cost would actually be low as its
symbols are not to be used often.
Philippe Lorin (me) wrote:
> Good point. The use I'm making of this specific package is certainly a
> bit unorthodox. I'll try to document it properly enough. Maybe I'll
> forbid USE-ing the package; the cost would actually be low as its
> symbols are not to be used often.
Now, what am I thinking!? If I'm not going to USE the package, there's
no point in exporting its symbols, right? Or is it still a good thing as
documentation, in order to show the user that he can use the symbols?
Any advice welcome...