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

[Yohanes Santoso]

While, technically speaking, both of you are absolutely and
undeniably correct (with one correction: Symbols are not Strings),
such a conflation is the best way to get someone over the
initial confusion.

The initial confusion is simply part of the learning curve rubyists
must go through along with learning that 'everything' is an
object. Dumbing down the situation can bring unexpected result:

Since we are around Christmas, I'm going to use Santa Claus as an
example. To prevent the initial confusion of children finding presents
magically appearing before Christmas tree, parents resort to such
outlandish notion that that is the work of a joyful guy who has never
heard of razor in a red jumper suit and riding reinders-pulled sleigh
around the world in one night.

Some children outgrew that notion. Some don't. Those that don't would
either sulk for a long time about the demise of such a joyful guy, or
start to think their parents are liars and spend the next untold years
of their life learning enough Math and Physics to prove that it is
impossible for a guy like Santa Claus to visit all children in one
night.

As this thread quite well demonstrates,
a definition for Symbols is quite difficult to come up with.

A formal definition is difficult to formulate correctly, but what CLHS
has is good enough:

"Symbols are used for their object identity to name various entities
in Common Lisp, including (but not limited to) linguistic entities
such as variables and functions." --
http://www.lisp.org/HyperSpec/Body/syscla_symbol.html#symbol

It is just a way to name/identify things. In RL, you name/identify
that collection of atoms 'bird', and another collection of atoms
'cow'. In ruby, you name/identify an object 'host', and another object
'port'. Just as you name parts of collection of atom that you named
'bird' 'wings', 'legs', 'feathers', etc., you name parts of a
Hashtable that you named 'ServerConfig' 'host', 'port'.

Just as one does not dumbed down "'everything' is an object in ruby",
which is a powerful ability, one should not dumbed down "symbols are
user-defined identifiers". It's just parts of learning curve.

 

[dblack]

Hi --

I think it's because A LOT of us were wondering the same thing. In general,
RUBY conforms beautifully to Eric Raymond's "Rule of Least Surprise". IMHO

s/RUBY/Ruby/ In Ruby, P[olicy]OLS refers to what does or does not
surprise Matz.

symbols are an exception.

A little surprise is OK. As Yohanes says, it's part of the learning
curve -- and Ruby does have a learning curve, even though it's
relatively gentle. The language has to be "allowed" to do things in a
way that are not identical to what programmers of other languages
expect. Otherwise its existence would serve no purpose.

Just out of curiosity: can you describe how symbols would work if
they weren't surprising?


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]

Hi --

I think it's because A LOT of us were wondering the same thing. In
general, RUBY conforms beautifully to Eric Raymond's "Rule of Least
Surprise". IMHO

s/RUBY/Ruby/ In Ruby, P[olicy]OLS refers to what does or does not
surprise Matz.

symbols are an exception.

A little surprise is OK. As Yohanes says, it's part of the learning
curve -- and Ruby does have a learning curve, even though it's
relatively gentle. The language has to be "allowed" to do things in a
way that are not identical to what programmers of other languages
expect. Otherwise its existence would serve no purpose.

Just out of curiosity: can you describe how symbols would work if
they weren't surprising?

They wouldn't exist, or they wouldn't be called symbols. If I'm referring t=
o=20
an instance instead of a value, I could call it &variable as in C, or I cou=
ld=20
call it :variable, but in that case I'd call it a reference, not a symbol.

Personally, I think of the referencing and dereferencing in C as being=20
unsurprising. C has plenty of surprises, but referencing and dereferencing =
is=20
not one.

=46rom what I understand, symbols are used for things other than naming=20
objects/variables. In such cases, it would be less surprising if they had a=
=20
different syntax than the ones that name objects.

A little surprise is OK. The subtle differnces of do/end and {/} in blocks =
is=20
a little surprise. But in my opinion, symbols and their uses is a blizzard =
on=20
the equator type surprise.

