In article <5174E9F018ADFCCC.F6B53EE0A06D6DC9.5CE6E22D206AE...@lp.airnews.net>,
Marc Battyani <Marc_Batty...@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.
On Tue, 18 Apr 2000 20:34:57 GMT, Barry Margolin <bar...@genuity.net> wrote: > In article <5174E9F018ADFCCC.F6B53EE0A06D6DC9.5CE6E22D206AE...@lp.airnews.net>, > Marc Battyani <Marc_Batty...@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:
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.
> 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.
> > > Marc Battyani <Marc_Batty...@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:
> > > > Marc Battyani <Marc_Batty...@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:
> 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.
> > a bit less contrived? (Though it doesn't cope with uninterned > > symbols...)
> and it doesn't tell you if the symbol is external.
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
> > 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.
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.
-- Gareth McCaughan Gareth.McCaug...@pobox.com sig under construction
In article <86hfcni2zq....@g.local>, Gareth McCaughan <Gareth.McCaug...@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)?
-- 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.
* 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.
| 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?
In article <3165868104954...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
>* 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, 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.
In article <ey366t3t5h5....@cley.com>, Tim Bradshaw <t...@cley.com> wrote:
>* Barry Margolin wrote: >> 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.
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.
-- 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.
* Barry Margolin <bar...@genuity.net> | 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.
> In article <86hfcni2zq....@g.local>, > Gareth McCaughan <Gareth.McCaug...@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)?
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..
In article <8eff72$cj...@nnrp1.deja.com>, <wnew...@my-deja.com> wrote: >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:
>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.
-- 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.
* Robert Monfera <monf...@fisec.com> | 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.
