Oh, so many replies to my poor question! What a wonderful community!
[email protected] wrote:
also, don’t forget that symbols are never freed.
this is a severe memory leak:loop{ Time::now.to_f.to_s.intern }
I still wonder if the lack of garbage collection of symbols
is merely a weakness in the current implementation, or something
that’s part of the Ruby language.
Note that most lisps and javas can garbage collect
symbols and interned strings.
If it’s just an implementation misfeature I’d love to
see that limitation go away in YARV.
Notes:
*1 http://community.schemewiki.org/?scheme-faq-language “Most Schemes
do perform garbage-collection of symbols, since otherwise programs
using string->symbol to dynamically create symbols would consume
ever increasing amounts of memory even if the created symbols are
no longer being used.”
*2 http://mindprod.com/jgloss/interned.html “In the early JDKs, any
string you interned could never be garbage collected because the
JVM had to keep a reference to in its Hashtable so it could
check each incoming string to see if it already had it in the
pool. With JDK 1.2 came weak references. Now unused interned
strings will be garbage collected.”
Eero S. [email protected] writes:
the only difference performance?
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.
To paraphrase fifteen thousand fourty-three mediocre
comedians over the last three centuries:“A Symbol is like a word, a sentence, a phrase, a
description or, perhaps, a name. Except sometimes.”
On Thursday 29 December 2005 03:03 am, Surgeon wrote:
Oh, so many replies to my poor question! What a wonderful community!
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
symbols are an exception.
Tell you the truth, I still don’t understand, but at least now I have
some
theorys thanks to the thread you started. Thank you for that.
SteveT
Steve L.
Hi –
On Thu, 29 Dec 2005, Steve L. wrote:
On Thursday 29 December 2005 03:03 am, Surgeon wrote:
Oh, so many replies to my poor question! What a wonderful community!
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
[email protected]
“Ruby for Rails”, from Manning Publications, coming April 2006!
On Thursday 29 December 2005 10:16 am, [email protected] wrote:
s/RUBY/Ruby/
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 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.
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.
From what I understand, symbols are used for things other than naming
objects/variables. In such cases, it would be less surprising if they
had a
different syntax than the ones that name objects.
A little surprise is OK. The subtle differnces of do/end and {/} in
blocks is
a little surprise. But in my opinion, symbols and their uses is a
blizzard on
the equator type surprise.
The fact that symbols cause so much more confusion than most other Ruby
facilities is an indicator. AFAIK there has been no good documentation
on
symbols. When I mean good, I mean like the thoughts that have gone into
this
thread – thoughts valuable to the person who doesn’t yet know symbols
by
instinct, at which time the documentation is moot anyway.
SteveT
Steve L.
On Dec 29, 2005, at 9:45 AM, Steve L. wrote:
symbol.
You are still confused.
Symbols are nothing like references. They would be much closer to
enums, if you want a C-ish comparison.
James Edward G. II
On Thursday 29 December 2005 8:45 am, Steve L. wrote:
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 H.
On 29/12/05, Steve L. [email protected] wrote:
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.
When I do the following:
attr_accessor :foo
I am not referencing anything. I am naming something. There is no
analogue between a Ruby Symbol and a C/C++ reference or pointer.
Symbols name things, and they are important enough that they are
intrinsic types just like Strings, Arrays, Hashes, and Integers. What
makes Symbols “special” in the current implementation is that a Symbol
is created for every named item.
olds = Symbol.all_symbols; nil
nil
quuxl = 0
0
Symbol.all_symbols - olds
[: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
On Thu, Dec 29, 2005 at 11:37:59PM +0900, Yohanes S. wrote:
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.
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
“Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts.” - Paul Graham
Hi –
On Fri, 30 Dec 2005, Steve L. wrote:
On Thursday 29 December 2005 10:16 am, [email protected] wrote:
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 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.
From what I understand, symbols are used for things other than naming
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.method(:sym)).
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
[email protected]
“Ruby for Rails”, from Manning Publications, coming April 2006!
On Dec 29, 2005, at 12:22 AM, Jim W. wrote:
ara wrote:
but this slightly modified version shows strings being a tiny bit
faster: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
On Fri, Dec 30, 2005 at 01:50:14AM +0900, Chad P. wrote:
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).
On Thursday 29 December 2005 11:20 am, Kirk H. wrote:
On Thursday 29 December 2005 8:45 am, Steve L. wrote:
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.
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 L.
On Thursday 29 December 2005 11:30 am, Austin Z. wrote:
On 29/12/05, Steve L. [email protected] wrote:
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.
Thanks Austin,
I think that article brought me closer to understanding. Armed with
your
article and all the other responses, I replied to Kirk H.’ 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 L.
On 12/29/05, Austin Z. [email protected] wrote:
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
On Fri, Dec 30, 2005 at 02:09:40AM +0900, Edward F. wrote:
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.
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
print substr(“Just another Perl hacker”, 0, -2);
On Dec 29, 2005, at 11:08 AM, Steve L. wrote:
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.
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 G. II
On 29/12/05, Steve L. [email protected] wrote:
: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=) that coincidentally
work on a variable of the same name. It doesn’t create that variable.
my_object.wilbur = 22
puts my_object.wilburSo 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
On Thursday 29 December 2005 10:08 am, Steve L. wrote:
OK, let me see if I’m correctly understanding you.
Yep!
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 H.