The fact that symbols cause so much more confusion than most other Ruby=20
facilities is an indicator. AFAIK there has been no good documentation on=20
symbols. When I mean good, I mean like the thoughts that have gone into thi=
s=20
thread -- thoughts valuable to the person who doesn't yet know symbols by=20
instinct, at which time the documentation is moot anyway.

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

 

[dblack]

Hi --

They wouldn't exist, or they wouldn't be called symbols. If I'm referring to
an instance instead of a value, I could call it &variable as in C, or I could
call it :variable, but in that case I'd call it a reference, not a symbol.

But it's not a reference; it's an object, of class Symbol. If you do:

s = :sym

then the variable s holds a reference to the object :sym, just as when
you do:

a = []

a holds a reference to that array.

Personally, I think of the referencing and dereferencing in C as being
unsurprising. C has plenty of surprises, but referencing and dereferencing is
not one.

Referencing and related things are so completely different as between
Ruby and C, though. They really don't map onto each other at all.

objects/variables. In such cases, it would be less surprising if they had a
different syntax than the ones that name objects.

They do; they have a literal constructor sym). That's always a
symbol first and foremost; and if there happens to be a method called
"sym", there may be some contexts in which you can use a symbol to
refer to it, but that's only because something is implemented to do
that (such as: obj.methodsym)).

I think one important key to understanding symbol objects is their
immediacy. When you see :sym, it's very similar to seeing an integer.
It *is* the object. What gets done with the object, or what methods
do or do not know how to use it to pry out methods or other things, is
secondary.


David

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

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

 

[James Edward Gray II]

They wouldn't exist, or they wouldn't be called symbols. If I'm
referring to
an instance instead of a value, I could call it &variable as in C,
or I could
call it :variable, but in that case I'd call it a reference, not a
symbol.

You are still confused. <laughs>

Symbols are nothing like references. They would be much closer to
enums, if you want a C-ish comparison.

James Edward Gray II

 

[Kirk Haines]

They wouldn't exist, or they wouldn't be called symbols. If I'm referring
to an instance instead of a value, I could call it &variable as in C, or I
could call it :variable, but in that case I'd call it a reference, not a
symbol.

It's not a reference. Symbols are much simpler than that. Really. They are
just an integer with some sequence of characters to represent it, all wrapped
up in an object.

:foo has nothing to do with a variable named @foo, or a method named foo() or
anything else. It's just the characters "foo" associated with an integer.
That association lasts for the life of the Ruby interpreter process.

That's all there is to it. They are _simple_ constructs. My hunch is that
the confusion for people new to the language is simply that they are trying
to map them to something more complex than Symbols really are, and they don't
happen to find any clear, concise, handy documentation to explain them.


Kirk Haines

 

[Austin Ziegler]

They wouldn't exist, or they wouldn't be called symbols. If I'm referring= to
an instance instead of a value, I could call it &variable as in C, or I c= ould
call it :variable, but in that case I'd call it a reference, not a symbol=

 

[Chad Perrin]

A formal definition is difficult to formulate correctly, but what CLHS
has is good enough:

"Symbols are used for their object identity to name various entities
in Common Lisp, including (but not limited to) linguistic entities
such as variables and functions." --
http://www.lisp.org/HyperSpec/Body/syscla_symbol.html#symbol

Ever since this discussion started, I've wondered if there was some
relationship between Ruby symbols and Lisp symbols. This is the first
thing I've seen that seemed to indicate that, though. Prior to this
quote you provided, everything that has been said in this discussion of
Ruby symbols has seemed to indicate that there is zero relationship
between the two.

So tell me: Is a Ruby symbol basically just an object oriented
implementation of the Lisp concept of a symbol? If that's the case,
what's up with all this tripe about "a symbol is just a name" and so on?
I get the distinct impression that either there's no real relationship
between Ruby symbols and Lisp symbols, or else all the people trying to
explain Ruby symbols don't much know what they're talking about.

It is just a way to name/identify things. In RL, you name/identify
that collection of atoms 'bird', and another collection of atoms
'cow'. In ruby, you name/identify an object 'host', and another object
'port'. Just as you name parts of collection of atom that you named
'bird' 'wings', 'legs', 'feathers', etc., you name parts of a
Hashtable that you named 'ServerConfig' 'host', 'port'.

