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

[Johannes Friestad]

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. ...
Am I wrong?

No, you're right.
The string "123" is a character sequence, and can be picked apart
character by character. The integer 123 is atomic - it cannot be
picked apart on the object level.
Likewise, the string "abc" is a character sequence, and can be picked
apart. The symbol :abc is atomic.

A further similarity between (fixnum) integers and symbols is that
there will always be only one object representing the integer 123, and
only one object representing the symbol :abc. Strings are basically
byte arrays, there can be several strings containing the same
elements.

So I guess you can say that symbols gives a fixnum-style atomic
representation of any given string.

jf

 

[Malte Milatz]

dblack:

Actually, s = :sym doesn't produce a reference to :sym;
rather, s has the actual/immediate value :sym. Anyway, the main (obscured)
point was that symbols are not references.

My understanding of things so far was that :sym and 3 are immediate values,
and after writing
a, b = :sym, 3
a is a reference to :sym and b is a reference to 3.

Have I been wrong all the time?

Malte

 

[Ross Bamford]

dblack:

My understanding of things so far was that :sym and 3 are immediate
values,
and after writing
a, b = :sym, 3
a is a reference to :sym and b is a reference to 3.

Have I been wrong all the time?

I wonder that too. What about:

a, b = :sym, :sym

I guess a and b hold separate references to the same object, much as if I
did

a, b = 4, 4

That was the basis for my mentioning literal fixnums earlier in the ':foo
and "foo"' thread, but now I wonder if I'm in fact wrong (again ).

Basically I suppose I'm confused about assignment by value or reference. I
though Ruby was pass by reference, with references passed by value, no
matter what?

 

[Steve Litt]

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.

And now you have identified the crux of all the misunderstanding (and I think
"misunderstanding" is the right word, given that tens of people smarter than
me disagree with each other on how to describe a symbol).

Long time Rubyists, people with heavy CS studies, and people who have
experience in languages with symbols (LISP, I guess) tend to talk more about
how it's implemented, while programmers (probably without CS degrees)
migrating from languages not containing symbols are more interested in what
it does than how it's implemented.

I asked if it's an object with 2 attributes, an integer key and a string
value. Someone says no, it's an object with one attribute that can be seen 2
ways, a string or an integer. From my point of view, he's saying the same
thing. I was describing what it can do for me, he was describing something
truer to the implementation, but when actually using the little bugger either
explanation will lead to correct programming, at least if I understand it
correctly (and I think I now understand it correctly, at least correctly
enough to know how and when to use a symbol).

One thing I know for sure -- the length and bredth of this thread indicates
for sure that Ruby symbols need much better documentation. Austin Ziegler has
made an excellent start. I volunteer to give input from an imigrant from Perl
land (and C, C++, and about a dozen others but not lisp) whose BS degree is
in Electrical Engineering and whose computer programming classes were limited
to the very practical stuff they taught at Santa Monica Community College.

SteveT

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

 

[dblack]

Hi --

-----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 :/

"Immediate value" is not a useless or arcane notion. (And I did *not*
mention the internal symbol table In fact, understanding that
some variable assignments result in variables that hold immediate
values, and others result in variables that hold references, is quite
important, if you want to understand, for example, the whole lack of
post-increment operator thing (i.e., the fact that, given x = 1, x++
and 1++ are the same expression, etc.).

I agree that part of the problem with people understanding Symbols is
the tendency to expect, and look for, more than is there -- but I'd
maintain that to understand Ruby identifiers fully, you really need to
be aware of the (not terribly difficult) notion of immediate values
vs. references.


David

--
David A. Black
(e-mail address removed)

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black

 

[Steve Litt]

That just means you didn't dig deep enough into Ruby (yet). ;-)

Then neither did the 20+ other people, some long time Ruby users, who couldn't
put forth an explanation clear enough to settle the issue amongst the
majority.

With all the controversy, including some piping to a killfile, the issue isn't
*my* depth of digging, it's either *everyone's* depth of digging, or it's an
issue of :symbols being a particularly surprising element of Ruby. I haven't
heard this level of disagreement about blocks, methods, iterators and the
like. Heck, for two cents I'll document it myself!

SteveT

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

 

[Austin Ziegler]

Long time Rubyists, people with heavy CS studies, and people who have
experience in languages with symbols (LISP, I guess) tend to talk more
about how it's implemented, while programmers (probably without CS
degrees) migrating from languages not containing symbols are more
interested in what it does than how it's implemented.

