From: Raymond Wiker
Subject: Re: howto string->symbol
Date: 
Message-ID: <87vh1ym19y.fsf@foobar.orion.no>
kp gores <·····@sip.medizin.uni-ulm.de> writes:

> hello,
> 
> in cmulisp i type:
> 
> (setq a 'hello) 
> (setq b 3)
> 
> how can i set a to be the "concatenation" of a and b, i.e. what i would 
> write as (setq a 'hello3) ?
> 
> i tried (setq a (make-symbol (format nil "~S~S" a b)))
> which gives #:HELLO3
> 
> any ideas? it surely is absolutely obvious.

        Try intern instead of make-symbol...

-- 
Raymond Wiker, Orion Systems AS
+47 370 61150

From: Erik Naggum
Subject: Re: howto string->symbol
Date: 
Message-ID: <3163848847427556@naggum.no>
* kp gores <·····@sip.medizin.uni-ulm.de>
| I probably have all  packages using "SHARED"  to re-use it??

  why do you think you need to "re-use" those packages?

| it seems like being a bad idea creating symbols which are shared over
| packages!?

  it might, but that depends on their purpose.

#:Erik
From: Tim Bradshaw
Subject: Re: howto string->symbol
Date: 
Message-ID: <ey34s9gam8s.fsf@cley.com>
* kp gores wrote:
> well, i didn't test it. but i thought that pack A using pack B knows 
> about only the (external) symbols of B existing at the time of using and 
> not later created symbols.

No, it's dynamic (this is Lisp!).

--tim
From: Erik Naggum
Subject: Re: howto string->symbol
Date: 
Message-ID: <3163935044643945@naggum.no>
* kp gores <·····@sip.medizin.uni-ulm.de>
| well, i didn't test it. but i thought that pack A using pack B knows 
| about only the (external) symbols of B existing at the time of using and 
| not later created symbols.

  as I suspected, but I am curious, from an educational vantage point --
  it's an odd assumption to make, in my view, and I wonder how you came to
  think this way.  here's how I think: when you let a package use another
  package, you refer to the package, as opposed to the symbols of the
  package with, say, a use-package-symbols operator, which is what import
  does, essentially.  my goal is to find out how to explain the difference
  between import and use-package very succinctly.  it is not enough to
  argue that the name "use-package" is sufficient, unless one also argues
  that people pay _real_ good attention to the names, but whether that is
  feasible or not is the underlying concern.

#:Erik
From: Joe Marshall
Subject: Re: howto string->symbol
Date: 
Message-ID: <ug0t0h3mj.fsf@alum.mit.edu>
Erik Naggum <····@naggum.no> writes:

>   my goal is to find out how to explain the difference
>   between import and use-package very succinctly.  
> 
> #:Erik

I'm not sure there is a very succinct description.  To really
understand the difference I think you have to have a fairly complete
model of how the package system works.

--
~jrm
From: Tim Bradshaw
Subject: Re: howto string->symbol
Date: 
Message-ID: <ey3vh1xrk6x.fsf@cley.com>
* kp gores wrote:

> the symbol is created in some package, but should have its home in 
> another package, "SHARED". other packages using "SHARED" should know the 
> newly created symbols too.
> i am thinking about
> intern <symbol> "SHARED"  and then 
> export <symbol> from within "SHARED" and then I probably have all 
> packages using "SHARED"  to re-use it??

No, that will just work without stress.  Intern it in the package,
then export it (with something like (export (intern ... ...))), then
everyone that uses that package will see the new symbol automagically.

However an error can happen when you do the export if some package
which uses the exporting package has a symbol with the same name.
This should be a continuable error though.

There is a crucial difference between importing a symbol from a
package and merely using the package which may be what is confusing
you: importing a symbol makes the symbol exist directly in the
importing package (as well as the exporting package), using another
package just adds it to the list of packages searched for symbols.
Importing is what you want to do if you want to construct some
interface package (like CL, typically), which doesn't actually have
many symbols of its own, but imports a lot of symbols from other
packages and then reexports them. (This confused me for years, and it
probably still does in fact, so this explanation may be wrong...)

--tim