Strings and symbols

Robert Maas, see http://tinyurl.com/uh3t wrote:

>    Constructor Summary
>    Button(String label)
>              Constructs a Button with the specified label.

http://java.sun.com/j2se/1.4.2/docs...on.html#JButton(jav
ax.swing.Icon)

public JButton(Icon icon)

Creates a button with an icon.


--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Mar 27, 10:45 am, Frank Buss <f...@frank-buss.de> wrote:
> Robert Maas, seehttp://tinyurl.com/uh3twrote:
> 
>
> http://java.sun.com/j2se/1.4.2/docs...on.html#JBut...)
>
> public JButton(Icon icon)
>
>     Creates a button with an icon.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de[/
color]

I'm sorry, my fault. I didn't mean label, I meant identifier. I was
looking for a way to actually bind values to symbols being generated
automatically, like button1, button2, etc... but I meant variables,
not the text labels that go on the buttons.

Michael Ben-Yosef <septagon@mweb.co.za> writes:

> On Mar 26, 9:17 pm, rocco.ro...@gmail.com wrote: 
>
> You can get the (string) name of a symbol using SYMBOL-NAME. So for
> your example the code would be
> (intern (concatenate 'string (symbol-name 'my) (symbol-name 'sum)))
>

CL-USER> (eql (concatenate 'string "alan" "crowe")
(concatenate 'string "alan" "crowe"))

=> NIL


CL-USER> (eql (intern (concatenate 'string
(symbol-name 'alan)
(symbol-name 'crowe)))
(intern (concatenate 'string
(symbol-name 'alan)
(symbol-name 'crowe))))
=> T

Symbols are for when you want to trade to get fast identity
checks at the exense of a lack of internal structure. INTERN
uses a hash table to recognise strings that it has interned before.

Strings are for the opposite trade: easy to append and check
for substrings, but identity requires a character by
character comparison.

You know who
Edinburgh
Scotland

rocco.rossi@gmail.com writes:

> I'm sorry, my fault. I didn't mean label, I meant identifier. I was
> looking for a way to actually bind values to symbols being generated
> automatically, like button1, button2, etc... but I meant variables,
> not the text labels that go on the buttons.

Lisp has arrays now, and you can access them with integers just like in
FORTRAN and C and Java and BASIC and INTERCAL. I really don't know why
you would think about constructing your own pounding-device out of bits
of twine and bent shoehorns when a hammer is sitting *right* *there* on
the bench beside you. ;)

rocco.rossi@gmail.com writes:

> Thank you all for kindly helping me out with this issue. I realize it
> appears to be a very strange thing someone would want to do :) but
> strangely enough the need for it arose while I was working on a GUI
> and I needed to automatically generate labels like button1, button2,
> button3, and so on ...

Why didn't you say so in the first place?

(GENTEMP "BUTTON-")

By the way, is there any particular reason the labels need to be
symbols?  Is that what the GUI library needs?  Or do you use them as
keys?

--
Thomas A. Russ,  USC/Information Sciences Institute

rocco.rossi@gmail.com writes:

> I'm sorry, my fault. I didn't mean label, I meant identifier. I was
> looking for a way to actually bind values to symbols being generated
> automatically, like button1, button2, etc... but I meant variables,
> not the text labels that go on the buttons.

But the problem with binding values to generated symbols is that you
still have to keep track of which symbols are available, since you can't
put runtime-generated symbols into your own code.

So somehow, you have to keep track of the button1, button2 symbols.  And
whatever data structure you use to keep track of those symbols can
instead be simply used to keep track of the values.  You could, for
example, use a hashtable to map button names to values.  Or p-lists, for
that matter, if you need to store more than one attribute.

--
Thomas A. Russ,  USC/Information Sciences Institute

On Mar 28, 5:45 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote:
> rocco.ro...@gmail.com writes: 
>
> But the problem with binding values to generated symbols is that you
> still have to keep track of which symbols are available, since you can't
> put runtime-generated symbols into your own code.
>
> So somehow, you have to keep track of the button1, button2 symbols.  And
> whatever data structure you use to keep track of those symbols can
> instead be simply used to keep track of the values.  You could, for
> example, use a hashtable to map button names to values.  Or p-lists, for
> that matter, if you need to store more than one attribute.
>
> --
> Thomas A. Russ,  USC/Information Sciences Institute

Oh yes, absolutely. But, at this point, just for the sake of
understanding the mechanism and thus the specification as best we can,
I've come across the following in the hyperspec regarding the function
INTERN:

"It is implementation-dependent whether the string that becomes the
new symbol's name is the given string or a copy of it. Once a string
has been given as the string argument to intern in this situation
where a new symbol is created, the consequences are undefined if a
subsequent attempt is made to alter that string."

Does this mean that, to play it safe, the best way to assign a value
to a symbol converted from a string would be using COPY-SEQ as
follows?

(defparameter *name* "my-variable")
(setf (symbol-value (intern (copy-seq (string-upcase *name*)))) "Any
old value!")

On Mar 26, 12:17 pm, rocco.ro...@gmail.com wrote:
> Are there any ways to manipulate symbols analogously to what can be
> done with strings?

Just a very general comment since others have replied in more detail:

It took years for the Lisp community to understand the difference
between symbols and strings.  In the old days, there were just
symbols, and what you want to do would have seemed completely natural
to use symbols for -- not just because there was no alternative, but
also because there were built-in functions like EXPLODE and IMPLODE
and GCTWA (ha! who remembers GCTWA? besides Kent, that is) that people
used for just this kind of purpose.

But eventually people realized that a separate string type was a good
idea, and started adding it to implementations.  And as people got
experience with it, I think a clearer sense of the difference started
to emerge.

In a nutshell: symbols are identifiers that stand for something else.
Strings, on the other hand, have no meaning beyond their contents.

This distinction, which might initially seem like hair-splitting, is
actually quite fundamental.  The very nature of a symbol is that it's
useless if it occurs in only one place.  Rather, it needs to be
defined in one place and referenced in at least one other place -- or
at the very least, there need to be two occurrences of it which refer
to the same thing.  This is true whether it's a variable in a program,
or used in some other way.

For strings, on the other hand, their usefulness doesn't depend on
whether there are multiple occurrences.  Consider error messages to be
shown to a user, or lines of text in an editor buffer.  These strings
don't stand for anything beyond themselves, and so it doesn't matter
whether they're repeated anywhere else in the program or the data it
is manipulating.

(An aside: too bad that after the Lisp community spent a couple
decades figuring all this out, the Java designers went and forgot it
again.  Java has optionally interned strings, which don't really know
whether they're strings or symbols.)

For the particular use you have in mind -- GUI buttons -- personally,
I would want to use both a string and a symbol.  The string is what
would appear on the screen; the symbol would serve as the name of the
button for purposes of communication between the application and the
GUI framework.  (For instance, this would let you change the displayed
label on the button without having to change all the places in your
code that respond to events on that button.)  I don't know whether any
Lisp GUI frameworks work that way, though.

Ah yes, you're still wondering about GCTWA :)  It stood for Garbage
Collect Truly Worthless Atoms.  Since there were only symbols, the
results of all "string operations" were interned.  This tended to
cause the relevant system hash table to fill up.  GCTWA told Lisp to
discard all symbols with neither a function nor a value binding, nor a
nonnull plist... that is, all symbols that weren't being used to refer
to anything.

-- Scott

rocco.rossi@gmail.com writes:

> On Mar 28, 5:45 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote: 
>
> Oh yes, absolutely. But, at this point, just for the sake of
> understanding the mechanism and thus the specification as best we can,
> I've come across the following in the hyperspec regarding the function
> INTERN:
>
> "It is implementation-dependent whether the string that becomes the
> new symbol's name is the given string or a copy of it. Once a string
> has been given as the string argument to intern in this situation
> where a new symbol is created, the consequences are undefined if a
> subsequent attempt is made to alter that string."
>
> Does this mean that, to play it safe, the best way to assign a value
> to a symbol converted from a string would be using COPY-SEQ as
> follows?
>
> (defparameter *name* "my-variable")
> (setf (symbol-value (intern (copy-seq (string-upcase *name*)))) "Any
> old value!")

Yes.

Well in this very case, no, since *name* is bound to a literal string,
that shouldn't be modified already in the first place.

But:

(ndo-something-with (let ((name (make-string 3 :initial-element #\a)))
(self (symbol-value (intern name)) 'ragnagna)
name))
would be very bad.

Better to write:

(ndo-something-with (let ((name (make-string 3 :initial-element #\a)))
(self (symbol-value (intern (copy-seq name))) 'ragnagna)
name))

On the other hand, there's no need for copy-seq in this case:

(ndo-something-with (let ((name (make-string 3 :initial-element #\a)))
(self (symbol-value (intern name)) 'ragnagna)
'not-name))

In the case of functions like string-upcase that may or may not return
the argument, you could avoid copy-seq in some occasions:

(ndo-something-with (let ((name (make-string 3 :initial-element (if (zerop (
random 2))
#\A #\a))))
(self (symbol-value (intern (let ((u (string-upcase name)))
(if (eq u name)
(copy-seq name)
u)))) 'ragnagna)
name))

--
__Pascal Bourguignon__                     http://www.informatimago.com/

"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."

On Mar 29, 12:35 pm, Pascal Bourguignon <p...@informatimago.com>
wrote:
> rocco.ro...@gmail.com writes: 
> 
> 
> 
> 
> 
> 
> 
>
> Yes.
>
> Well in this very case, no, since *name* is bound to a literal string,
> that shouldn't be modified already in the first place.
>
> But:
>
> (ndo-something-with (let ((name (make-string 3 :initial-element #\a)))
>                        (self (symbol-value (intern name)) 'ragnagna)
>                        name))
> would be very bad.
>
> Better to write:
>
> (ndo-something-with (let ((name (make-string 3 :initial-element #\a)))
>                        (self (symbol-value (intern (copy-seq name))) 'ragn
agna)
>                        name))
>
> On the other hand, there's no need for copy-seq in this case:
>
> (ndo-something-with (let ((name (make-string 3 :initial-element #\a)))
>                        (self (symbol-value (intern name)) 'ragnagna)
>                        'not-name))
>
> In the case of functions like string-upcase that may or may not return
> the argument, you could avoid copy-seq in some occasions:
>
> (ndo-something-with (let ((name (make-string 3 :initial-element (if (zerop
 (random 2))
>                                                                    #\A #\a
))))
>                        (self (symbol-value (intern (let ((u (string-upcase
 name)))
>                                                      (if (eq u name)
>                                                         (copy-seq name)
>                                                         u)))) 'ragnagna)
>                        name))
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
>
> "Klingon function calls do not have "parameters" -- they have
> "arguments" and they ALWAYS WIN THEM."

OK, I actually thought that all that could be said on this topic, had
been already, but I did discover something which is of course probably
well known (but not to me unfortunately until now):

(eval (read-from-string "(format t \"Hello World!!!~%\")"))

READ-FROM-STRING can really do the job when it comes to passing from
strings to Lisp objects!

The only thing is that I didn't expect to find out that EVAL does not
"see" the lexically scoped environment in which it is operating. WHY
IS THAT? I'm really very curious. I tried some stuff, for instance, in
the Python language with its eval function, and the lexical scoping
was valid, so I can't figure out the reason for doing it differently
in Lisp.