And what I've been trying to get across, Steve, is that Symbols don't
actually *do* anything. Nothing. Zero. Zip. ABSOLUTELY NADA! They're
names with the special property that the name uniquely identifies the
object. :wilbur always identifies :wilbur.

I asked if it's an object with 2 attributes, an integer key and a
string value. Someone says no, it's an object with one attribute that
can be seen 2 ways, a string or an integer. From my point of view,
he's saying the same thing.

Then you didn't understand the answer if you saw them as the same. What
I said (rephrasing; I'm too lazy to look up what I really said) is
essentially that a Symbol has one value: itself. If you will, its name.

puts :wilbur.inspect=09# =3D> :wilbur

You can *convert* a Symbol to a string:

puts :wilbur.to_s=09=09# =3D> wilbur

You can *convert* a Symbol to an integer value:

puts :wilbur.to_i=09=09# =3D> 23569 !! This value can change !!

But both #to_s and #to_i are conversions, not attributes of the Symbol.
The Symbol's only attribute is ... itself. Just like a Fixnum's only
attribute is ... itself.

puts 1.inspect=09=09# =3D> 1

Look at what Symbol.instance_methods(false) returns:

["inspect", "to_int", "=3D=3D=3D", "to_s", "to_sym", "to_i", "id2name"]

Symbol doesn't otherwise provide any methods not provided by Object (or
Kernel), and most of those listed above are conversion methods.

[...]

Hopefully that's a bit clearer. It's not that different from Perl
barewords.

-austin

 

[Steve Litt]

It's not that different from Perl
barewords.

I plead ignorance on Perl barewords. I use "use strict" every time.

SteveT

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

 

[Christer Nilsson]

Amazing!

This is the 98th comment in this thread! Longest in december.
If we go further we have to discuss on the transistor level...

Christer

 

[Gregory Brown]

Personally, I don't know why people have such big
problems with Symbol, and I'll probably not ever understand. Just
take them for granted and use them.

Amen!

Sorry if this has already been posted but Kevin Clark gives a good
explanation of Ruby Symbols in his article _Understanding Ruby
Symbols_

http://glu.ttono.us/articles/2005/08/19/understanding-ruby-symbols

Now i'm not sure that this has enough detail for the pedantic* but he
certainly makes the case for USING symbols.

Hope this helps shed some light, as this thread is getting painfully long.

-Greg

* seriously we should find a new word, search the archive for this
week to see what I mean!
On the lighter sides of things... I've searched for new ways to call
each other or ourselves pedantic, which hopefully the erudites among
us will pick apart

abstruse, academic, arid, didactic, doctrinaire, donnish, dry, dull,
egotistic, erudite, formal, fussy, hairsplitting, learned, nitpicking,
ostentatious, overnice, particular, pedagogic, pompous, precise,
priggish, punctilious, scholastic, schoolish, sententious, stilted

 

[Christer Nilsson]

The original poster, Surgeon, wrote only two comments.
This is his second, sixty comments ago:

Oh, so many replies to my poor question! What a wonderful community!

I guess, he was forgotten somewhere around five

Next comment will be number 100!

Christer

 

[gwtmp01]

The original poster, Surgeon, wrote only two comments.
This is his second, sixty comments ago:


I guess, he was forgotten somewhere around five

Next comment will be number 100!

Yikes. I hope we don't start behaving like the Slashdot community
where everyone races to post the message "this is the first message".

Gary "did I submit the 100th message?" Wright

 

[Gregory Brown]

Gary "did I submit the 100th message?" Wright

Actually. Not according to ruby-forum. The message before yours was
the 100th

But nothin' wrong with being 101.

Gary Wright, Symbols 101. Hey, didn't you teach that class a couple
weeks ago?

-Greg (102... i think)

 

[Steve Litt]

