What is the difference between :foo and "foo" ?

[Steve Litt]

On Thursday 29 December 2005 01:03 pm, James Edward Gray II wrote:
[clip]

That's an instance variable, not a class variable.

I knew that Skipping from Perl to C to C++ to Python to Ruby, I sometimes
forget the terminology.

As Austin taught us yesterday, it doesn't make the variable either,
just some methods.

My understanding of Ruby is the getters and setters it makes make the
variable, because the setter sets @wilber to its argument.

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Chad Perrin]

Because it's true? Because there are people who don't have lisp
background who are not familiar with what symbol is? Because there are
people who thinks symbols are magical thingie?

It's not really true, though, considering what a symbol is (according to
my current understanding). A symbol is an element of a hash table that
is often used as a name, and it is an (anonymous? not sure how to
qualify that) object. Calling it a "name" seems to be confusing common
use with actual nature, or premature explanation of an abstract way of
thinking about it, depending on how you mean "it is a name" when you say
it. Either way, it seems to be getting the cart before the horse.

This is true for all analogies. Different people are receptive to
different analogies. This simply means you are not receptive to the
analogy I made.

I think it's probably more useful to start by describing the actual
functional nature of a symbol, then start in with the analogies if that
doesn't make a lightbulb go on in the person's head.

The basic message has always been clear: symbol is a mean for you, the
programmer, to name/identify entities. But somehow, people are having
difficulty understanding this and asked for more explanations. This is
when analogies and categorical statements came in.

"A means for you, the programmer, to name/identify entities" is not a
description of what a symbol *is* so much as a description of how you
can use it. It seems awfully odd to me that everything else in the
language tends to get described in terms of what it actually is under
the hood, then starts getting analogies only if the target of the
explanation doesn't get it, while for some reason nobody starts an
explanation of symbols that way in Ruby.

For example: while saying that a method is "a verb" does help one to
"get" how verbs are used in the language, nobody really knows what a
method is until it's explained that it's a mini-algorithm whose
definition is part of a class definition, accessible by way of instances
thereof. As such, someone always starts explaining what a method is
under the hood pretty quickly when trying to get the point of a method
across in teaching OOP. With symbols, though, I keep seeing bland
assertions that a symbol is "just a name", or "a name that is an
object", or something like that, without any explanation of what a
symbol actually does behind the scenes.

I seem to have missed the blog post that mentioned the relationship to
Lisp methods, but even that didn't really address the matter as clearly
as I would have expected.

While you're at it, define "identifier" within this context.

To help people understanding the meaning of 'identifier', I've been
mentioning it together with 'name': 'name/identify' as in "It is just
a way to name/identify things".

In any case, there is only one definition of identifier so context
should not influence the meaning of it:

From WordNet (r) 2.0 (August 2003) [wn]:

identifier
n : a symbol that establishes the identity of the one bearing it

. . which, unfortunately, in no way explains what one does with a
"symbol" in a programming context in a helpful way.

A symbol is an element (or a reference to an element, though I hesitate
to use the term "reference" with its programming contextual baggage) in
a hash table. A hash table is, in short, a list maintained "by the
language" rather than by the user. From the programmer's point of view,
this list essentially has only values, not keys, though from the
language's point of view it most certainly has keys. This is primarily
useful for applying names to things, thus the common assertion that "a
symbol is a name".

Is that close, or have I missed something?

 

[Chad Perrin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's not really true, though, considering what a symbol is (according to
my current understanding). A symbol is an element of a hash table that
is often used as a name, and it is an (anonymous? not sure how to
qualify that) object. Calling it a "name" seems to be confusing common
use with actual nature, or premature explanation of an abstract way of
thinking about it, depending on how you mean "it is a name" when you say
it. Either way, it seems to be getting the cart before the horse.

Nope, Symbols have nothing to do with Hashes. They are often used
as Hash keys because they are descriptive: h[:foo] is better than
h[1] if one wants to convey some meaning with the key. In other
languages, you might use a string instead of a Symbol (and you
can, of course, do so in ruby as well: h['foo']).

