I found myself wanting to use a generic function and the ~// format
directive to define a protocol for what some languages call 'format
providers' . To make it a little more typist friendly, I also wanted
to define a wrapper with a very short name. However, the way strings
are resolved into symbols by ~// result in some curious inconveniences
when trying to provide an argument that is both short and in a package
of my choice.
The hyperspec has the following to say about resolving name in ~/name/
to a symbol:
name can be any arbitrary string that does not contain a "/". All of
the characters in name are treated as if they were upper case. If name
contains a single colon (:) or double colon (::), then everything up
to but not including the first ":" or "::" is taken to be a string
that names a package. Everything after the first ":" or "::" (if any)
is taken to be a string that names a symbol. The function
corresponding to a ~/name/ directive is obtained by looking up the
symbol that has the indicated name in the indicated package. If name
does not contain a ":" or "::", then the whole name string is looked
up in the COMMON-LISP-USER package.
Note this means even if I wanted to use a keyword symbol as a function
name I would still need to specify 'keyword' as the package part of
the argument.
So I could either define my wrapper in cl-user, or have a very short
package (nick)name and an even shorter wrapper name. I chose the
latter, but I was wondering if there was any history to the rather
idiosyncratic way ~// turns its argument into a symbol?
Matt
"Matthew D. Swank" <··················@gmail.com> writes:
> ... then everything up
> to but not including the first ":" or "::" is taken to be a string
> that names a package. Everything after the first ":" or "::" (if any)
> is taken to be a string that names a symbol.
...
> Note this means even if I wanted to use a keyword symbol as a function
> name I would still need to specify 'keyword' as the package part of
> the argument.
Actually, I would have expected you could write a keyword just the same
way as you would normally write them in source code -- namely with an
empty package string. So that you should be able to write
(format t "~/:foo/" ...)
and have the :FOO function invoked.
But checking with some implementations indicates that this is not
necessarily the case. When I try it in
ACL 6.2 Works
ACL 7.0 Works
SBCL 1.0.25 Error
CMUCL 19e Error
CLISP 2.47 Error
CCL 1.2 Error
LispWorks 5.0 Error
it seems the consensus is that the package name cannot be empty. And in
addition, LispWorks signals a continuable error when trying to define a
function in the keyword package.
So, that doesn't really help, then.
Even aside from that, I think that using a short package nickname and
short directive name would be the preferable way to go. As far as short
directive names go, the example that the built-in directives provide is
for very short names.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> "Matthew D. Swank" <··················@gmail.com> writes:
>
>> ... then everything up
>> to but not including the first ":" or "::" is taken to be a string
>> that names a package. Everything after the first ":" or "::" (if any)
>> is taken to be a string that names a symbol.
> ...
>> Note this means even if I wanted to use a keyword symbol as a function
>> name I would still need to specify 'keyword' as the package part of
>> the argument.
>
> Actually, I would have expected you could write a keyword just the same
> way as you would normally write them in source code -- namely with an
> empty package string. So that you should be able to write
>
> (format t "~/:foo/" ...)
>
> and have the :FOO function invoked.
IIRTANSFLCL the keyword package has an actual package name of "KEYWORD"
so to avoid any implementation dependencies on ~/.../ resolution of a
symbol name you could use ~/keyword:I'm-a-function/
Regardless what the ANS forgot to say, it is a pathetic practice to
define functions on symbols in the keyword package. It violates the
intention of what packages are all about.
From: Tobias C. Rittweiler
Subject: Re: Format's ~// and package resolution
Date:
Message-ID: <87r5z083f1.fsf@freebits.de>
"Matthew D. Swank" <··················@gmail.com> writes:
> So I could either define my wrapper in cl-user, or have a very short
> package (nick)name and an even shorter wrapper name. I chose the
> latter, but I was wondering if there was any history to the rather
> idiosyncratic way ~// turns its argument into a symbol?
I'd probably create, or reuse if already existing, a package named
"FORMAT", and then intern your function in that package. You could
explicitly assert that such a function does not already exist in that
package.
If everyone does it like that, it should work out well in practise.
(Of course that'll provide just a single namespace for everyone, so
there's the possibility of collisions, but note that collisions are just
as likely as if you could use keywords conventionally.)
-T.
Tobias C. Rittweiler wrote:
> "Matthew D. Swank" <··················@gmail.com> writes:
>
>> So I could either define my wrapper in cl-user, or have a very short
>> package (nick)name and an even shorter wrapper name. I chose the
>> latter, but I was wondering if there was any history to the rather
>> idiosyncratic way ~// turns its argument into a symbol?
>
> I'd probably create, or reuse if already existing, a package named
> "FORMAT", and then intern your function in that package. You could
> explicitly assert that such a function does not already exist in that
> package.
>
> If everyone does it like that, it should work out well in practise.
>
> (Of course that'll provide just a single namespace for everyone, so
> there's the possibility of collisions, but note that collisions are just
> as likely as if you could use keywords conventionally.)
I won't belabor the point, since your last paragraph implies you
understand the issue, but the primary purpose of packages is exactly
that, to avoid collisions. The X3J13 commitee, I think, realized that
the package system wasn't entirely adequate (hence the instruction to
the editor of the ANS, if possible, to keep it in "Chapter 11" which is
in a different statutory body the Involuntary Bankruptcy regulation is
US law.
If everyone used this convention, it would merely diminish the
possibility of collision since there are few function definitions
for use in ~/.../ format strings. But the possibility is still there.
A better solution would be to define these formatter-control functions
in the same package as the code that uses them, and use that explicit
quaklifier in the format control string. That is reliable, but leaves
a different problem, that when packages are refactored the text inside
a format control string might not get scanned properly by other tools.
To repeat, I don't think this problem is important enough to deserve
serious consideration (compared to all the other things the CL
community should be pondering).
On May 11, 1:48 am, "Steven M. Haflich" <····@alum.mit.edu> wrote:
> Tobias C. Rittweiler wrote:
> > "Matthew D. Swank" <··················@gmail.com> writes:
>
> >> So I could either define my wrapper in cl-user, or have a very short
> >> package (nick)name and an even shorter wrapper name. I chose the
> >> latter, but I was wondering if there was any history to the rather
> >> idiosyncratic way ~// turns its argument into a symbol?
>
> > I'd probably create, or reuse if already existing, a package named
> > "FORMAT", and then intern your function in that package. You could
> > explicitly assert that such a function does not already exist in that
> > package.
>
> > If everyone does it like that, it should work out well in practise.
>
> > (Of course that'll provide just a single namespace for everyone, so
> > there's the possibility of collisions, but note that collisions are just
> > as likely as if you could use keywords conventionally.)
>
> I won't belabor the point, since your last paragraph implies you
> understand the issue, but the primary purpose of packages is exactly
> that, to avoid collisions. The X3J13 commitee, I think, realized that
> the package system wasn't entirely adequate (hence the instruction to
> the editor of the ANS, if possible, to keep it in "Chapter 11" which is
> in a different statutory body the Involuntary Bankruptcy regulation is
> US law.
>
> If everyone used this convention, it would merely diminish the
> possibility of collision since there are few function definitions
> for use in ~/.../ format strings. But the possibility is still there.
>
> A better solution would be to define these formatter-control functions
> in the same package as the code that uses them, and use that explicit
> quaklifier in the format control string. That is reliable, but leaves
> a different problem, that when packages are refactored the text inside
> a format control string might not get scanned properly by other tools.
>
> To repeat, I don't think this problem is important enough to deserve
> serious consideration (compared to all the other things the CL
> community should be pondering).
Like?
Cheers
--
Marco