On Friday 30 December 2005 10:35 am, Steve Litt wrote:
[clip]

With all the controversy, including some piping to a killfile, the issue
isn't *my* depth of digging, it's either *everyone's* depth of digging, or
it's an issue of :symbols being a particularly surprising element of Ruby.
I haven't heard this level of disagreement about blocks, methods, iterators
and the like. Heck, for two cents I'll document it myself!

SteveT

The Ruby Newbie Guide to Symbols is here:

http://www.troubleshooters.com/codecorn/ruby/symbols.htm

SteveT

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

 

[Austin Ziegler]

On Friday 30 December 2005 10:35 am, Steve Litt wrote:
[clip]

With all the controversy, including some piping to a killfile, the issu= e
isn't *my* depth of digging, it's either *everyone's* depth of digging,= or
it's an issue of :symbols being a particularly surprising element of Ru= by.
I haven't heard this level of disagreement about blocks, methods, itera= tors
and the like. Heck, for two cents I'll document it myself!

SteveT

The Ruby Newbie Guide to Symbols is here:

http://www.troubleshooters.com/codecorn/ruby/symbols.htm

Steve:

Please edit your guide, as it is *not* correct when it says:

A Ruby symbol is a thing that has both a number (integer) and a string.

This is not correct in any way. If you leave it as "A Ruby Symbol is a
thing", you're fine. But when you say that it "has" a number and a
string, you are incorrect. Symbols are not composed of the integer or
string values that you can convert Symbols to; they just are. The
value of a Symbol is not its String value or its Fixnum value, but
itself.

I strongly recommend rewriting your guide from that perspective,
because you are likely to greatly *increase* the confusion of newbies.
If you would like, I can see about possibly helping you edit this or
coauthor it such that it might become a useful article to be published
at Ruby Code & Style to explain where Symbols can be used and what
they are. Ultimately, though, trying to dig into the internals of
Symbols misses the point -- it's just something that represents
itself.

-austin

 

[Kirk Haines]

Please edit your guide, as it is *not* correct when it says:

A Ruby symbol is a thing that has both a number (integer) and a string.

This is not correct in any way. If you leave it as "A Ruby Symbol is a
thing", you're fine. But when you say that it "has" a number and a
string, you are incorrect. Symbols are not composed of the integer or
string values that you can convert Symbols to; they just are. The
value of a Symbol is not its String value or its Fixnum value, but
itself.

I think that I am probably the source for this confusion, and I am guilty of
not clarifying further what I meant.

:foo is a symbol. The string representation of :foo is 'foo'.

:foo.to_s

:foo also has an integer that id, found with #object_id:

:foo.object_id

This is no different than any other object. What is different is this:

irb(main):001:0> 'foo'.object_id
=> -609482574
irb(main):002:0> 'foo'.object_id
=> -609486184
irb(main):003:0> 'foo'.object_id
=> -609489724

The id changes because each 'foo' is a different object.

irb(main):004:0> :foo.object_id
=> 3957006
irb(main):005:0> :foo.object_id
=> 3957006
irb(main):006:0> :foo.object_id
=> 3957006

The id doesn't change because :foo is just :foo -- it's the same object every
time.


Kirk Haines

 

[Steve Litt]

On Friday 30 December 2005 10:35 am, Steve Litt wrote:
[clip]

With all the controversy, including some piping to a killfile, the
issue isn't *my* depth of digging, it's either *everyone's* depth of
digging, or it's an issue of :symbols being a particularly surprising
element of Ruby. I haven't heard this level of disagreement about
blocks, methods, iterators and the like. Heck, for two cents I'll
document it myself!

SteveT

The Ruby Newbie Guide to Symbols is here:

http://www.troubleshooters.com/codecorn/ruby/symbols.htm

Steve:

Please edit your guide, as it is *not* correct when it says:

A Ruby symbol is a thing that has both a number (integer) and a string.

This is not correct in any way. If you leave it as "A Ruby Symbol is a
thing", you're fine. But when you say that it "has" a number and a
string, you are incorrect. Symbols are not composed of the integer or
string values that you can convert Symbols to; they just are. The
value of a Symbol is not its String value or its Fixnum value, but
itself.

