"llama" <·····@yahoo.com> writes:
> how do i concatenate two symbols 'a and 'b into 'ab?
(defun concatenate-symbols (&rest symbols)
(intern (apply #'concatenate 'string (mapcar #'string symbols))))
Gabe Garza
Gabe Garza wrote:
> "llama" <·····@yahoo.com> writes:
>
>
>>how do i concatenate two symbols 'a and 'b into 'ab?
>
>
> (defun concatenate-symbols (&rest symbols)
> (intern (apply #'concatenate 'string (mapcar #'string symbols))))
I've found it's usually a mistake to not provide intern
with the optional package argument.
llama, what would you want this concatenator to return on
the arguments 'FOO::A and 'BAR::B?
Paul
Paul F. Dietz wrote:
> Gabe Garza wrote:
>
>> "llama" <·····@yahoo.com> writes:
>>
>>
>>> how do i concatenate two symbols 'a and 'b into 'ab?
>>
>>
>>
>> (defun concatenate-symbols (&rest symbols)
>> (intern (apply #'concatenate 'string (mapcar #'string symbols))))
>
>
>
> I've found it's usually a mistake to not provide intern
> with the optional package argument.
>
> llama, what would you want this concatenator to return on
> the arguments 'FOO::A and 'BAR::B?
'AB, in *package*?
I build up names in Cell::macros which extend CL by expanding into
methods whose names I want interned in the client package, so intern's
default behavior in re packages is fine for that.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton wrote:
>> I've found it's usually a mistake to not provide intern
>> with the optional package argument.
>>
>> llama, what would you want this concatenator to return on
>> the arguments 'FOO::A and 'BAR::B?
>
>
> 'AB, in *package*?
In my experience, that's often dangerous, since *package* may
happen to become bound to something one didn't expect.
Anyone else ever had problems with this?
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> In my experience, that's often dangerous, since *package* may happen
> to become bound to something one didn't expect.
>
> Anyone else ever had problems with this?
>
Yes, I certainly have. But someone who is new to Common Lisp probably
isn't really using packages quite yet and probably won't have a
problem with it for some time. Packages and a solid understanding of
symbols are a big bite to swallow if all you wanted to know was how to
concatenate symbols....
Gabe Garza
"Paul F. Dietz" <·····@dls.net> writes:
> Kenny Tilton wrote:
>
> >> I've found it's usually a mistake to not provide intern
> >> with the optional package argument.
> >>
> >> llama, what would you want this concatenator to return on
> >> the arguments 'FOO::A and 'BAR::B?
> > 'AB, in *package*?
>
>
> In my experience, that's often dangerous, since *package* may
> happen to become bound to something one didn't expect.
>
> Anyone else ever had problems with this?
Yes.
But if both A and B are in the same package, it seems reasonable to
assume that 'ab would be in that package.
Joe Marshall <···@ccs.neu.edu> writes:
> "Paul F. Dietz" <·····@dls.net> writes:
>
> > Kenny Tilton wrote:
> >
> > >> I've found it's usually a mistake to not provide intern
> > >> with the optional package argument.
> > >>
> > >> llama, what would you want this concatenator to return on
> > >> the arguments 'FOO::A and 'BAR::B?
> > > 'AB, in *package*?
> >
> > In my experience, that's often dangerous, since *package* may
> > happen to become bound to something one didn't expect.
> >
> > Anyone else ever had problems with this?
>
> Yes.
>
> But if both A and B are in the same package, it seems reasonable to
> assume that 'ab would be in that package.
So if, for example, SET- and DIFFERENCE are in package FOO, then
SET-DIFFERENCE will be in package FOO?
This was the nightmare we ran into with SYMBOLCONC (the old name for
what you're doing) and why we moved away from defstruct-style :CONC-NAME
prefixes.
Things like
(defstruct set
contents
difference
ratio)
would end up trying to redefine some system function. The DEFCLASS style
where you name the symbols you are trying to define explicitly has the virtue
of making you think about each symbol and decide on a case-by-case basis
whether the package it's getting is right.
Also, we used to sometimes use (intern (string-append a b) (symbol-package a))
but this invariably got faked out by some package inclusion problem like
(intern (string-append 'car '-wreck) (symbol-package 'car))
and ended up trying to intern in the CL package. *package* was found to
generally be more reliable if you do decide to do symbolconc'ing, but I
don't recommend the practice really at all because now we're talking
"more likely to screw you" and "less likely to screw you" rather than talking
about reliable ways of making sure you don't get screwed at all. And since
the latter does exist, why not go for it?
Kent M Pitman <······@world.std.com> writes:
> So if, for example, SET- and DIFFERENCE are in package FOO, then
> SET-DIFFERENCE will be in package FOO?
>
> This was the nightmare we ran into with SYMBOLCONC (the old name for
> what you're doing) and why we moved away from defstruct-style :CONC-NAME
> prefixes.
>
> Things like
>
> (defstruct set
> contents
> difference
> ratio)
>
> would end up trying to redefine some system function. The DEFCLASS style
> where you name the symbols you are trying to define explicitly has the virtue
> of making you think about each symbol and decide on a case-by-case basis
> whether the package it's getting is right.
Good point. Requiring the user to supply the names explicitly is a
better idea.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>Things like
>
> (defstruct set
> contents
> difference
> ratio)
>
>would end up trying to redefine some system function. The DEFCLASS style
>where you name the symbols you are trying to define explicitly has the virtue
>of making you think about each symbol and decide on a case-by-case basis
>whether the package it's getting is right.
While I'm sure this package problem was part of it, I like to think that
the reason CLOS doesn't use the <class>-<slot> naming scheme is for a
higher-level, conceptual reason. In an OO system, a slot is associated
with a whole hierarchy of classes, not any particular one. We could have
used the name of the class that declares the slot, but this would then make
the class's composition visible to users (unless the programmer goes to the
effort of overriding the defaults to hide it). Since these are generic
functions, giving them class-specific names seems inappropriate.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, 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 <··············@level3.com> writes:
> While I'm sure this package problem was part of it, I like to think that
> the reason CLOS doesn't use the <class>-<slot> naming scheme is for a
> higher-level, conceptual reason. In an OO system, a slot is associated
> with a whole hierarchy of classes, not any particular one. We could have
> used the name of the class that declares the slot, but this would then make
> the class's composition visible to users (unless the programmer goes to the
> effort of overriding the defaults to hide it). Since these are generic
> functions, giving them class-specific names seems inappropriate.
Yet it seems that Lispers often do that on their own anyway,
e.g. writing something like
(defclass foo ()
((name :accessor foo-name ...)))
I think that this is often inappropriate, too, but I'm not sure if I
miss something. The only reason for this style seems to be the
requirement for congruent gf lambda lists, i.e. that you could get in
trouble if you would want to define another gf called name in the same
package that took more than one argument.
I cannot remember any case where this would have been a problem, but
my experience is limited. It would be interesting to hear what others
think about this issue.
Regards
Henrik
Henrik Motakef <··············@web.de> writes:
> Yet it seems that Lispers often do that on their own anyway,
> e.g. writing something like
>
> (defclass foo ()
> ((name :accessor foo-name ...)))
[...]
> I cannot remember any case where this would have been a problem, but
> my experience is limited. It would be interesting to hear what others
> think about this issue.
You might be interested to read what Tim Moore said:
http://www.lisp-p.org/htdocs/80-closminded/index.html
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
"llama" <·····@yahoo.com> writes:
> how do i concatenate two symbols 'a and 'b into 'ab?
(intern (concatenate 'string (symbol-name 'a) (symbol-name 'b)))
or
(intern (format nil "~a~a" 'a 'b))
Or replace INTERN with MAKE-SYMBOL if you want an uninterned symbol
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> (intern (format nil "~a~a" 'a 'b))
This technique for concatenating symbols was used extensively in the
company where I was working until a couple of weeks ago. I found it
terribly annoying, because it works only if *print-case* is set to
:upcase (and not :downcase, which I happen to prefer). IMHO, it is
bad style to make assumptions about the value of *print-case* in
production code.
--
Tord Romstad
Tord Kallqvist Romstad <·······@math.uio.no> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > (intern (format nil "~a~a" 'a 'b))
>
> This technique for concatenating symbols was used extensively in the
> company where I was working until a couple of weeks ago. I found it
> terribly annoying, because it works only if *print-case* is set to
> :upcase (and not :downcase, which I happen to prefer). IMHO, it is
> bad style to make assumptions about the value of *print-case* in
> production code.
One should wrap WITH-STANDARD-IO-SYNTAX around forms which implicitly
make such assumptions. I use an abstraction similar to the one below
for creating concatenated symbols:
(defun fintern (format-string &rest format-args)
(let ((package *package*))
(with-standard-io-syntax
(intern (apply #'format nil format-string format-args)) package)))
Carl Shapiro <·············@panix.com> writes:
> One should wrap WITH-STANDARD-IO-SYNTAX around forms which implicitly
> make such assumptions.
I wasn't aware of the existence of WITH-STANDARD-IO-SYNTAX. Thanks
for letting me know!
--
Tord Romstad
Tord Kallqvist Romstad <·······@math.uio.no> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > (intern (format nil "~a~a" 'a 'b))
>
> This technique for concatenating symbols was used extensively in the
> company where I was working until a couple of weeks ago. I found it
> terribly annoying, because it works only if *print-case* is set to
> :upcase (and not :downcase, which I happen to prefer). IMHO, it is
> bad style to make assumptions about the value of *print-case* in
> production code.
True, which is why it is a good idea to wrap these calls to format in
a WITH-STANDARD-IO-SYNTAX.
--
Jane - Daria? Come on, the neighbors are starting to talk.
Daria - Um... good. Soon they'll progress to cave drawings and civilization
will be on its way.