[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Paul Graham explains Ruby symbols

ramalho@gmail.com

3/7/2007 1:14:00 AM

Paul Graham offers this excellent explanation for the symbol type:

"Symbols are effectively pointers to strings stored in a hash table.
So you can test equality by comparing a pointer, instead of comparing
each character." [1]

Of course, he's talking about symbols in Lisp, but what he says
applies equally well to Ruby and Smalltalk.

Cheers,

Luciano

[1] http://paulgraham.com...
27 Answers

Rick DeNatale

3/7/2007 5:17:00 PM

0

On 3/6/07, Luciano Ramalho <ramalho@gmail.com> wrote:
> Paul Graham offers this excellent explanation for the symbol type:
>
> "Symbols are effectively pointers to strings stored in a hash table.
> So you can test equality by comparing a pointer, instead of comparing
> each character." [1]
>
> Of course, he's talking about symbols in Lisp, but what he says
> applies equally well to Ruby and Smalltalk.

I find this a little too implementation-centric a description.

The key aspect of symbols is that two symbols are identical if they are equal.
The fact that there may (or may not be) a hash table used to ensure
this is irelevant.

And that description really misses the boat as far as Lisp is
concerned. Lisp symbols aren't strings, they are really names to which
three (separate) things can be bound, a value (which can be any Lisp
object), a function, and a property list. Actually the name is also
one of the slots in a symbol.
Note that in Lisp the value of a Symbol is separate from it's name,
and two Symbols can have the same value, they just can't have the same
name.

So in Lisp a symbol is more like an entry in the table of global names.

Symbols in Ruby and Smalltalk are more alike than Symbols in Lisp.

Smalltalk and Ruby symbols have unique 'values' which are also their 'names'.

Most Smalltalk implementations make Symbol a subclass of String,
although I'm pretty sure that we didn't require this when we wrote the
X3J20 ANSI Smalltalk spec (We didn't require much if any particular
inheritance hierarchy). Ruby does not treat Symbols as Strings,
although one can obtain an instance of either from an instance of the
other.

Not long ago Matz experimented with the idea of making Symbol a
subclass of String in 1.9, but this appears to have been dropped in
more recent versions.

--
Rick DeNatale

Bharat Ruparel

3/7/2007 7:21:00 PM

0

I think of symbols is immutable strings that are useful only in
referring to some values? Seems like a nice way for using pointers
without all the warps?
Bharat

--
Posted via http://www.ruby-....

Gregory Seidman

3/7/2007 8:03:00 PM

0

On Thu, Mar 08, 2007 at 04:21:10AM +0900, Bharat Ruparel wrote:
> I think of symbols is immutable strings that are useful only in
> referring to some values? Seems like a nice way for using pointers
> without all the warps?

Symbols are what they are. If you need to think of them with some metaphor,
try this (google cache because it seems that the site is down):

http://72.14.209.104/search?q=cache%3An1xKIHxuk6UJ%3Ahttp%3A%2F%2Fwww.randomhacks.net%2Farticles%2F2007%2F01%2F20%2F13-ways-of-looking-at-a-r...

> Bharat
--Greg

Bharat Ruparel

3/7/2007 8:45:00 PM

0

Nice. Thanks.

--
Posted via http://www.ruby-....

Robert Dober

3/7/2007 11:05:00 PM

0

On 3/7/07, Gregory Seidman <gsslist+ruby@anthropohedron.net> wrote:
> On Thu, Mar 08, 2007 at 04:21:10AM +0900, Bharat Ruparel wrote:
> > I think of symbols is immutable strings that are useful only in
> > referring to some values? Seems like a nice way for using pointers
> > without all the warps?
>
> Symbols are what they are. If you need to think of them with some metaphor,
> try this (google cache because it seems that the site is down):
>
> http://72.14.209.104/search?q=cache%3An1xKIHxuk6UJ%3Ahttp%3A%2F%2Fwww.randomhacks.net%2Farticles%2F2007%2F01%2F20%2F13-ways-of-looking-at-a-r...
>
> > Bharat
> --Greg
>
>
>
Nice indeed but for a simple mind as mine #3 just works well!

--
We have not succeeded in answering all of our questions.
In fact, in some ways, we are more confused than ever.
But we feel we are confused on a higher level and about more important things.
-Anonymous

Chad Perrin

3/8/2007 5:42:00 AM

0

On Thu, Mar 08, 2007 at 02:17:13AM +0900, Rick DeNatale wrote:
> On 3/6/07, Luciano Ramalho <ramalho@gmail.com> wrote:
> >Paul Graham offers this excellent explanation for the symbol type:
> >
> >"Symbols are effectively pointers to strings stored in a hash table.
> >So you can test equality by comparing a pointer, instead of comparing
> >each character." [1]
> >
> >Of course, he's talking about symbols in Lisp, but what he says
> >applies equally well to Ruby and Smalltalk.
>
> I find this a little too implementation-centric a description.

Unfortunately, there's no way to differentiate a string literal from a
symbol in a definitive manner without brushing up against
implementation. At least, I haven't seen such a thing yet.


>
> The key aspect of symbols is that two symbols are identical if they are
> equal.
> The fact that there may (or may not be) a hash table used to ensure
> this is irelevant.

Ahh . . . but think about how they're "equal". They're equal because of
the manner in which they're implemented. If you want to separate the
concept of symbols from the implementation to some degree, you might
explain as little of implementation as possible while still getting the
point across, then say that "this could change so that symbols still
behave the same way but are implemented somewhat differently, but this
is how it's done right now".

How exactly, other than the difference between : and '', do you
differentiate a string literal from a symbol without discussing
implementation? I don't much see a way to do it.

Obviously, a symbol is different in easily explained ways from string
variables, without having to drag implementation into it. Things aren't
quite so clear-cut between symbols and string *literals*, though.


>
> Not long ago Matz experimented with the idea of making Symbol a
> subclass of String in 1.9, but this appears to have been dropped in
> more recent versions.

That's interesting -- I didn't know that. Thanks for mentioning it.

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky

Chad Perrin

3/8/2007 5:47:00 AM

0

On Thu, Mar 08, 2007 at 04:21:10AM +0900, Bharat Ruparel wrote:
> I think of symbols is immutable strings that are useful only in
> referring to some values? Seems like a nice way for using pointers
> without all the warps?

"Immutable strings" doesn't work so well, since a string literal is
"immutable" anyway. You might differentiate by mentioning that the
string is fleeting and the symbol persistent, perhaps. A string literal
only exists as long as the interpreter is evaluating -- whether for
assignment, for printing to standard out, or whatever else it may be
doing with it. You might also differentiate by pointing out that string
literals are not necessarily unique, while symbols are -- duplicate
string literals may be stored in several different variables at once.
In fact, several copies of a given string literal might all be stored in
the same array. A symbol, meanwhile, is unique -- and everything that
looks like a copy is actually making reference to the same thing under
the hood.

This is where you start getting into implementation, though, which some
Rubyists consider verboten as a means of defining symbols when
discussing it within the context of the language.

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
Amazon.com interview candidate: "When C++ is your
hammer, everything starts to look like your thumb."

Gary Wright

3/8/2007 5:49:00 AM

0


On Mar 8, 2007, at 12:41 AM, Chad Perrin wrote:
> Obviously, a symbol is different in easily explained ways from string
> variables, without having to drag implementation into it. Things
> aren't
> quite so clear-cut between symbols and string *literals*, though.

I'm not sure that the problem you are describing has anything to do with
symbols. Anyone learning Ruby is going to have to understand the
difference between "1", 1, 1.0, /1/, and :1. Symbol literals
aren't really special in this regard.

Gary Wright

Gary Wright

3/8/2007 5:56:00 AM

0


On Mar 8, 2007, at 12:46 AM, Chad Perrin wrote:
> You might also differentiate by pointing out that string
> literals are not necessarily unique, while symbols are -- duplicate
> string literals may be stored in several different variables at once.

This doesn't sound right to me. String literals are part of the
source code. They aren't stored in variables at all (let's just
agree to ignore eval for the moment).

And a single symbol can be represented by several different literals:

:alpha, :'alpha', :"alpha"

So you have to be careful about talking about unique literals.

Gary Wright

Brian Candler

3/8/2007 7:02:00 AM

0

On Thu, Mar 08, 2007 at 02:46:43PM +0900, Chad Perrin wrote:
> On Thu, Mar 08, 2007 at 04:21:10AM +0900, Bharat Ruparel wrote:
> > I think of symbols is immutable strings that are useful only in
> > referring to some values? Seems like a nice way for using pointers
> > without all the warps?
>
> "Immutable strings" doesn't work so well, since a string literal is
> "immutable" anyway.

Well maybe that's technically right, in the sense that the source code
itself is immutable. However, every time a string literal is 'executed' a
new, mutable string object is instantiated:

5.times { puts "hello".object_id }

So there's no way in practice to make use of the 'immutable' property you
describe, because every String object your program sees is mutable.

5.times {
a = "hello"
a << "!" # changed it
}

Here's where I'd say a symbol is different:

5.times {
a = :hello
puts a.object_id # same every time round
a << "!" # fails (symbol has no mutating methods)
}

Regards,

Brian.