Until you mentioned the hash table in that paragraph, it didn't make any
sense at all. I think these analogies are doing a disservice to people
trying to get a read on what a symbol is in Ruby. You might as well go
back to trying to explain OOP with truck analogies, which never worked
worth a damn for explaining the concept either, if you are going to do
that. It's impressively frustrating trying to make heads or tails of
this discussion of Ruby symbols: people are full of analogies and
categorical statements that don't really explain anything, but there
isn't a whole lot of substance to it.

If you tell me that Ruby symbols are basically just Lisp symbols,
implemented in an OOP way by way of a symbol class, I think I could
probably come up with a succinct and clear explanation of what a Ruby
symbol is that would remove a lot of the ambiguity, but so far I still
don't know if that's what a Ruby symbol actually is.

Just as one does not dumbed down "'everything' is an object in ruby",
which is a powerful ability, one should not dumbed down "symbols are
user-defined identifiers". It's just parts of learning curve.

Dumb down? No, never. Try explaining it, though. Identifier for what?
While you're at it, define "identifier" within this context.

 

[Jonathan Simms]

The difference is that your version measures more than just hash
access
speed. It also includes string and symbol creation times. In
particular, to create a symbol, you must first create a string, so you
have twice as many object creations when using symbols.

This version (I believe) shows that by using a string literal, you're
paying for the creation of a string object with each invocation, whereas
by using a symbol, you only pay for the interning once, but on each
subsequent usage, you're using a reference to a singleton.


slyphon@willie ~ $ cat /tmp/bmrk.rb
#!/usr/bin/env ruby

require 'benchmark'

n = 1_000_000
string_hash, symbol_hash = {}, {}


Benchmark.bm(10) do |b|
b.report("string set"){ n.times{|x| string_hash["foo"] = rand}}
end
Benchmark.bm(10) do |b|
b.report("symbol set"){ n.times{|x| symbol_hash[:foo] = rand}}
end


slyphon@willie ~ $ ruby /tmp/bmrk.rb
user system total real
string set 1.270000 0.000000 1.270000 ( 1.274019)
user system total real
symbol set 0.880000 0.000000 0.880000 ( 0.877080)
slyphon@willie ~ $


- Jonathan Simms

 

[Steve Litt]

It's not a reference. Symbols are much simpler than that. Really. They
are just an integer with some sequence of characters to represent it, all
wrapped up in an object.

OK, let me see if I'm correctly understanding you.

:wilbur is an object. That object has two properties, which one could call, in
generic and not Ruby terms, a key and a value. The key is an integer. The
value is "wilbur". Neither the key nor the value can be changed during the
execution of the program. When we write:

attr_accessor :wilbur

what really happens is that the function attr_accessor() takes symbol :wilbur
as an argument, tacks on a @ to the string's value in order to make the true
class variable @wilbur, and then writes a tiny get and set functions whose
names are wilbur, such that:

my_object.wilbur = 22
puts my_object.wilbur

So my initial comment that it seemed like magic is true only to the extent
that the "magic" performed by attr_accessor is to create the set and get
methods with the same name as the symbol that is its argument.

Do I understand what you're saying?

Thanks

SteveT

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

 

[Edward Faulkner]

--pZs/OQEoSSbxGlYw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

If you tell me that Ruby symbols are basically just Lisp symbols,
implemented in an OOP way by way of a symbol class, I think I could
probably come up with a succinct and clear explanation of what a Ruby
symbol is that would remove a lot of the ambiguity, but so far I still
don't know if that's what a Ruby symbol actually is.

Yes, I think Ruby symbols and Lisp symbols are the same thing. The
issue is just slightly obscured because Ruby glosses over the Lisp
concept of "quote" by building the quote syntax directly into the
symbol-literal syntax. :mysymbol means the same thing as Lisp's
'mysymbol, except the whole thing is treated as a single literal
token, instead of parsing to (quote mysymbol).