Hi Austin,

I have no idea of the internal representation, but I do know when I use to_s
on a symbol I get a string, and when I use to_i on that same symbol I get an
integer, so in a generic, non-ruby-dependent way, it has an integer and a
string. If it didn't "have" or "possess" or "be cognisant of" both the
integer and the string, I wouldn't be able to deduce the string and integer
with to_s and to_i.

Once again, this document is not meant for Ruby veterans, and its intention
was never to explain symbols in Ruby terms. This document does not pretend to
portray how Ruby really stores a symbol, or even what a symbol is beyond the
basics necessary to use it. This document simply presents a *model* that is
handy in forming a very basic understanding leading to correct use of
symbols.

Light is something more complicated than either a wave or a particle, and yet
discussing it as waves and particles helped me understand light to some
degree in high school physics class. Had I majored in Physics on college, I
would have learned where reality departed from the wave and particle models.

I strongly recommend rewriting your guide from that perspective,
because you are likely to greatly *increase* the confusion of newbies.

I think it will *decrease* newbie confusion about how to use symbols, and how
to read other peoples code containing symbols.

If somebody could show me some actual code where the model I represent in the
document leads to somebody mis-coding a program, I'll reconsider.

As far as the document's departure from actual Ruby implementation, the doc
warns up front that this does not necessarily conform to actual
implementation in Ruby.

If you would like, I can see about possibly helping you edit this or
coauthor it such that it might become a useful article to be published
at Ruby Code & Style to explain where Symbols can be used and what
they are.

Ultimately, though, trying to dig into the internals of
Symbols misses the point

That's exactly my motivation for writing it the way it was written. Thinking
about the Ruby internals at too early a stage muddies the water.

-- it's just something that represents
itself.

That's true, but it's not sufficient to help a newbie understand code
containing symbols, nor is it sufficient to help a newbie.

To summarize, I'm not for a moment disputing your portrayal of Ruby's
implementation of symbols. I'm simply saying that the *model* I present in
the document enables Ruby newbies to quickly understand, on a basic level,
other peoples code that uses symbols, and enable them to use symbols
correctly in their own code.

Thanks

SteveT

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

 

[Steve Litt]

I think that I am probably the source for this confusion, and I am guilty
of not clarifying further what I meant.

:foo is a symbol. The string representation of :foo is 'foo'.
:
:foo.to_s
:
:foo also has an integer that id, found with #object_id:
:
:foo.object_id

This is no different than any other object. What is different is this:

irb(main):001:0> 'foo'.object_id
=> -609482574
irb(main):002:0> 'foo'.object_id
=> -609486184
irb(main):003:0> 'foo'.object_id
=> -609489724

The id changes because each 'foo' is a different object.

irb(main):004:0> :foo.object_id
=> 3957006
irb(main):005:0> :foo.object_id
=> 3957006
irb(main):006:0> :foo.object_id
=> 3957006

The id doesn't change because :foo is just :foo -- it's the same object
every time.


Kirk Haines

Hi Kirk,

I could swear that's exactly what I said in the Ruby Newbie Guide to Symbols.
I like your code-centric way of saying it, though.

SteveT

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

 

[Caleb Tennis]

I have no idea of the internal representation, but I do know when I use

to_s on a symbol I get a string, and when I use to_i on that same symbol I
get an integer, so in a generic, non-ruby-dependent way, it has an integer
and a string. If it didn't "have" or "possess" or "be cognisant of" both
the integer and the string, I wouldn't be able to deduce the string and
integer with to_s and to_i.

I think the nomenclature of "has" isn't valid because the symbol doesn't
contain those things. Much like

a = "53"
a.to_i

=> 53

"a" doesn't contain an integer. It does, however, contain a method that
allows you to convert it to an integer representation.

 

[Kirk Haines]

I could swear that's exactly what I said in the Ruby Newbie Guide to
Symbols. I like your code-centric way of saying it, though.

It could be what you said. I am leaving to get a needle stuck into my arm
in a moment and haven't read more than Austin's comment about your writeup,
so far.


Kirk Haines