getting a full symbol name
Marc Battyani
is there a format directive for this ?
Thanks
Marc Battyani
Barry Margolin
Marc Battyani <Marc_B...@csi.com> wrote:
>what is the easiest way to get a full symbol name ie "package::name" ?
>is there a format directive for this ?
If you bind *PACKAGE* to NIL, then all symbols will be printed with package
qualifiers. So you can use:
(let ((*package* nil))
(format nil "~S" symbol))
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Dave Pearson
> In article <5174E9F018ADFCCC.F6B53EE0...@lp.airnews.net>,
> Marc Battyani <Marc_B...@csi.com> wrote:
>
> >what is the easiest way to get a full symbol name ie "package::name" ? is
> >there a format directive for this ?
>
> If you bind *PACKAGE* to NIL, then all symbols will be printed with
> package qualifiers. So you can use:
>
> (let ((*package* nil))
> (format nil "~S" symbol))
I just tried something like the above in three different lisps, clisp
complained about *PACKAGE* not being a package, acl complained that it had
suffered a printing error and cmucl complained that it had seen too many
errors.
Am I missing something regarding the above?
--
Take a look in Hagbard's World: | boxquote.el - "Boxed" text quoting.
http://www.hagbard.demon.co.uk/ | sawmill.el - Sawmill mode.
http://www.acemake.com/hagbard/ | uptimes.el - Record emacs uptimes.
emacs software, including.......| quickurl.el - Recall lists of URLs.
foot...@thcsv01.trafford.ford.com
> On Tue, 18 Apr 2000 20:34:57 GMT, Barry Margolin <bar...@genuity.net> wrote:
> > In article <5174E9F018ADFCCC.F6B53EE0...@lp.airnews.net>,
> > Marc Battyani <Marc_B...@csi.com> wrote:
> >
> > >what is the easiest way to get a full symbol name ie "package::name" ? is
> > >there a format directive for this ?
> >
> > If you bind *PACKAGE* to NIL, then all symbols will be printed with
> > package qualifiers. So you can use:
> >
> > (let ((*package* nil))
> > (format nil "~S" symbol))
>
> I just tried something like the above in three different lisps, clisp
> complained about *PACKAGE* not being a package, acl complained that it had
> suffered a printing error and cmucl complained that it had seen too many
> errors.
>
> Am I missing something regarding the above?
>
Try something like:
(defvar *dummy-package* (make-package "DUMMY" :use nil))
(defun symbol-name-with-package (symbol)
(let ((*package* *dummy-package*))
(format nil "~S" symbol)))
Guy.
Michael Hudson
> davep...@davep.org (Dave Pearson) writes:
>
> > > Marc Battyani <Marc_B...@csi.com> wrote:
> > >
> > > >what is the easiest way to get a full symbol name ie "package::name" ?
> > > >is there a format directive for this ?
[schnipp]
> Try something like:
>
> (defvar *dummy-package* (make-package "DUMMY" :use nil))
>
> (defun symbol-name-with-package (symbol)
> (let ((*package* *dummy-package*))
> (format nil "~S" symbol)))
>
Isn't
(defun symbol-full-name (symbol)
(format nil "~a::~a" (package-name (symbol-package symbol))
(symbol-name symbol)))
a bit less contrived? (Though it doesn't cope with uninterned
symbols...)
Cheers,
M.
--
languages shape the way we think, or don't.
-- Erik Naggum, comp.lang.lisp
foot...@thcsv01.trafford.ford.com
> foot...@thcsv01.trafford.ford.com writes:
>
> > davep...@davep.org (Dave Pearson) writes:
> >
> > > > Marc Battyani <Marc_B...@csi.com> wrote:
> > > >
> > > > >what is the easiest way to get a full symbol name ie "package::name" ?
> > > > >is there a format directive for this ?
> [schnipp]
> > Try something like:
> >
> > (defvar *dummy-package* (make-package "DUMMY" :use nil))
> >
> > (defun symbol-name-with-package (symbol)
> > (let ((*package* *dummy-package*))
> > (format nil "~S" symbol)))
> >
>
> Isn't
>
> (defun symbol-full-name (symbol)
> (format nil "~a::~a" (package-name (symbol-package symbol))
> (symbol-name symbol)))
>
> a bit less contrived? (Though it doesn't cope with uninterned
> symbols...)
>
The version I posted will also differentiate between exported
and unexported symbols, and deal with escaping of
characters/character-sequences.
It was really just taking what Barmar posted
and fixing what I take to be his oversight, though I have used this
approach myself on some project I worked ages ago.
Guy.
Erik Naggum
| If you bind *PACKAGE* to NIL, ...
... you are violating a system-wide invariant. just don't do it.
#:Erik
Erik Naggum
| what is the easiest way to get a full symbol name ie "package::name"?
(let ((*package* (find-package :keyword))
(write-to-string object :readably t)))
| is there a format directive for this?
(defun fqsn (stream object colon-p atsign-p &rest format-args)
(declare (ignore colon-p atsign-p format-args))
(let ((*package* (find-package :keyword))
(write object :stream stream :readably t))))
now there is. fqsn stands for fully qualified symbol name.
(format nil "~/fqsn/" <symbol>)
#:Erik
Tim Bradshaw
> (defun symbol-full-name (symbol)
> (format nil "~a::~a" (package-name (symbol-package symbol))
> (symbol-name symbol)))
> a bit less contrived? (Though it doesn't cope with uninterned
> symbols...)
and it doesn't tell you if the symbol is external.
--tim
Michael Hudson
Yes. Erik's solution is better; more bits of common lisp I didn't
know about.
Cheers,
M.
--
"declare"? my bogometer indicates that you're really programming
in some other language and trying to force Common Lisp into your
mindset. this won't work. -- Erik Naggum, comp.lang.lisp
Marc Battyani
news:31651251...@naggum.no...
Using the keyword package is very elegant indeed.
Thanks
Marc Battyani
Gareth McCaughan
> (let ((*package* (find-package :keyword))
> (write-to-string object :readably t)))
and
> (defun fqsn (stream object colon-p atsign-p &rest format-args)
> (declare (ignore colon-p atsign-p format-args))
> (let ((*package* (find-package :keyword))
> (write object :stream stream :readably t))))
>
> now there is. fqsn stands for fully qualified symbol name.
>
> (format nil "~/fqsn/" <symbol>)
Very elegant, but it doesn't work if the symbol you're
passed is actually a keyword! (You've also misplaced
one parenthesis in each case.)
I don't see any way to do this properly that isn't painful.
The best I can come up with is:
(defun fqsn (stream object colon-p atsign-p &rest format-args)
(declare (ignore colon-p atsign-p format-args))
(let ((*package* (find-package (if (keywordp object)
'common-lisp
:keyword))))
(write object :stream stream :readably t)))
--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction
Marc Battyani
Gareth McCaughan <Gareth.M...@pobox.com> wrote in message
news:863doh4...@g.local...
> Erik Naggum wrote:
>
> > (let ((*package* (find-package :keyword))
> > (write-to-string object :readably t)))
>
> and
>
> > (defun fqsn (stream object colon-p atsign-p &rest format-args)
> > (declare (ignore colon-p atsign-p format-args))
> > (let ((*package* (find-package :keyword))
> > (write object :stream stream :readably t))))
> >
> > now there is. fqsn stands for fully qualified symbol name.
> >
> > (format nil "~/fqsn/" <symbol>)
>
> Very elegant, but it doesn't work if the symbol you're
> passed is actually a keyword! (You've also misplaced
> one parenthesis in each case.)
>
> I don't see any way to do this properly that isn't painful.
> The best I can come up with is:
I don't think there are any pb with keywords.
The hyper spec says it's ok:
22.1.3.3.1 Package Prefixes for Symbols
Package prefixes are printed if necessary. The rules for package prefixes
are as follows. When the symbol is printed, if it is in the KEYWORD package,
then it is printed with a preceding colon; otherwise, if it is accessible in
the current package, it is printed without any package prefix; otherwise, it
is printed with a package prefix.
Marc Battyani
Erik Naggum
| Very elegant, but it doesn't work if the symbol you're passed is actually
| a keyword!
yes, it does.
#:Erik
Gareth McCaughan
> Very elegant, but it doesn't work if the symbol you're
> passed is actually a keyword! (You've also misplaced
> one parenthesis in each case.)
On further investigation, prompted by mail from another
c.l.l reader, I find that it *does* work in Lisps that
actually do what the Standard says, and that CMU CL
(which I usually use) doesn't do what the Standard
says. My apologies to #\Erik.
Barry Margolin
Gareth McCaughan <Gareth.M...@pobox.com> wrote:
>I wrote (regarding #\Erik's symbol-to-string code):
>
>> Very elegant, but it doesn't work if the symbol you're
>> passed is actually a keyword! (You've also misplaced
>> one parenthesis in each case.)
>
>On further investigation, prompted by mail from another
>c.l.l reader, I find that it *does* work in Lisps that
>actually do what the Standard says, and that CMU CL
>(which I usually use) doesn't do what the Standard
>says. My apologies to #\Erik.
I'm not surprised that at least one implementation gets it wrong. When he
quoted the spec, I was surprised to see that it makes the keyword package a
special case, and I can easily imagine an implementor overlooking this
detail. The special case seems pretty silly to me, since it makes little
sense to set set *PACKAGE* to the keyword package or to import symbols from
the keyword package. Why complicate things to accomodate something that no
sensible person would do? Does it really matter if keywords don't display
as expected after doing (in-package :keyword)?
Erik Naggum
| Why complicate things to accomodate something that no sensible
| person would do?
well, thank you. maybe some sensible person saw that it would be a
waste to create a dummy package to have symbols always print with a
package qualifier?
the answer is, of course: to get it right, always.
| Does it really matter if keywords don't display as expected after
| doing (in-package :keyword)?
yes. this is Common Lisp, not Java or C++ or Perl. remember?
#:Erik
Tim Bradshaw
> Does it really matter if keywords don't display
> as expected after doing (in-package :keyword)?
I think so. I'd like keywords to print the way I expect so long as
*package* has some legal value.
--tim
Barry Margolin
>* Barry Margolin <bar...@genuity.net>
>| Why complicate things to accomodate something that no sensible
>| person would do?
>
> well, thank you. maybe some sensible person saw that it would be a
> waste to create a dummy package to have symbols always print with a
> package qualifier?
>
> the answer is, of course: to get it right, always.
I think you misunderstand me. I was not saying that it was OK for the
implementation to violate the standard. I was saying that it was silly for
the standard to make this requirement in the first place, IMHO.
>| Does it really matter if keywords don't display as expected after
>| doing (in-package :keyword)?
>
> yes. this is Common Lisp, not Java or C++ or Perl. remember?
I don't understand. How would a simple rule like "Don't display any
package prefix if the symbol is in the current package" go against the CL
philosophy? How does the exception "unless the symbol is in the KEYWORD
package" really improve things? As I said, it's so unlikely that anyone
would be working in the keyword package that this exception would rarely be
invoked, so why did we create it in the first place?
Barry Margolin
>* Barry Margolin wrote:
>> Does it really matter if keywords don't display
>> as expected after doing (in-package :keyword)?
>
>*package* has some legal value.
Note also that there can be conflicting expectations. Intuitively, I'd
expect symbols in the current package to be printed with no package
prefix. I think of the keyword prefix as being a special case of how to
print package prefixes, i.e. *if* you're printing a prefix, and the prefix
would be "KEYWORD:", abbreviate it as ":".
The keyword package is certainly a special case, I just intuitively think
of it taking place at a different point in the printing algorithm than we
actually specified it. Naturally, I think it would have been just as
reasonable if the CL designers had specified it to match my intuition.
Erik Naggum
| How would a simple rule like "Don't display any package prefix if
| the symbol is in the current package" go against the CL philosophy?
| How does the exception "unless the symbol is in the KEYWORD package"
| really improve things?
because there are already a number of special cases for the keyword
package that warrant visual distinction. if the current package is
the keyword package, any symbol interned would be a keyword, right?
I greatly prefer the printer to reflect this fact if it is called to
print the value of such a symbol.
| As I said, it's so unlikely that anyone would be working in the
| keyword package that this exception would rarely be invoked, so why
| did we create it in the first place?
I already answered this: to avoid creating a dummy package in
certain circumstances.
#:Erik
wne...@my-deja.com
Barry Margolin <bar...@genuity.net> wrote:
> In article <86hfcni...@g.local>,
> Gareth McCaughan <Gareth.M...@pobox.com> wrote:
> >I wrote (regarding #\Erik's symbol-to-string code):
> >
> >> Very elegant, but it doesn't work if the symbol you're
> >> passed is actually a keyword! (You've also misplaced
> >> one parenthesis in each case.)
> >
> >On further investigation, prompted by mail from another
> >c.l.l reader, I find that it *does* work in Lisps that
> >actually do what the Standard says, and that CMU CL
> >(which I usually use) doesn't do what the Standard
> >says. My apologies to #\Erik.
>
> I'm not surprised that at least one implementation gets it
> wrong. When he quoted the spec, I was surprised to see that
> it makes the keyword package a special case, and I can easily
> imagine an implementor overlooking this detail. The special
> case seems pretty silly to me, since it makes little sense
> to set set *PACKAGE* to the keyword package or to import symbols
> something that no sensible person would do? Does it really
> matter if keywords don't display as expected after doing
> (in-package :keyword)?
Isn't printing :FOO instead of KEYWORD:FOO already a special case?
As long as you do this special thing, it's arguably simpler
to do it always instead of only doing it sometimes.
I wish the KEYWORD package were a little more special, actually.
I've been trying to decide what the SBCL interface for
profiling and tracing should look like. It's based on the CMU CL
TRACE code, and the CMU CL TRACE interface is basically nice, but
relies heavily on the assumption that a keyword is not a function
name, which as far as I can tell is not something which ANSI
guarantees. So do I compromise the expressive CMU CL interface
just to support people who want to
(defun :foo (x) (1+ x))
(trace :foo)
Almost certainly, since I like systems to conform to standards.
But it seems irksome in this case..
Bill Newman
Sent via Deja.com http://www.deja.com/
Before you buy.
Barry Margolin
>Isn't printing :FOO instead of KEYWORD:FOO already a special case?
>As long as you do this special thing, it's arguably simpler
>to do it always instead of only doing it sometimes.
As I said above, it depends on where in the process you implement the
special case. The logic could be:
(unless (symbol-in-package sym *package*)
(princ (package-prefix sym)))
(princ (symbol-name sym))
where the PACKAGE-PREFIX function implements the special casing of the
keyword package. Or the logic could be:
(cond ((eq (symbol-package sym) *keyword-package*)
(princ ":"))
((symbol-in-package sym *package*)
(princ (symbol-name sym)))
(t (princ (symbol-package sym))
(princ (double-or-single-colon sym))
(princ (symbol-name sym))))
>I wish the KEYWORD package were a little more special, actually.
>I've been trying to decide what the SBCL interface for
>profiling and tracing should look like. It's based on the CMU CL
>TRACE code, and the CMU CL TRACE interface is basically nice, but
>relies heavily on the assumption that a keyword is not a function
>name, which as far as I can tell is not something which ANSI
>guarantees. So do I compromise the expressive CMU CL interface
>just to support people who want to
> (defun :foo (x) (1+ x))
> (trace :foo)
>Almost certainly, since I like systems to conform to standards.
>But it seems irksome in this case..
I don't think the specification prohibits defining keywords as functions,
but realistically it's not a smart thing to do. The point of the package
system is to prevent unrelated pieces of code from interfering with each
other, but if two programmers both decide to define :FOO they'll clobber
each other when both applications are loaded into the same image.
This is very similar to the reasoning behind all the restrictions on the
COMMON-LISP package; perhaps we should have said something similar about
keywords, but just never thought of it (the COMMON-LISP package is more
critical, and impacts whether the implementation can can use it internally
or must have its own internal parallel sets of functions).
I'm not familiar with the CMUCL trace implementation, but I wonder why they
needed to use the keyword package, rather than some internal package of
their own.
Robert Monfera
wne...@my-deja.com wrote:
> Isn't printing :FOO instead of KEYWORD:FOO already a special case?
Probably not. Without looking at the standard, I have assumed that a
nickname of "KEYWORD" is simply "". And here it is:
> (package-nicknames :keyword)
("")
Regards,
Robert
Erik Naggum
| Probably not. Without looking at the standard, I have assumed that a
| nickname of "KEYWORD" is simply "". And here it is:
|
| > (package-nicknames :keyword)
| ("")
so if you turn off printing with package nicknames, they come out as
keyword:foo? I don't think so.
I'm slightly amused by Barry's willingness to regard the standard as
silly and to-be-ignored when his own interests are at stake. I have
been going over the character vs string debate with the purpose of
writing a proposal for the committee, and I seem to have found a
rather die-hard attitude from him on precisely what the standard
said and there were no option but to do _exactly_ what the standard
said, either. now, consistency is the hob-goblin of small minds and
all that, but I can't help but be amused when I realized that some
people's insistence on adherence to the standard is function of
rather more shifting personal needs than they pretend they are.
#;Erik
Barry Margolin
> I'm slightly amused by Barry's willingness to regard the standard as
> silly and to-be-ignored when his own interests are at stake.
I *never* said that the standard was to be ignored. I dare you to prove
that.
Erik Naggum
| In article <31661132...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
| > I'm slightly amused by Barry's willingness to regard the standard
| > as silly and to-be-ignored when his own interests are at stake.
|
| I *never* said that the standard was to be ignored. I dare you to
| prove that.
Prove what? Did I say you _said_ the standard was to be ignored?
No. Did you say it was very understandable that an implementation
get keyword printing wrong, and that that no sensible person would
rely on conformance? Yes. If that doesn't _communicate_ "ignore
the silly standard", nothing does.
I think conformance to an agreed-upon standard is fundamental to the
trust we want in a language. If we don't agree with it, which some
of us won't for a number of reasons, both good and bad, the process
is to change the document into something we _can_ agree with, not to
reduce or undermine the trust in the standard.
#:Erik
Barry Margolin
>* Barry Margolin <bar...@genuity.net>
>| In article <31661132...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>| > I'm slightly amused by Barry's willingness to regard the standard
>| > as silly and to-be-ignored when his own interests are at stake.
>|
>| I *never* said that the standard was to be ignored. I dare you to
>| prove that.
>
> Prove what? Did I say you _said_ the standard was to be ignored?
> No.
You say "to-be-ignored when his own interests are at stake." What does
that mean other than implying that I said such a thing.
> Did you say it was very understandable that an implementation
> get keyword printing wrong, and that that no sensible person would
> rely on conformance? Yes. If that doesn't _communicate_ "ignore
> the silly standard", nothing does.
Where did I say "no sensible person would rely on conformance"? I believe
I said that no sensible person would do something like (in-package
:keyword). I believe it was the authors of the standard who made a silly
design choice; I guess their intuition about the modularity of package
prefix printing differed from mine.
And saying that something is understandable is not the same thing as saying
it's acceptable. People make mistakes, and in many cases it's easy to
understand what causes the mistake. Small, counter-intuititive details in
a specification are easy to overlook.
Everything else I've said has just been my opinion about what the standard
should say, not what implementations should do (until and unless the
standard is updated). I certainly never intended to imply that the
standard should be ignored.
Tim Bradshaw
> Note also that there can be conflicting expectations. Intuitively, I'd
> expect symbols in the current package to be printed with no package
> prefix. I think of the keyword prefix as being a special case of how to
> print package prefixes, i.e. *if* you're printing a prefix, and the prefix
> would be "KEYWORD:", abbreviate it as ":".
I agree, I think either way could be argued. I think the way it works
is better, but that's just an opinion...
--tim