From: Peter Seibel
Subject: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <m3d6dczdd2.fsf@javamonkey.com>
I seem to find myself constantly stumbling across the problem of
wanting to write classes like this:
(defclass random-number-iterator (iterator)
((count :initargs :count :reader count)
(limit :initargs :limit :reader limit)))
and getting bit because COUNT (or someother generic name like LENGTH
or STRING) is a symbol in the COMMON-LISP package. Obviously there are
a bunch of ways to "fix" this ranging from finding another name to
shadowing the symbol. What is considered good style? Or is there some
other stylistic convention that I'm not using that would keep me from
running into this problem.
-Peter
P.S. Kenny, for the moment you have won on the :initargs front. While
I still think Burdick and I are right, I'm not confident enough to fly
in the face of tradition (an your strenuous opposition) without
someone else getting my back.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: james anderson
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <3F7FFAB8.7FD671A7@setf.de>
when this situation arises i consider the following options and factors
Peter Seibel wrote:
>
> I seem to find myself constantly stumbling across the problem of
> wanting to write classes like this:
>
> (defclass random-number-iterator (iterator)
> ((count :initargs :count :reader count)
> (limit :initargs :limit :reader limit)))
>
> and getting bit because COUNT (or someother generic name like LENGTH
> or STRING) is a symbol in the COMMON-LISP package. Obviously there are
> a bunch of ways to "fix" this ranging from finding another name to
> shadowing the symbol. What is considered good style? Or is there some
> other stylistic convention that I'm not using that would keep me from
> running into this problem.
which symbol must be qualified - both, cl, new (visibility):
as i tend to intern slot, class, can function name symbols in an isolated api
package, shadow per-se is not an issue. rather it is which would be the target
of a shadowing-import from the api package into an implementation package.
it's also possible to use a single package for implementation and api, but
that limits the options. (see "same" in the table below.)
whether the name itself has a qualifying prefix, as in rng-count (stem/prefixed):
first, the issue is likely to arise with single parameter functions only.
combinators likely have more elaborate names. it is a matter of how eminent
the function is, whether it is extending an existing function, or computing
something unrelated. given a single parameter function, the question is
whether the result is of the same kind as it would be when the function is
applied to other types. where other need to distinguish sub-types and disjoint
types. if the by disjoint value and result domains, a prefix is likely. at the
other extreme, by disjoint value and common result domains, a stem-only is likely.
whether to combine the functions (generic dispatch):
depending on the visibility mode and/or the conformance requirements, it may
be an option to define a generic function which combines an existing function
with additional generic methods. that is, given roughly
(defpackage :random-math (:nicknames :rm))
(in-package :random-math)
(defclass random-number-iterator (iterator)
((count :initargs :count :reader count)
(limit :initargs :limit :reader limit)))
this yields a taxonomy somewhat like
visibility eminence generic
-----------|-----------|-----------|------------------------------------
cl stem distinct count, rm::count
when they are producing different
results, esp. when counting the same
thing and, note the visibility,
ps::count is perhaps not even an
exported operation
new stem distinct cl:count, count
similar range/domain characteristics,
but the application depends more on
the new behaviour
cl,new prefix distinct count rni-count
especially if the api had other -counts
which behaved differently than rni-count
cl stem generic unlikely
new stem generic cl:count count
(:method ((datum t)) (cl:count datum))
same stem generic this is an option where there are no
distinct api and implementation packages
and conformance is not a concern
cl prefix generic can't recall having done this and
new prefix generic not sure there would be reasons to
neither ** ** this is also an option, but i won't
go into it
...
Peter Seibel wrote:
> I seem to find myself constantly stumbling across the problem of
> wanting to write classes like this:
>
> (defclass random-number-iterator (iterator)
> ((count :initargs :count :reader count)
> (limit :initargs :limit :reader limit)))
>
> and getting bit because COUNT (or someother generic name like LENGTH
> or STRING) is a symbol in the COMMON-LISP package. Obviously there are
> a bunch of ways to "fix" this ranging from finding another name to
> shadowing the symbol. What is considered good style? Or is there some
> other stylistic convention that I'm not using that would keep me from
> running into this problem.
When I get clashes I just change the name. I also tend to use prefixes
as a convention, md-this, sm-that. I do not use x and y as accessors on
my point structure, i use px and py. stuff like that. This belated
confession probably explains my lack of sympathy for initarg conflicts:
> P.S. Kenny, for the moment you have won on the :initargs front.
woo-hoo!
> I still think Burdick and I are right,
doh!
I'm not confident enough to fly
> in the face of tradition (an your strenuous opposition) without
> someone else getting my back.
Well you also have the standard backing you up. :)
kenny
From: Takehiko Abe
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <keke-0510031448320001@solg4.keke.org>
In article <··············@javamonkey.com>, Peter Seibel wrote:
> I seem to find myself constantly stumbling across the problem of
> wanting to write classes like this:
>
> (defclass random-number-iterator (iterator)
> ((count :initargs :count :reader count)
> (limit :initargs :limit :reader limit)))
>
> and getting bit because COUNT (or someother generic name like LENGTH
> or STRING) is a symbol in the COMMON-LISP package. Obviously there are
> a bunch of ways to "fix" this ranging from finding another name to
> shadowing the symbol. What is considered good style? Or is there some
> other stylistic convention that I'm not using that would keep me from
> running into this problem.
A possible solution is to use longer names. I found prefixing
with a class name convenient. e.g. random-number-iterator-count and
random-number-iterator-limit. or, iterator-count and
iterator-limit in case the iterator shares those slots.
From: Coby Beck
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <blon0k$8kt$1@otis.netspace.net.au>
"Takehiko Abe" <····@mac.mac.com> wrote in message
··························@solg4.keke.org...
> In article <··············@javamonkey.com>, Peter Seibel wrote:
>
> > I seem to find myself constantly stumbling across the problem of
> > wanting to write classes like this:
> >
> > (defclass random-number-iterator (iterator)
> > ((count :initargs :count :reader count)
> > (limit :initargs :limit :reader limit)))
> >
> > and getting bit because COUNT (or someother generic name like LENGTH
> > or STRING) is a symbol in the COMMON-LISP package. Obviously there are
> > a bunch of ways to "fix" this ranging from finding another name to
> > shadowing the symbol. What is considered good style? Or is there some
> > other stylistic convention that I'm not using that would keep me from
> > running into this problem.
>
> A possible solution is to use longer names. I found prefixing
> with a class name convenient. e.g. random-number-iterator-count and
> random-number-iterator-limit. or, iterator-count and
> iterator-limit in case the iterator shares those slots.
Definately an option, but this is not very appealing in general, you
probably agree... to Peter: I just deal with those problems on a case by
case basis, it does not seem to happen that often to me. Admitedly it is
sometimes an annoyance that I have to come up with a less satisfactory name.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
From: Thomas F. Burdick
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <xcvekxrntvf.fsf@famine.OCF.Berkeley.EDU>
Peter Seibel <·····@javamonkey.com> writes:
> I seem to find myself constantly stumbling across the problem of
> wanting to write classes like this:
>
> (defclass random-number-iterator (iterator)
> ((count :initargs :count :reader count)
> (limit :initargs :limit :reader limit)))
>
> and getting bit because COUNT (or someother generic name like LENGTH
> or STRING) is a symbol in the COMMON-LISP package. Obviously there are
> a bunch of ways to "fix" this ranging from finding another name to
> shadowing the symbol.
(You wouldn't believe how often this comes up when you're writing code
that reasons about code. Actually, you probably would; it's a lot. )
> What is considered good style? Or is there some other stylistic
> convention that I'm not using that would keep me from running into
> this problem.
When this happens to me, I try to think of a slightly more descriptive
name, and treat it as an indication that maybe I should refactor. I
don't generally prepend the class name to the slotname, because that
makes things really ugly when you inherit from the class, and
discourages refactoring (oh crap, I have to change
random-number-iterator-count *and* arbitrary-number-iterator-count to
iterator-count). I do prepend the class name when I make a *really*
abstract mixin. Something like:
(defclass counter-mixin ()
((counter-count :initargs counter-count :reader counter-count)))
(defclass random-number-iterator (iterator counter-mixin)
((random-limit :initargs random-limit :reader random-limit)))
Unless you're writing code that reasons about code, I think the above
is workable 99% of the time. For the other 1%, I'll do something like:
(defpackage :nameclash
(:use)
(:export ...))
(defpackage #:nameclash-impl
(:use :common-lisp))
(in-package #:name-clash-impl)
(defclass nameclash:random-number-iterator (nameclash:iterator)
((nameclash:count :initarg nameclash:count :reader nameclash:count)
(nameclash:limit :initarg nameclash:limit :reader nameclash:limit)))
That, or use a lame name here or there.
> P.S. Kenny, for the moment you have won on the :initargs front. While
> I still think Burdick and I are right, I'm not confident enough to fly
> in the face of tradition (an your strenuous opposition) without
> someone else getting my back.
[ boo! hiss! IMO, the reason this continues to be the dominant way of
doing things is precisely because book writers keep teaching people
to use it. ]
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Peter Seibel
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <m3vfr3w5im.fsf@javamonkey.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Peter Seibel <·····@javamonkey.com> writes:
[snip]
> > P.S. Kenny, for the moment you have won on the :initargs front. While
> > I still think Burdick and I are right, I'm not confident enough to fly
> > in the face of tradition (an your strenuous opposition) without
> > someone else getting my back.
>
> [ boo! hiss! IMO, the reason this continues to be the dominant way of
> doing things is precisely because book writers keep teaching people
> to use it. ]
Yeah. All I need is one or two more folks to say, "Yeah, you're right,
that is what one really should do." I have this idea that it was an
old posting of Kent Pitman's that put this idea in my head
originally--I'd be interested to know what he thinks of it now. Kent?
(Speaking of which, I don't recall having seen any posts from Mr.
Pitman for a while so maybe he's on vacation and will either back me
up or give me a Tiltonesque beatdown when he gets back.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> (Speaking of which, I don't recall having seen any posts from Mr.
> Pitman for a while so maybe he's on vacation and will either back me
> up or give me a Tiltonesque beatdown when he gets back.)
Gee, I feel just awful. I just thought a good way to popularize Lisp
would be to conduct technical discussions as they might go on the WWF,
with correspondents jumping off turnbuckles onto each other's opinions
and breaking chairs over their choices of words. You and Burdick had a
nice little tag team going there, lucky for me I was right.
:)
kenny "The Metal Rabbit" tilton
From: Nils Goesche
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <ly4qym4fst.fsf@cartan.de>
Peter Seibel <·····@javamonkey.com> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Peter Seibel <·····@javamonkey.com> writes:
>
> > > P.S. Kenny, for the moment you have won on the :initargs
> > > front. While I still think Burdick and I are right, I'm not
> > > confident enough to fly in the face of tradition (an your
> > > strenuous opposition) without someone else getting my back.
> >
> > [ boo! hiss! IMO, the reason this continues to be the dominant
> > way of doing things is precisely because book writers keep
> > teaching people to use it. ]
>
> Yeah. All I need is one or two more folks to say, "Yeah, you're
> right, that is what one really should do."
The only reason I didn't say so is that I thought you and Thomas had
already explained why it is better. I bet others didn't for the same
reason. When I still use keyword initargs in some postings, then only
because it is more common and I don't want to distract from other
points I'm trying to make.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> Peter Seibel <·····@javamonkey.com> writes:
>
>
>>···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>>
>>
>>>Peter Seibel <·····@javamonkey.com> writes:
>>
>>>>P.S. Kenny, for the moment you have won on the :initargs
>>>>front. While I still think Burdick and I are right, I'm not
>>>>confident enough to fly in the face of tradition (an your
>>>>strenuous opposition) without someone else getting my back.
>>>
>>>[ boo! hiss! IMO, the reason this continues to be the dominant
>>>way of doing things is precisely because book writers keep
>>>teaching people to use it. ]
>>
>>Yeah. All I need is one or two more folks to say, "Yeah, you're
>>right, that is what one really should do."
>
>
> The only reason I didn't say so is that I thought you and Thomas had
> already explained why it is better.
Do you all use non-keyword symbols for initargs on defstruct slots as well?
:)
kenny
From: Joe Marshall
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <ptha2q91.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:
>
> Do you all use non-keyword symbols for initargs on defstruct slots as well?
Gensyms.
From: Nils Goesche
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <lyptha447x.fsf@cartan.de>
Kenny Tilton <·······@nyc.rr.com> writes:
> Do you all use non-keyword symbols for initargs on defstruct slots
> as well?
Since I use LispWorks' decent CLOS implementation, I have no need for
DEFSTRUCT anymore :-)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Do you all use non-keyword symbols for initargs on defstruct slots
>>as well?
>
>
> Since I use LispWorks' decent CLOS implementation, I have no need for
> DEFSTRUCT anymore :-)
Wait! I almost have Cells for Defstruct!! :)
ACL's CLOS is dandy, too, but have you clocked make-instance? Of course
most apps won't care.
kenny
From: Duane Rettig
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <41xtq3sal.fsf@beta.franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Nils Goesche wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
>
> >>Do you all use non-keyword symbols for initargs on defstruct slots
> >>as well?
> > Since I use LispWorks' decent CLOS implementation, I have no need for
>
> > DEFSTRUCT anymore :-)
>
> Wait! I almost have Cells for Defstruct!! :)
>
> ACL's CLOS is dandy, too, but have you clocked make-instance? Of
> course most apps won't care.
Most apps will care, but your mileage _will_ vary, based on how much
lead is in your foot.
If you use the full functionality of CLOS and especially the MOP
so that your make-instance call has to deal with initialize-instance,
shared-initialize, and meta protocols, then of course the performance
of your make-instance call is degraded; you've traded it in for all
that functionality. But if you do simple things, and especially if
the compiler can figure out what you're doing at compile-time, then
the call to make-instance can be almost as fast as a call to vector,
with just a few extra cycles under the hood to morph the vector into
an instance. And that's about the same speed as defstruct, which
does effectively the same thing.
Having said that, I also must admit to using defstruct where speed
is concerned; but not because of the speed of make-instance, it's
because of the nonstandard nature of fast slot-value access.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Nils Goesche
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <87brsunea2.fsf@darkstar.cartan>
Duane Rettig <·····@franz.com> writes:
> Having said that, I also must admit to using defstruct where
> speed is concerned; but not because of the speed of
> make-instance, it's because of the nonstandard nature of fast
> slot-value access.
You know this of course, but just in case anybody else doesn't
already, I realized embarrassingly late that the accessors you
get with :ACCESSOR in DEFCLASS are /much/ faster than accessing
slots with SLOT-VALUE (at least in LispWorks...)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xD26EF2A0
From: Duane Rettig
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <4wubh3ojg.fsf@beta.franz.com>
Nils Goesche <···@cartan.de> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Having said that, I also must admit to using defstruct where
> > speed is concerned; but not because of the speed of
> > make-instance, it's because of the nonstandard nature of fast
> > slot-value access.
>
> You know this of course, but just in case anybody else doesn't
> already, I realized embarrassingly late that the accessors you
> get with :ACCESSOR in DEFCLASS are /much/ faster than accessing
> slots with SLOT-VALUE (at least in LispWorks...)
And it had better be the same in other CLs, as well. This is
another case of pay-as-you-go - under normal CLOS rules, the
index of any given CLOS slot is not fixed, so slot-value can't
just do an aref-like access. And because of multiple inheritance,
two instances of classes which have common inheritance might have
the slots defined by the common superclass residing in a different
location in each instances.
To mitigate this, there are several caching techniques that can
be used. These are usually best suited for many accesses of
instances of similar classes, because the setup is sometimes
best amortized over many accesses.
Also, several CLs (including Allegro CL) have extensions which
allow fixed indeces to be assigned to slots (which imply some
restrictions in inheritance rules, or course). With these
extensions, one can get back almost to the defstruct-accessor
speed, for a sacrifice of some flexibility.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Nils Goesche
Subject: Re: Conflicts between slot accessors and symbols naming functions in CL package?
Date:
Message-ID: <87he2mf358.fsf@darkstar.cartan>
Kenny Tilton <·······@nyc.rr.com> writes:
> Nils Goesche wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>Do you all use non-keyword symbols for initargs on defstruct
> >>slots as well?
> > Since I use LispWorks' decent CLOS implementation, I have no
> > need for DEFSTRUCT anymore :-)
>
> Wait! I almost have Cells for Defstruct!! :)
>
> ACL's CLOS is dandy, too, but have you clocked make-instance? Of
> course most apps won't care.
I haven't �clocked� it, but I indeed wanted to find out once just
how fast or slow it really is. So I wrote an application in a
way that relied on CLOS' performance more heavily than anything
else I'd written before. I wrote an ISDN-CAPI application
framework where every CAPI message was represented by a CLOS
instance, /including/ data packages. If you want decent speech
quality, you'll have to choose small data packages, about 128
octets in size, meaning you'll have 2 * 8000/128 = 125 calls to
MAKE-INSTANCE per second per connection! There was lots of
inheritance and multimethod dispatch. I also used CHANGE-CLASS a
lot, BTW. To my surprise, performance was /still/ great. Even
with several connections simultaneously, the processor was mostly
idle. That enhanced my confidence in CLOS a lot...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xD26EF2A0