--pZs/OQEoSSbxGlYw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDtBg1nhUz11p9MSARAmawAKDCJvF7LEGbQV5YfO5Bp+rmtTx5jgCdFj6P
F34IR6crkRP6h0kdbKFxgFY=
=1RoP
-----END PGP SIGNATURE-----

--pZs/OQEoSSbxGlYw--

 

[Steve Litt]

http://www.oreillynet.com/ruby/blog/2005/12/symbols_strings_methods_and_va.
html

Thanks Austin,

I *think* that article brought me closer to understanding. Armed with your
article and all the other responses, I replied to Kirk Haines' post with my
interpretation of what you all were saying.

By the way, your article is obviously needed, and you should probably refine
it as time goes on. The fact that we had so many responses that at least in
part contradicted each other indicates to me that symbols are perhaps the
most surprising element of Ruby, which is otherwise not a surprising language
at all.

Thanks for the great blog entry.

SteveT

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

 

[A LeDonne]

What
makes Symbols "special" in the current implementation is that a Symbol
is created for every named item.
[:quuxl]

But as I stated in the blog entry I posted above, the Symbol is just a
name. What gives a Symbol its power is the thing that uses it, such as
attr_accessor. Symbols are names. No more, no less.

Really, I think that people create the confusion for themselves,
expecting them to be more than they are.

-austin

I think that the same thing that "makes symbols 'special' in the
current implementation" is what creates confusion for people.

I know that the idea that the "thingy" in the symbol table is the same
"thingy" represented by an immediate object that has a literal
representation seemed very voodoo/black magic to me at first, coming
from languages where the symbol table is a hidden, reserved, internal
sort of structure. From the outside, Symbols look like they were
invented solely to facilitate meta-programming, which is why they have
all the "name" conceptual baggage attached.

In other words, to a non-Rubyist, a natural question to ask is, "If
you didn't need easy access to names in or destined for the symbol
table, would Symbol objects exist in Ruby?" (Probably followed by "And
why do you need access to names in the symbol table, anyway?")

-A

 

[Chad Perrin]

Yes, I think Ruby symbols and Lisp symbols are the same thing. The
issue is just slightly obscured because Ruby glosses over the Lisp
concept of "quote" by building the quote syntax directly into the
symbol-literal syntax. :mysymbol means the same thing as Lisp's
'mysymbol, except the whole thing is treated as a single literal
token, instead of parsing to (quote mysymbol).

Thank you.

 

[James Edward Gray II]

When we write:

attr_accessor :wilbur

what really happens is that the function attr_accessor() takes
symbol :wilbur
as an argument, tacks on a @ to the string's value in order to make
the true
class variable @wilbur,

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

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

and then writes a tiny get and set functions whose
names are wilbur, such that:

my_object.wilbur = 22
puts my_object.wilbur

So my initial comment that it seemed like magic is true only to the
extent
that the "magic" performed by attr_accessor is to create the set
and get
methods with the same name as the symbol that is its argument.

"Magic" to me is the tricky stuff and I don't see any of that here.
We just told it the name for a method we wanted. You could easily
code a pure Ruby replacement for the attr* methods, so it's really
just a shortcut with Ruby doing some work for you. No magic there.

James Edward Gray II

 

[Kirk Haines]

OK, let me see if I'm correctly understanding you.
Yep!

what really happens is that the function attr_accessor() takes symbol
:wilbur as an argument, tacks on a @ to the string's value in order to make
the true class variable @wilbur, and then writes a tiny get and set
functions whose names are wilbur, such that:

my_object.wilbur = 22
puts my_object.wilbur

So my initial comment that it seemed like magic is true only to the extent
that the "magic" performed by attr_accessor is to create the set and get
methods with the same name as the symbol that is its argument.

Do I understand what you're saying?

That is exactly what happens.

And because that is what happens, one can write attr_accessor-like methods
oneself, if there is something additional/different that you want to have
happen. The symbol is just a tool.


Kirk Haines

 

[Austin Ziegler]

OK, let me see if I'm correctly understanding you.

:wilbur is an object. That object has two properties, which one could
call, in generic and not Ruby terms, a key and a value. The key is an
integer. The value is "wilbur". Neither the key nor the value can be
changed during the execution of the program. When we write:

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.

