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
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.
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.
--
Rick DeNatale
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-forum.com/.
>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.
On Thu, Mar 08, 2007 at 02:17:13AM +0900, Rick DeNatale wrote:
On 3/6/07, Luciano Ramalho <ramalho@gmail.com> wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky
> 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 inLisp, 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 asLispis
concerned.Lispsymbols aren't strings, they are really names to which
three (separate) things can be bound, a value (which can be anyLisp
object), a function, and a property list. Actually the name is also
one of the slots in a symbol.
Actually it's five in Common Lisp: Value, Function, Name, Property
List, Package.
Note that inLispthe 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.
No, that's wrong. Two different symbols can have the same name in
Common Lisp.
CL-USER 30 > (eq '#:foo '#:foo)
NIL
CL-USER 31 > (symbolp '#:foo)
T
CL-USER 32 > (symbol-name '#:foo)
"FOO"
So inLispa symbol is more like an entry in the table of global names.
No. In Lisp a symbol is a data structure with above five (virtual)
slots.
Symbols can exist without a 'table of names'. These 'table of names'
are called packages. A symbol can belong to a package. You can then
lookup the symbol via the package by its name. Again a symbol
can exist without being interned in a package.
Symbols in Ruby and Smalltalk are more alike than Symbols inLisp.
Smalltalk and Ruby symbols have unique 'values' which are also their 'names'.
These are a bit keyword symbols in Lisp. All symbols that belong to
the keyword package
have themselves as the value.
CL-USER 30 > (eq '#:foo '#:foo)
NIL
CL-USER 31 > (symbolp '#:foo)
T
CL-USER 32 > (symbol-name '#:foo)
"FOO"
CL-USER 33 > :foo
:FOO
CL-USER 34 > (symbol-package :foo)
#<The KEYWORD package, 0/4 internal, 9284/32768 external>
CL-USER 35 > (eq :foo (symbol-value :foo))
T
CL-USER 36 > (describe ':foo)
:FOO is a SYMBOL
NAME "FOO"
VALUE :FOO
FUNCTION #<unbound function>
PLIST NIL
PACKAGE #<The KEYWORD package, 0/4 internal, 9284/32768
On Mar 7, 6:17 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
On 3/6/07, Luciano Ramalho <rama...@gmail.com> wrote:
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
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):
Bharat
--Greg
On Thu, Mar 08, 2007 at 04:21:10AM +0900, Bharat Ruparel wrote:
"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.
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?
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Amazon.com interview candidate: "When C++ is your
hammer, everything starts to look like your thumb."
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
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.
> >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.
lets see
def is_symbol?(arg)
arg.object_id == arg.to_sym.object_id rescue false
end
On 3/8/07, Chad Perrin <perrin@apotheon.com> wrote:
On Thu, Mar 08, 2007 at 02:17:13AM +0900, Rick DeNatale wrote:
> On 3/6/07, Luciano Ramalho <ramalho@gmail.com> wrote:>
> 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.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/
Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/
>
> > 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 inLisp, 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 asLispis
> concerned.Lispsymbols aren't strings, they are really names to which
> three (separate) things can be bound, a value (which can be anyLisp
> object), a function, and a property list. Actually the name is also
> one of the slots in a symbol.Actually it's five in Common Lisp: Value, Function, Name, Property
List, Package.> Note that inLispthe 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.No, that's wrong. Two different symbols can have the same name in
Common Lisp.CL-USER 30 > (eq '#:foo '#:foo)
NILCL-USER 31 > (symbolp '#:foo)
TCL-USER 32 > (symbol-name '#:foo)
"FOO">
> So inLispa symbol is more like an entry in the table of global names.No. In Lisp a symbol is a data structure with above five (virtual)
slots.
Symbols can exist without a 'table of names'. These 'table of names'
are called packages. A symbol can belong to a package. You can then
lookup the symbol via the package by its name. Again a symbol
can exist without being interned in a package
Well, I never claimed to be a Lisp expert, the last time I used Lisp
seriously it was Lisp 1.5.
On the other hand, the author of the originally referenced
'explanation of symbols' seemed to be basing his description on his
knowledge of Lisp.
Given all the other differences pointed out by joswig, I think that my
original contention that:
> Symbols in Ruby and Smalltalk are more alike than Symbols inLisp.
seems to be more true than ever.
On 3/8/07, joswig@corporate-world.lisp.de <joswig@corporate-world.lisp.de> wrote:
On Mar 7, 6:17 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
> On 3/6/07, Luciano Ramalho <rama...@gmail.com> wrote:
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Nice. Thanks.
--
Posted via http://www.ruby-forum.com/.
Nice indeed but for a simple mind as mine #3 just works well!
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):> Bharat
--Greg
--
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
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
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.
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.
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.
Umm . . . I don't see how any of that has anything to do with whether or
not some reference to implementation details is necessary for a
meaningful explanation of the difference between :bob and "bob".
On Thu, Mar 08, 2007 at 02:48:48PM +0900, Gary Wright wrote:
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.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
Hi --
On 3/8/07, Gary Wright <gwtmp01@mac.com> wrote:
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.
I'll add yet another way of thinking about symbols, namely that they
are very integer-like. All of the immutable, unique, immediate-value
stuff is not so much a modification of how strings behave as a rather
exact replication of how integers behave.
David
--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
I think that this is an awful article (and said as such in the
comments). There are much better descriptions of symbols out there
that don't impute magic to symbol objects.
-austin
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):
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
With an itchy trigger finger.
> > >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.lets see
def is_symbol?(arg)
arg.object_id == arg.to_sym.object_id rescue false
end
is_symbol?(:a) => true
is_symbol?("a") => false
is_symbol?([:a, :b]) => false
>
> >
> > 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".
Or you can turn this around and say that the equality-identity
relationship is what's essential and that one way of implementing this
requirement is to intern using a hash table.
> 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.
The same way you can describe the properties of other objects without
regard to implementation. For example we can understand how integers
work without having to going into the details of how they are
represented.
> 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 I get your distinction between string variables and
string literals. It's really a matter of the differences between
string OBJECTs and symbol OBJECTs.
On 3/8/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
On 3/8/07, Chad Perrin <perrin@apotheon.com> wrote:
> On Thu, Mar 08, 2007 at 02:17:13AM +0900, Rick DeNatale wrote:
> > On 3/6/07, Luciano Ramalho <ramalho@gmail.com> wrote:
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
. . . which brushes up against implementation.
On Fri, Mar 09, 2007 at 06:11:43AM +0900, Rick DeNatale wrote:
On 3/8/07, Chad Perrin <perrin@apotheon.com> wrote:
>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.lets see
def is_symbol?(arg)
arg.object_id == arg.to_sym.object_id rescue false
end
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid
> > > 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 inLisp, 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 asLispis
> > concerned.Lispsymbols aren't strings, they are really names to which
> > three (separate) things can be bound, a value (which can be anyLisp
> > object), a function, and a property list. Actually the name is also
> > one of the slots in a symbol.> Actually it's five in Common Lisp: Value, Function, Name, Property
> List, Package.> > Note that inLispthe 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.> No, that's wrong. Two different symbols can have the same name in
> Common Lisp.> CL-USER 30 > (eq '#:foo '#:foo)
> NIL> CL-USER 31 > (symbolp '#:foo)
> T> CL-USER 32 > (symbol-name '#:foo)
> "FOO"> > So inLispa symbol is more like an entry in the table of global names.
> No. In Lisp a symbol is a data structure with above five (virtual)
> slots.
> Symbols can exist without a 'table of names'. These 'table of names'
> are called packages. A symbol can belong to a package. You can then
> lookup the symbol via the package by its name. Again a symbol
> can exist without being interned in a packageWell, I never claimed to be a Lisp expert, the last time I used Lisp
seriously it was Lisp 1.5.
Lisp 1.5 is not really in use anymore.
On the other hand, the author of the originally referenced
'explanation of symbols' seemed to be basing his description on his
knowledge of Lisp.Given all the other differences pointed out byjoswig, I think that my
original contention that:> > Symbols in Ruby and Smalltalk are more alike than Symbols inLisp.
seems to be more true than ever.
Symbols in Ruby and Smalltalk are like keyword symbols in Common Lisp.
Keyword symbols are symbols in the package KEYWORD and they
have themselves as value and they are unique.
On Mar 9, 3:13 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
On 3/8/07, jos...@corporate-world.lisp.de > > > > <jos...@corporate-world.lisp.de> wrote:
> On Mar 7, 6:17 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
> > On 3/6/07, Luciano Ramalho <rama...@gmail.com> wrote:
--
Rick DeNataleMy blog on Rubyhttp://talklikeaduck.denhaven2.com/