Apparently, a more significant distinction needs to be made between a
"hash table" in the symbol sense of the term and a "hash" in the sense
of an associative array.

 

[Devin Mullins]

The Symbol is just a name.

Er... a thing that /has/ a name. (That being, Symbol#to_s.)

A symbol's just a thing. :apple == :apple. :apple.to_s == "apple".
:apple.to_i == 23417. The end.*

AFAIK, you *can* use a String to do all the things you would do with a
Symbol (i.e. identify things)+, but using Symbols is more fun! (More
performant, possibly, for the purpose of static identifiers, and a
little less line noise, when used as the key to a hash, for example.
Plus, if you're using a text editor with syntax highlighting, they'll
show up a different color, which is fun.)

Devin
* Though I'm not a very good one, I'm a mathematician at heart, so I
like to define things by their properties.
+ This is because all the builtin methods that are meant to take a
Symbol as a parameter tend to call its #== or #eql? or #hash or #to_s
method (the properties of which String mimicks, to an isomorphism), or
allow a String to be passed in its place (as is the case with attr_*, e.g.).

 

[Chad Perrin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



This is another bad aspect of Symbol explanations. Sooner or later
someone mentions 'immediate values' or 'internal symbol tables'.
While accurate (and in some cases, useful knowledge), these are a
big source of confusion and not in any way helpful to understanding
the fairly trivial function of Symbols :/

I disagree. If the underlying semantic mechanism of a symbol isn't
understood, symbols won't be understood.

 

[Devin Mullins]

Er... a thing that /has/ a name. (That being, Symbol#to_s.)

OK, well, I RTFA, and sorry for blatantly contradicting what was an
intentional choice of words (and not, as I had thought, a slip-up)
without reason. Anyways, to quote you:

No. :wilbur is an object. It has *one* property, itself. You can ask for
integer or string representations, but :wilbur's value is :wilbur and
there will only ever be one :wilbur.

Calling it a "name" is just another analogy. Its name is its String
representation, just as Module#name == Module#to_s (for non-singletons).
Rather, :jazz is :jazz is :jazz. There is no reducing it to other concepts.

Devin
Yeah, I know, total 540.

 

[J. Ryan Sobol]

To whom who asked this question, open your console / terminal and type:

ri Symbol

Then type:

ri String

~ ryan ~

 

[Yohanes Santoso]

Calling it a "name" seems to be confusing common use with actual
nature, or premature explanation of an abstract way of thinking
about it, depending on how you mean "it is a name" when you say it.

Well, what can I say? Symbol is really meant to represent a
name/identifier.

Let's stop with analogies since obviously we are not
analogy-compatible, and get on with the concretes.

What is 1? A way to represent the number one. You said a way, what
others are there? 0x1, \001, "1". However, one does not use "1" to
represent the number one even if one doesn't plan to do any arithmetic
operations on that number because that representation is
ambiguous. Does he mean "1" as in number one or as in the character
"1"?

What is :server? A way to represent the name/identifier
``server``. What others are there? "server" is another one. But it is
also ambigious. Does he mean the name/identifier ``server`` or the
character sequence "s","e","r","v","e","r"?

I can see no way to describe 1 without involving number. Similarly, I
can see no way to describe :server without involving
name/identifier. Perhaps you can.

"A means for you, the programmer, to name/identify entities" is not a
description of what a symbol *is* so much as a description of how you
can use it.

I really am not sure what you are saying there. That sentence
describes what a symbol is. That sentence does not describe/prescribe
how to use it.

Here, let me paraphrase my sentence: "[Symbol is] a means for you, the
programmer, to [represent the] name/identit[y] of entities". Did I
manage to preserve the meaning? Let's do word substitution. "Number
is a means for you, the programmer, to represent numbers". In no way
am I describing/prescribing how to use instances of Number.

object", or something like that, without any explanation of what a
symbol actually does behind the scenes.

This is precisely the kind of explanation that I objected when
explaining what a symbol is to a newcomer. Any explanation that refer
to the implementation is doomed to be short-lived. There are many ways
to implement the class Symbol and the concept of symbol.

Do you explain what number does behind the scenes to someone asking
'What is a number?' Do you explain that ruby maps number less than
2^31-1 directly to native integer format? Quick question, then: does
this still hold on a 64-bit machine? How about in ruby 2.0? Will
Number behave differently and is used to represent different thing
there simply because what goes on behind the scene has changed?

If one is interested in how something is implemented in a specific
environment, one should ask for that (and there are posts in this
thread dwelving into how Symbol is implemented in current ruby VM).

In any case, if someone can give me a description of what 1 is without
involving number, then I'll show you a description of what symbol is
without involving name/identifier.

YS.

 

[Devin Mullins]

For the heck of it, I decided to come up with my own Symbol analogy.
Caveat reader:

A symbol is a bubble. In Ruby-land, there is this ever-present *ether*
wherein lies an abundance of bubbles.

<picture of a bunch of bubbles, each with a symbol literal inside --
feel free to Gimp it into existence -- here's a starter kit:
http://www.scrapbookerie.com/images/autocollants/Sticko-Bubbles.jpg>

Every symbol you could ever want is out there, in the ether, bubbling
along. For every name, there is a single bubble. For every bubble, there
is a single name.

When you assign +x = :mr_t+, as with all variable assignments, you're
pointing x to the :mr_t object. Here, you're pointing at that bubble
that the Ruby interpreter recognizes as :mr_t. For plausability reasons,
the Ruby interpreter blows the :mr_t bubble the first time you mention
its name, but for your sake, you can assume that the :mr_t bubble has
always existed and always will exist -- it's just there, floating in the
ether, waiting to be pointed to.

So from that description right there, we already know one thing we can
do with bubbles--er, Symbols--determine equality. Are these two
variables pointing to the same bubble? Find me the Hash value whose
associated key is this bubble I'm pointing to right now. For programming
convenience, these bubbles have names associated with them, but as far
as your code is concerned, they're just bubbles. This is the magic
behind {:server => 'localhost', ort => 80}, etc.

The other (principal) thing you can do with a bubble--eh, Symbol--is
find out its name at runtime (thanks to #to_s or #id2name). Thus,
attr_accessor :mcklellan is born. I'm passing along a pointer to the
:mcklellan bubble. attr_accessor follows the pointer, talks to that
bubble, asks it what its name is, and uses that information to define
some methods. Here, :mcklellan is just used as a fancy shorthand for
'mcklellan'. (It happens to be one I like, but I digress...)

So, uh, yeah. That's it. The End.

Ha, yeah, so that description is probably more unsettling than settling,
but maybe it'll plant a seed of wisdom, or whatnot. Plus, I can rest
easy, now that I've solved everybody's problems.

Devin
Did I really just digress into "The End"?

 

[Austin Ziegler]

Er... a thing that /has/ a name. (That being, Symbol#to_s.)

No, I think that the essential property of a Symbol is that it is an
object that is a name:

keep =3D Symbol.all_symbols
quuxl =3D nil
puts Symbol.all_symbols - keep

You'll see that :quuxl is there. You can get a string representation
of that name quuxl.to_s) or an integer representation of that name
quuxl.to_i), but the canonical representation of that name is the
Symbol itself quuxl). Sure, you could get pedantically
philosophical, but the you'd be saying that 1 really isn't the number,
it's a thing that represents a quantity of one.

For all practical purposes, Symbols are atomic in the sense that they
are themselves. Who *cares* how it's actually represented in the
implementation? That can change. The fundamental nature of a Symbol is
that :quuxl will always be :quuxl and never anything else. Consider
these two IRB sessions:

irb(main):001:0> :bar.to_i
=3D> 23417
irb(main):002:0> :quuxl.to_i
=3D> 23425
irb(main):003:0>

irb(main):001:0> :quuxl.to_i
=3D> 23417
irb(main):002:0> :bar.to_i
=3D> 23425
irb(main):003:0>

A Symbol, like a number, is immediate and is identified by itself.

-austin

 

[Devin Mullins]

Heh, one of my emails to the list got eaten (by a grue?). Let's try this
again:

Er... a thing that /has/ a name. (That being, Symbol#to_s.)

OK, well, I RTFA, and sorry for blatantly contradicting what was an
intentional choice of words (and not, as I had thought, a slip-up)
without reason. Anyways, to quote you:

No. :wilbur is an object. It has *one* property, itself. You can ask for
integer or string representations, but :wilbur's value is :wilbur and
there will only ever be one :wilbur.

Calling it a "name" is just another analogy. Its name is its String
representation, just as Module#name == Module#to_s (for non-singletons).
Rather, :jazz is :jazz is :jazz. There is no reducing it to other concepts.

Devin
Yeah, I know, total 540.

 

[Chad Perrin]

What is 1? A way to represent the number one. You said a way, what
others are there? 0x1, \001, "1". However, one does not use "1" to
represent the number one even if one doesn't plan to do any arithmetic
operations on that number because that representation is
ambiguous. Does he mean "1" as in number one or as in the character
"1"?

Then why not simply say:

:symbol is to "symbol" as 1 is to "1"

That would get the point across far more clearly than saying "A symbol
is just a name," especially since strings can be names (from another
perspective), and since variables are "names" in another sense of the
term, and so on. Saying it's "a name" doesn't explain jack, as far as I
can tell.

Being vague doesn't help.

I really am not sure what you are saying there. That sentence
describes what a symbol is. That sentence does not describe/prescribe
how to use it.

Let's take a look at that sentence's structure and meaning:

A [something] is a means [. . .] to [do something].

Gee, looks like a description of how one uses it. A symbol is a means
to name/identify entities. A screwdriver is a means to turn screws. A
mug is a means to transport coffee. By the same token, however,
telekinesis is a means to turn screws, as is a centrifuge if you really
want to put screws into one, for some definition of "turn". Also, a
hose, a Folger's can, and an eighteen wheeler might be a means for
transporting coffee. It's vague and, ultimately, useless for getting
the point across, that point being: What *is* it?

A screwdriver is a handle affixed to a metal shaft with a bit on the end
that serves as the interface for the screw -- the torque point, if you
will. A mug is a drinking vessel that is ideally suited to beverages
such as coffee, allow you to transport the hot beverage from the coffee
pot to your lips after it has been prepared and poured.

For someone who doesn't already know what a mug or screwdriver actually
is, the mere description of what each is a means to do is far too vague
to actually impart much understanding.

This is precisely the kind of explanation that I objected when
explaining what a symbol is to a newcomer. Any explanation that refer
to the implementation is doomed to be short-lived. There are many ways
to implement the class Symbol and the concept of symbol.

It may be doomed to be short lived, but without some kind of example
that is recognizable, the prospective student is more likely than not to
learn very little of anything.

Do you explain what number does behind the scenes to someone asking
'What is a number?' Do you explain that ruby maps number less than
2^31-1 directly to native integer format? Quick question, then: does
this still hold on a 64-bit machine? How about in ruby 2.0? Will
Number behave differently and is used to represent different thing
there simply because what goes on behind the scene has changed?

Unlike symbols, numbers are pretty well understood, particularly for
someone coming from another programming language (any language except
the original, archetypal "lisp", pre-implementation, involves numbers).
Symbols are another matter entirely.

The problem with most of the descriptions of symbols I've seen is that
they try to define symbols in terms of themselves to people who don't
already understand those terms. A framistan is a thing. Whee. That
taught me nothin'.

This approach to explaining symbols is equivalent to trying to teach
object oriented programming with nothing more than the statement that
"an object is a thing". Okay, great. What kind of thing? What are all
these terms like "method/message" and "class" and "instance" and so on?
There are entire college courses devoted (almost) solely to imparting a
rudimentary understanding of what an "object" is and how it is used.
Why can't someone come up with a better explanation of a symbol than the
five-word sentences that are so common here?

 

[Chad Perrin]

On Fri, Dec 30, 2005 at 01:36:05PM +0900, Eero Saynatkari wrote:

0. :symbol is to "symbol" as 1 is to "1"
Insofar as it is accurate to say that an integer is an atomic
numeral, it is likewise accurate to say that a symbol is an
atomic string, or so it seems to me.

1. Symbols are values.
:foo is like 'foo' or 2 or f = FooObject.new

2. Symbols are used to name, describe or label things.
cd_drive_type = :dvd_rom
socks = my_closet[:sock_drawer]

3. Common usages.
object.send :method_name, parameter # Could use 'method_name'
attr_accessor roperty1, roperty2 # Could use 'property1' etc.

4. Implementation details.

Am I wrong?

 

[gwtmp01]

Sure, you could get pedantically
philosophical, but the you'd be saying that 1 really isn't the number,
it's a thing that represents a quantity of one.

But 1 (as in the ascii character code 49) is *not* the number/object
one.
And the reference value that the Ruby parser constructs when it sees
the ascii character code 49 is also *not* the number/object one.

I don't think it is possible to have a coherent discussion of Ruby
semantics without clearly and consistently differentiating between
an object, a reference to an object, and an identifier that is
bound to a reference to the object. In particular, the semantics
of assignment/equality/identity can't be fully explained without
carefully distinguishing between these ideas.

Yes it sounds very pedantic but the devil is in the details.

Gary Wright

 

[Chad Perrin]

I think one of the hardest things to explain/comprehend
about symbols is that the *only* semantics associated
with a symbol is that there is a one to one mapping from a symbol
object to a sequence of characters. It is this isomorphism that
is the useful (and *only*) property of symbols.

If you want a useful introductory description of symbols for someone
that hasn't encountered them before, the above is the only part of your
previous email that is taking steps in that direction.

 

[Chad Perrin]

Calling it a "name" is just another analogy. Its name is its String
representation, just as Module#name == Module#to_s (for non-singletons).
Rather, :jazz is :jazz is :jazz. There is no reducing it to other concepts.

That's something I've been trying to get across in other emails, but I
don't think I've done a very good job. Thus, using the "symbol is just
a name" analogy doesn't actually explain what a symbol *is*. Analogies
are essentially useless without the technically correct explanation for
them to illustrate.

 

[gwtmp01]

If you want a useful introductory description of symbols for someone
that hasn't encountered them before, the above is the only part of
your
previous email that is taking steps in that direction.

I wasn't trying to produce a useful introductory description
of symbols. Nor do I really think that first paragraph would be all
that appropriate for that purpose. 'Isomorphism' isn't exactly in
common use.

Gary Wright

 

[Gregory Brown]

That's something I've been trying to get across in other emails, but I
don't think I've done a very good job. Thus, using the "symbol is just
a name" analogy doesn't actually explain what a symbol *is*. Analogies
are essentially useless without the technically correct explanation for
them to illustrate.

You know. I'm tired of hearing about how incorrect everyone is and
how they haven't found a solution that meets your needs. It's frankly
becoming insulting.

kill-filed.

 

[Chad Perrin]

I wasn't trying to produce a useful introductory description
of symbols. Nor do I really think that first paragraph would be all
that appropriate for that purpose. 'Isomorphism' isn't exactly in
common use.

Sorry. I didn't mean to suggest that you must intend to produce a
useful introduction. I guess I wasn't clear. I was just saying that
*if* "you" (for some definition of "you") wanted to produce such an
introduction, that one part of your message seemed to be a step in the
right direction. The language wasn't particularly accessible (as you
point out), but the concepts were, and didn't require a firm grounding
in Ruby to understand them.

 

[Chad Perrin]

You know. I'm tired of hearing about how incorrect everyone is and
how they haven't found a solution that meets your needs. It's frankly
becoming insulting.

kill-filed.

hallelujah