attr_accessor :wilbur

what really happens is that the function attr_accessor() takes symbol
:wilbur as an argument, tacks on a @ to the string's value in order to
make the true class variable @wilbur, and then writes a tiny get and
set functions whose names are wilbur, such that:

Sort of. In the link that I posted for you earlier, you'll note that I
wrote an accessor generator (md5_accessor) which can be used to create
accessors that deal with variables named completely differently than the
accessors.

The method Module#attr_accessor will take the symbol and use it as a
name to create accessors (#wilbur and #wilbur=3D) that *coincidentally*
work on a variable of the same name. It doesn't *create* that variable.

my_object.wilbur =3D 22
puts my_object.wilbur

So my initial comment that it seemed like magic is true only to the
extent that the "magic" performed by attr_accessor is to create the
set and get methods with the same name as the symbol that is its
argument.

You are correct in this last. The "magic" is in attr_accessor, not in
the Symbol. The Symbol is just a name.

-austin

 

[Yohanes Santoso]

Prior to this quote you provided, everything that has been said in
this discussion of Ruby symbols has seemed to indicate that there is
zero relationship between the two.

The first line of my journal (third post in this thread) already
mentions "The concept of symbols have been popular among the lisp
community...".

So, there is not zero relationship between the two. Before coming to
ruby, I was already familiar with elisp and dabled some in CL. A quick
reading of the then scampy documentation of ruby Symbol revealed that
they are just different implementations of the same concept. But they
are not the same. ruby's symbol is CL&elips symbol minus attributes
(symbol value, property list, etc.)

So tell me: Is a Ruby symbol basically just an object oriented
implementation of the Lisp concept of a symbol?

Yes: different implementations of the same concept. No: CL&elisp's
Symbol has more functionalities.

If that's the case, what's up with all this tripe about "a symbol is
just a name" and so on?

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?

I think these analogies are doing a disservice to people trying to
get a read on what a symbol is in Ruby.

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.

people are full of analogies and categorical statements
that don't really explain anything

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.

Dumb down? No, never. Try explaining it, though.

As this and many other previous threads about symbol have shown,
explaining the concept of symbol is not easy.

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



YS.

 

[Johannes Friestad]

Ever since this discussion started, I've wondered if there was some
relationship between Ruby symbols and Lisp symbols..
So tell me: Is a Ruby symbol basically just an object oriented
implementation of the Lisp concept of a symbol?

Yes, the concept of a symbol in Ruby is the same as in Lisp. Just as
similar as the concepts for integers, strings, arrays and other basic
constructs.

I think the confusion comes from two areas:

1) Not many languages has 'symbol' as a distinct data type. Java has
interned strings, which are pretty close to symbols for most practical
purposes (symbols are atomic, immutable and unique, Java interned
strings are just immutable and unique), but they are not a separate
datatype.

2) It is not immediately obvious why symbols are useful. Numbers and
arrays/lists are easily explained as representing numbers and 'a
construct to hold multiple values', but there is no such simple
explanation for symbols. Not that I know of, anyway.

jf

 

[dblack]

Hi --

Hi --

They wouldn't exist, or they wouldn't be called symbols. If I'm referring
to
an instance instead of a value, I could call it &variable as in C, or I
could
call it :variable, but in that case I'd call it a reference, not a symbol.

But it's not a reference; it's an object, of class Symbol. If you do:

s = :sym

then the variable s holds a reference to the object :sym, just as when
you do:

a = []

a holds a reference to that array.

This assertion by me seems to have been mercifully ignored in
subsequent discussion 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.

I think one important key to understanding symbol objects is their
immediacy. When you see :sym, it's very similar to seeing an integer.
It *is* the object. What gets done with the object, or what methods
do or do not know how to use it to pry out methods or other things, is
secondary.

Here's where the s = :sym example should have been, since otherwise
I'm really talking about the literal constructor, which wasn't (i.e.,
shouldn't have been) the main point.

Anyway, I just wanted to ungarble that post a little


David

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

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