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

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
73803e9b62fe9b6499db6a7ca87c909c?d=identicon&s=25 Surgeon (Guest)
on 2005-12-28 20:28
(Received via mailing list)
Hi,

I am a Ruby newbie. I wish I didn't post such a simple question here
but I had to.
What is the difference between :foo (a keyword) and "foo"(a string).
Can they be used interchangeably? Are they fundamentally same and is
the only difference performance?

Thanks in advance
Cca8fe64fab32e8872a8afaab2f6f7d8?d=identicon&s=25 Alex Knaub (Guest)
on 2005-12-28 20:34
(Received via mailing list)
2005/12/28, Surgeon <biyokuantum@gmail.com>:
> Hi,
>
> I am a Ruby newbie. I wish I didn't post such a simple question here
> but I had to.
> What is the difference between :foo (a keyword) and "foo"(a string).
> Can they be used interchangeably? Are they fundamentally same and is
> the only difference performance?

http://onestepback.org/index.cgi/Tech/Ruby/Symbols...
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-28 20:50
(Received via mailing list)
On Wednesday 28 December 2005 02:32 pm, Alex Knaub wrote:
>d
The preceding URL tells me unequivically that symbols aren't strings,
but
really doesn't tell me too much about what they are, other than what,
names???

I still don't understand why it's

attr_reader :fname, :lname

instead of

attr_reader @fname, @lname

How does attr_reader know that :fname corresponds to @fname. Seems like
magic
to me.

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-28 21:02
(Received via mailing list)
On Dec 28, 2005, at 1:47 PM, Steve Litt wrote:

>> http://onestepback.org/index.cgi/Tech/Ruby/
>> SymbolsAreNotImmutableStrings.re
>> d
>
> The preceding URL tells me unequivically that symbols aren't
> strings, but
> really doesn't tell me too much about what they are, other than what,
> names???

As one of the people guilty of saying what that article says we
shouldn't, I better try to get back in Jim's good graces by answering
this one...  ;)

> to me.
Attributes of a class logically correspond to instance variables in
many cases, don't you think?  Ruby's just making that assumption for
you.

When I see:

   some_call @my_variable

I expect what is held inside of @my_variable to get passed to
some_call(), not the variable name itself.  What you describe would
be the opposite and that would surely surprise a lot of people.

Furthermore, Symbols are commonly used to refer to method names (as
Ruby uses them for this internally).  That's really what we are doing
here, creating new methods by name, so it's a good fit.

Hope that makes some sense.

James Edward Gray II
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 Ross Bamford (Guest)
on 2005-12-28 21:23
(Received via mailing list)
On Wed, 28 Dec 2005 19:47:16 -0000, Steve Litt <slitt@earthlink.net>
wrote:

>> http://onestepback.org/index.cgi/Tech/Ruby/Symbols...
>> d
>
> The preceding URL tells me unequivically that symbols aren't strings, but
> really doesn't tell me too much about what they are, other than what,
> names???
>

I agree with Jim (obviously ;)) that describing symbols as immutable
strings isn't ideal, but it did help me break away from the idea that
they
worked on some kind of internal voodoo. An object with a name seems a
good
way to put it - maybe 'an object that is a name, by which it can be
referenced anywhere'.

So :foo is just the name, 'foo', as an object. A singleton object. Kind
of
like the literal '4' - wherever you use that literal, you'll get the
same
instance of Fixnum (incidentally, with object_id 9), whether you mean
four
loops, or four bananas, since four is four the same one will do.

> to me.
>

You're looking at it backwards. You give attr_reader a name (or
several).
It then takes those names, and just creates methods with each one.
There's
no connection between the symbols, and the methods - it's just like
passing in a string (which you can actually do instead) except that,
instead of creating a new string with the characters 'lname' or
whatever,
it just grabs the single symbol with that name, or makes it if it
doesn't
already exist. It saves memory, and is better on performance in many
types
of system. The reader method accesses an instance variable, again named
 from the symbol, and it gets created automatically at startup.

So the symbol just gives you the name - it's up to you to supply the
context (like 'an attribute reader with this name' above).
B000982a23d5c6a34292902caf225dd7?d=identicon&s=25 Yohanes Santoso (Guest)
on 2005-12-28 21:26
(Received via mailing list)
Alex Knaub <aknaub@gmail.com> writes:

> 2005/12/28, Surgeon <biyokuantum@gmail.com>:
>> Hi,
>>
>> I am a Ruby newbie. I wish I didn't post such a simple question here
>> but I had to.
>> What is the difference between :foo (a keyword) and "foo"(a string).
>> Can they be used interchangeably? Are they fundamentally same and is
>> the only difference performance?
>
> http://onestepback.org/index.cgi/Tech/Ruby/Symbols...

What a coincidence. Seems like Jim and I finally had enough of people
conflating symbols and immutable strings on the same day.

http://microjet.ath.cx/WebWiki/2005.12.27_UsingSym...

YS.
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2005-12-28 21:29
(Received via mailing list)
From: "Steve Litt" <slitt@earthlink.net>
> to me.
If this helps, attr_reader itself isn't magic or special Ruby syntax,
it's just a method that defines helper-methods for you, using whatever
names you provide it.  The symbols :fname, :lname above are just
interpreted by attr_reader as names of methods we are asking it to
define, and names of corresponding instance variables we want it to
access.  (Note that: attr_reader "fname", "lname" also works - it's
less convenient to type than the symbol equivalents.)

I think there are more elegant ways to do this, but here's one way we
could define our own attr_reader:

def my_attr_reader(*list_of_attr_names)
  list_of_attr_names.each do |name|
    eval <<-ENDFUNC
      def #{name}
        @#{name}
      end
    ENDFUNC
  end
end

class Foo
  my_attr_reader :foo, :bar
  def initialize
    @foo = 123
    @bar = 456
  end
end

f = Foo.new
puts f.foo, f.bar

# the above program outputs:
123
456


So you can see my_attr_reader is just taking a list of "names",
which we conveniently specify as symbols (but we could also
specify as strings, if we wanted.)  Then my_attr_reader just
proceeds to use eval to define methods with the requested name,
accessing the corresponding instance variable.  (Again, there
are probably more elegant ways to do this than using eval; it's
just one way.)


Hope this helps,

Regards,

Bill
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 Ross Bamford (Guest)
on 2005-12-28 21:29
(Received via mailing list)
On Wed, 28 Dec 2005 20:00:13 -0000, James Edward Gray II
<james@grayproductions.net> wrote:

>> really doesn't tell me too much about what they are, other than what,
>> names???
>
> As one of the people guilty of saying what that article says we
> shouldn't, I better try to get back in Jim's good graces by answering
> this one...  ;)
>

I still think it's a useful description, at least for those of us coming
 from Java. In fact it was reading one of your 'priors' that set me on
the
road to understanding a bit more - I couldn't get away from the internal
connotations of the word 'Symbol' until I read that.

I still really think of symbols as an immutable _representation of_ a
string. Although it's not entirely accurate it suits me I think. I am
liking the Object with name thing the more I think about it. Or 'a name
referenced by name'. Or whatever. :)
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-28 21:38
(Received via mailing list)
On Wednesday 28 December 2005 03:00 pm, James Edward Gray II wrote:
> >>
> shouldn't, I better try to get back in Jim's good graces by answering
> > How does attr_reader know that :fname corresponds to @fname. Seems
>
> I expect what is held inside of @my_variable to get passed to
> some_call(), not the variable name itself.

Oh, I get it!!!

In see itwould be some_call(&@my_variable), and in ruby it's
some_call(:my_variable). One thing -- why not some_call(:@my_variable)?


> What you describe would
> be the opposite and that would surely surprise a lot of people.
>
> Furthermore, Symbols are commonly used to refer to method names (as
> Ruby uses them for this internally).  That's really what we are doing
> here, creating new methods by name, so it's a good fit.

Ah ha! That's why I need to pass callback routines entry and exit that
occur
in object cb, like this:

walker = Walker.new(node, cb.method(:entry), cb.method(:exit))

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-28 21:50
(Received via mailing list)
On Dec 28, 2005, at 2:35 PM, Steve Litt wrote:

> One thing -- why not some_call(:@my_variable)?

This is a fair question I've asked myself once or twice.  Ruby seems
to change it's mind on this sometimes too:

 >> class MyClass
 >>   def initialize( var )
 >>     @var = var
 >>   end
 >>   attr_reader :var  # I guess we're talking about the method here
(no @)
 >>   def fetch( name )
 >>     instance_variable_get("@#{name}") # but we need the @ now
 >>   end
 >> end
=> nil
 >> ex = MyClass.new(123)
=> #<MyClass:0x32565c @var=123>
 >> ex.var
=> 123
 >> ex.fetch(:var)
=> 123

James Edward Gray II
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-28 21:53
(Received via mailing list)
attr_reader :fname, :lname (attr_reader "fname", "lname" works too)
knows how to map the names because that's what an attribute is: A
read-only attribute 'foo' will have a getter method named 'foo' and an
instance variable '@foo'. It's a common enough convention, used in
other languages as well. (In Java, it would be a method 'getFoo()' and
an instance variable 'foo'.)

The difference between symbols and strings:

A string is a sequence of characters. You can append to a string,
parse it, split it, iterate over characters or lines and so forth. Two
strings containing the same character sequence (say "abc" and "abc")
are equal, but not necessarily the same object.
Strings can be basically any character or byte sequence, like the
contents of a text or binary file. Strings are local and are garbage
collected when they are no longer referred to, like other objects.

A symbol is atomic, immutable and unique: It cannot be parsed or
modified, and all references to a symbol with a given name (say :abc)
refers to the same object.
Symbols tend to be short, simple names, like a single word with no
whitespace. Symbols are global, and hang around quite a bit longer
than strings normally do, often until the end of the program.

Symbols are (or can be) quicker for hash lookup, since it is
sufficient to compare object identity to find whether two symbols are
the same, while strings must be compared character by character. You
are unlikely to notice the difference unless your program uses hashes
heavily.

So they are not fundamentally the same. But there are a some cases
where they can be used interchangeably, like naming an attribute or as
hash key.

Reasons for using symbols instead of strings are mostly based on
convention. Personally, I  use them basically because I save a
keystroke in typing them :)

Does this make it any clearer?

johannes
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-28 21:53
(Received via mailing list)
On 28/12/05, Steve Litt <slitt@earthlink.net> wrote:
> Oh, I get it!!!
> In see itwould be some_call(&@my_variable), and in ruby it's
> some_call(:my_variable). One thing -- why not some_call(:@my_variable)?

No.

There is nothing even remotely close in C, C++, or Java.

In Ruby, it's *not* some_call(:my_variable), it's some_call(:my_name).



When you do:

   attr_accessor :my_name

You do NOT get a @my_name variable. You get two methods: Foo#my_name
and Foo#my_name= -- that's it. Consider:

>> class Foo
>>   attr_accessor :bar
>> end
=> nil
>> baz = Foo.new
=> #<Foo:0x2d8aea8>

Note. Thus far, there's no instance variable @bar on the Foo instance
baz.

>> Foo.instance_methods(false)
=> ["bar", "bar="]

There's our instance methods.

>> baz.bar = 32
=> 32
>> baz
=> #<Foo:0x2d8aea8 @bar=32>

Now that we've called Foo#bar= on the baz instance of Foo class, baz
finally has a @bar instance variable. But not a moment before, unless
we instantiate such an instance variable prior to the call of
Foo#bar=.

So :bar is a name (Symbol) used to refer to the name :bar. It is used
by attr_accessor to create two methods that also operate on a
like-named instance variable. But :bar doesn't refer to a variable,
which is precisely why it isn't :@bar -- you're not creating a
variable @bar, you're creating instance methods #bar and #bar= that
happen to work on @bar in the instance.

-austin
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-28 21:59
(Received via mailing list)
On Dec 28, 2005, at 2:51 PM, Austin Ziegler wrote:

> => nil
>
>>> baz.bar = 32
> => 32
>>> baz
> => #<Foo:0x2d8aea8 @bar=32>
>
> Now that we've called Foo#bar= on the baz instance of Foo class, baz
> finally has a @bar instance variable. But not a moment before, unless
> we instantiate such an instance variable prior to the call of
> Foo#bar=.

That's what I suspected as shown in the comments of my last example,
but Austin explains it much better.  Learn something new all the
time...  :)

James Edward Gray II
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-28 22:14
(Received via mailing list)
Depends on the call.
In the case of attr_*, it's because you're naming the attribute, not
the methods or the variable. The convention (and the code behind
attr_*) will do the expansion.
In instance_variable_get(...), you are explicitly looking for a
variable, and naturally supply the variable name.
In both cases, the symbol is just a name. What we are naming depends
on the context.

jf
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-28 22:17
(Received via mailing list)
On Thu, 29 Dec 2005, Johannes Friestad wrote:


> Symbols are (or can be) quicker for hash lookup, since it is sufficient to
> compare object identity to find whether two symbols are the same, while
> strings must be compared character by character. You are unlikely to notice
> the difference unless your program uses hashes heavily.

i see this claim all the time but never data supporting it, all my test
programs have shown the opposite to be true.  see

   http://groups.google.com/group/comp.lang.ruby/brow...

for some sample code.

running that sample code with the latest ruby (1.8.4) shows the gap has
narrowed, but strings are still beating symbols on my box:

   ---
    - Symbol:
       max: "0.0019838809967041"
       avg: "0.0000033428150346"
       min: "0.0000019073486328"
   - String:
       max: "0.0019280910491943"
       avg: "0.0000037288846215"
       min: "0.0000019073486328"



also, don't forget that symbols are __never__ freed.


this is a severe memory leak:

   loop{ Time::now.to_f.to_s.intern }

this is not

   loop{ Time::now.to_f.to_s }


strings certainly play nicer with yaml as well.

regards.

-a
--
===============================================================================
| ara [dot] t [dot] howard [at] noaa [dot] gov
| all happiness comes from the desire for others to be happy.  all misery
| comes from the desire for oneself to be happy.
| -- bodhicaryavatara
===============================================================================


















a.rb
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-28 22:38
(Received via mailing list)
That's where the 'can be' part comes in :)
The point is that symbols support quicker lookup by their nature.
Whether they are quicker in practice will depend on the
implementation. From the timings you give, it looks like symbol lookup
is implemented by converting the symbol to a string and doing string
lookup. Which is obviously not quicker :)

My data were from a Common Lisp implementation, where symbols were
quicker in practice as well.
Sorry, didn't know about the Ruby implementation. Thanks for the info.


jf
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2005-12-28 22:44
(Received via mailing list)
Yohanes Santoso wrote:
>>>Can they be used interchangeably? Are they fundamentally same and is
>>>the only difference performance?
>>
>>http://onestepback.org/index.cgi/Tech/Ruby/Symbols...
>
>
> What a coincidence. Seems like Jim and I finally had enough of people
> conflating symbols and immutable strings on the same day.
>
> http://microjet.ath.cx/WebWiki/2005.12.27_UsingSym...


Question: Would using a constant be equally suitable for expressing
intention, and (possibly) less error-prone?

# Assume ConstUtils.next_value
# ensures unique values
HOST = ConstUtils.next_value
PORT = ConstUtils.next_value

foo1 = {
    HOST => 'localhost',
    PORT => 80
}

A downside to using symbols as constants is that this will not raise any
exceptions:


foo1 = {
    :hots => 'localhost',
    :prt => 80
}

But a typo in a constant will.


James
--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-28 22:54
(Received via mailing list)
On Thu, 29 Dec 2005, Johannes Friestad wrote:

> That's where the 'can be' part comes in :)
> The point is that symbols support quicker lookup by their nature.
> Whether they are quicker in practice will depend on the
> implementation. From the timings you give, it looks like symbol lookup
> is implemented by converting the symbol to a string and doing string
> lookup. Which is obviously not quicker :)

i never consider that as an impl - i bet your right though... time for
me to
read the source.

cheers.

-a
A9c4658e9e475e13d790ae419acf01b6?d=identicon&s=25 =?ISO-8859-1?Q?Simon_Kr=F6ger?= (Guest)
on 2005-12-28 22:57
(Received via mailing list)
I'm all with you, you may even use

HOST = :host
PORT = :port

instead of ConstUtils.next_value, but anybody else will tell you
to use modul tests to find your errors instead of letting the
interpreter find them.

(Agreed, sharp knifes are better than dull ones, but even if all
you need is a spoon?)

cheers

Simon
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-28 23:03
(Received via mailing list)
> Question: Would using a constant be equally suitable for expressing
> intention, and (possibly) less error-prone?

I agree. But there's no law against using both:

HOST = :host
PORT = :port
foo1 = {
    HOST => 'localhost',
    PORT => 80
}

which is equally safe, simpler to read, doesn't need the ConstUtil,
and automagically gives a constant with a readable string value.

jf
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2005-12-28 23:12
ara wrote:
> i see this claim all the time but never data supporting it, all my test
> programs have shown the opposite to be true.

My benchmark shows symbols to have a slight edge.  I've attached my
benchmark at the end for review. (Benchmarks are tricky ... sometimes
you don't measure what you think you are measuring).

    $ ruby string_symbol_time.rb
    Strings Filling
     14.080000   0.090000  14.170000 ( 14.406058)
    Strings Fetching
      4.320000   0.030000   4.350000 (  4.355025)

    Symbols Filling
     12.300000   0.030000  12.330000 ( 12.561648)
    Symbols Fetching
      3.370000   0.030000   3.400000 (  3.461109)

> also, don't forget that symbols are __never__ freed.

True, but when used properly, this is rarely a concern.  If they are
used as programmer names for things, then the number of symbols is
finite and not likely to grow and consume memory as the program runs.

If however, you are dynamically creating symbols by interning strings, I
would suggest you review your use of symbols and consider using strings
instead.

--
-- Jim Weirich

-------------------------------------------------------------------
#!/usr/bin/env ruby

require 'benchmark'

SIZE = 100
N = 10000

def make_str_keys
  (1..SIZE).collect { |i| "key#{i}" }
end

def make_sym_keys(strs)
  strs.collect { |s| s.intern }
end

def populate(keys)
  result = {}
  keys.each_with_index do |k, i|
    result[k] = i
  end
  result
end

def fetch(keys, hash)
  keys.each do |key| hash[key] end
end

strs = make_str_keys
syms = make_sym_keys(strs)

str_hash = populate(strs)
sym_hash = populate(syms)

puts "Strings Filling"
puts Benchmark.measure {
  N.times do
    populate(strs)
  end
}

puts "Strings Fetching"
puts Benchmark.measure {
  N.times do
    fetch(strs, str_hash)
  end
}

puts
puts "Symbols Filling"
puts Benchmark.measure {
  N.times do
    populate(syms)
  end
}

puts "Symbols Fetching"
puts Benchmark.measure {
  N.times do
    fetch(syms, sym_hash)
  end
}
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2005-12-28 23:15
James Gray wrote:
> As one of the people guilty of saying what that article says we
> shouldn't, I better try to get back in Jim's good graces by answering
> this one...  ;)

James, you have never been out of my good graces (despite how you
describe symbols) :)

--
-- Jim Weirich
Ad97b577f331ae29ed90da5751f2e44f?d=identicon&s=25 Dan Diebolt (dandiebolt)
on 2005-12-28 23:21
(Received via mailing list)
How about devoting the next Ruby Quiz to coming up with the
best-of-class examples, self paced-tutorial and documentation to settle
the :symbol vs "string" issue? At some point you have to ask yourself
are the explanations given so far to inquiring users adequate. The fact
that this question keeps coming up must be seen as evidence that there
is something lacking in the explanations previously given. At a minimum
all the explanations give so far should be edited up into a FAQ entry
that the experts can agree upon. Just my two cents.
    6.1 What does :var mean?    A colon followed by a name generates an
integer(Fixnum) called a symbol which corresponds one to one with the
identifier. "var".intern gives the same integer as :var, but the ``:''
form will create a local symbol if it doesn't already exist.  The
routines "catch", "throw", "autoload", and so on, require a string or a
symbol as an argument. "method_missing", "method_added" and
"singleton_method_added" (and others) require a symbol.  The fact that a
symbol springs into existence the first time it is referenced is
sometimes used to assign unique values to constants:      NORTH = :NORTH
SOUTH = :SOUTH
EAST  = :EAST
WEST  = :WEST

  http://www.rubycentral.com/faq/rubyfaqall.html#s6
B000982a23d5c6a34292902caf225dd7?d=identicon&s=25 Yohanes Santoso (Guest)
on 2005-12-28 23:21
(Received via mailing list)
James Britt <james_b@neurogami.com> writes:

> Question: Would using a constant be equally suitable for expressing
> intention, and (possibly) less error-prone?

I would say that if your language does not provide a means for you to
define your own identifier, then it would be acceptable.

But this seems pointless in ruby.


> # Assume ConstUtils.next_value
> # ensures unique values
> HOST = ConstUtils.next_value
> PORT = ConstUtils.next_value

For discussion simplicity sake, I'd just assume next_value returning
integers.

>
> foo1 = {
>     HOST => 'localhost',
>     PORT => 80
> }

p foo1  ==> {32=>"localhost", 238=>80}

That makes debugging difficult. Since the value of HOST/PORT is
volatile (it could change depending on how next_value generates the
integers, and also if you, say, insert 'DOMAIN =
ConstUtils.next_value' between HOST and PORT assignments),
understanding past debugging outputs(e.g., in a log file) would be
harder as well.

> A downside to using symbols as constants is that this will not raise
> any exceptions:
>
>
> foo1 = {
>     :hots => 'localhost',
>     :prt => 80
> }

True, typos are such a hard error to prevent. Fortunately, there are
ways around that.


<example>
module ConfigIdentifiers
       [:host, :port].each{|x| const_set(x.to_s.upcase, x)}
end

include ConfigIdentifiers
foo1 = { HOST => 'localhost', PORT => 80}
</example>

is a solution.

But my experience as someone who has made many typos such as that (and
still is making them) is my test cases usually catch them and those
that manage to elude are easily identified (and corrected) manually.


YS.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-28 23:27
(Received via mailing list)
On Thu, 29 Dec 2005, Dan Diebolt wrote:


> NORTH = :NORTH
> SOUTH = :SOUTH
> EAST  = :EAST
> WEST  = :WEST


   %w( NORTH SOUTH EAST WEST ).each{|c| const_set c, c}

;-)


-a
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2005-12-28 23:30
Jim Weirich wrote:
>> also, don't forget that symbols are __never__ freed.
>
> True, but when used properly, this is rarely a concern.  If they are
> used as programmer names for things, then the number of symbols is
> finite and not likely to grow and consume memory as the program runs.

Here I am replying to my own posting, but I think this point could use
some elaboration.

Why are symbols not garbage collected?  Because a symbol represents a
mapping from a string name to a unique object.  Anytime in the execution
of the program, if that name is used for a symbol, the original symbol
object must be returned.  If the symbol is garbage collected, then a
later reference to the symbol name will return a different object.
That's generally frowned upon (although I don't really see the harm.  If
the original symbol was GC'ed, nobody cared what the original object was
anyways.  But that's the way it works).

This might be one area where the "Symbol isa immutable string" meme
might be doing some real harm.  We if think of symbols as strings, then
we tend to build symbols dynamically like we do strings.  This is when
the memory leak" problem of symbols becomes a problem.

Here's a rule of thumb ... if a programmer never sees the symbol name in
the code base, then you probably should be using a string rather than a
symbol.

I'm not sure if this helped, or just muddied the water more.

--
-- Jim Weirich
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2005-12-29 00:33
(Received via mailing list)
Johannes Friestad wrote:
...
>
My hack was a quicky to flesh out the example.  After sending it I
thought about assigning symbols.  My main point was that if one mistypes
a symbol name, Ruby doesn't care.  Unit tests should catch this, but
using constants might just help things along because of the immediate
error.    And it might more clearly express intent.


James

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-29 00:42
(Received via mailing list)
On Dec 28, 2005, at 3:22 PM, Ross Bamford wrote:
> On Wed, 28 Dec 2005 19:47:16 -0000, Steve Litt
> <slitt@earthlink.net> wrote:
>> The preceding URL tells me unequivically that symbols aren't
>> strings, but
>> really doesn't tell me too much about what they are, other than what,
>> names???
>
> An object with a name seems a good way to put it - maybe 'an object
> that is a name, by which it can be referenced anywhere'.

At the new_haven.rb December meeting, I gave a short presentation on
Symbols
versus Strings.  I described Symbols as:

	Named numbers, you pick the name, Ruby picks the number

The number that Ruby picks is effectively an index into an internal
table
with some bit shifting and masking to encode the index into a 32-bit
Ruby
reference value.

The internal table gets new entries when a symbol literal is parsed
or when String#to_sym is called.


Gary Wright
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2005-12-29 01:25
(Received via mailing list)
On Thu, Dec 29, 2005 at 07:30:44AM +0900, Jim Weirich wrote:
> Jim Weirich wrote:
> Why are symbols not garbage collected?  Because a symbol represents a
> mapping from a string name to a unique object.  Anytime in the execution
> of the program, if that name is used for a symbol, the original symbol
> object must be returned.  If the symbol is garbage collected, then a
> later reference to the symbol name will return a different object.
> That's generally frowned upon (although I don't really see the harm.  If
> the original symbol was GC'ed, nobody cared what the original object was
> anyways.  But that's the way it works).

Keep in mind that symbols are immediate values backed by
the global_symbols table (actually global_symbols.tbl and
global_symbols.rev, for the name => id and id => name associations
respectively). Since the lower bits encode information like ID_LOCAL,
ID_INSTANCE, etc., symbol values cannot point to the appropriate entry
in global_symbols the same way VALUEs for normal objects point to RVALUE
slots in the object heaps. [1]

During the mark phase, the stack must be scanned for references to live
objects. It's easy to verify if an unsigned (long) long seems to point
to an object, by seeing if the address falls into the area occupied by
some heap and actually corresponds to a slot. In order to mark symbol
entries
in global_symbols, a lookup in global_symbols.rev would be needed for
each
word in the stack. I conjecture that this would be relatively expensive,
but
there are probably better reasons for the current behavior (it's too
late to
read the sources in detail though :)...

[1] Even if those bits were not used, another level of indirection would
be needed due to the way the hash table works.
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2005-12-29 02:13
(Received via mailing list)
On Thu, Dec 29, 2005 at 06:51:29AM +0900, ara.t.howard@noaa.gov wrote:
> On Thu, 29 Dec 2005, Johannes Friestad wrote:
> >That's where the 'can be' part comes in :)
> >The point is that symbols support quicker lookup by their nature.
> >Whether they are quicker in practice will depend on the
> >implementation. From the timings you give, it looks like symbol lookup
> >is implemented by converting the symbol to a string and doing string
> >lookup. Which is obviously not quicker :)
>
> i never consider that as an impl - i bet your right though... time for me to
> read the source.

I think :sym.hash uses the method definition from Kernel (inherited
through
Object) and :sym.eql?(:foo) would also reuse the existing definition.

[see C code at the bottom]

So there's seemingly no reason for symbol hashing/comparison not to be
faster than for strings. The benchmarks you linked to, as well as Jim's,
use relatively short strings, but one can exaggerate the effect:


# >> Strings Filling
# >>   5.800000   0.000000   5.800000 (  6.302649)
# >> Strings Fetching
# >>   3.120000   0.010000   3.130000 (  3.404679)
# >>
# >> Symbols Filling
# >>   2.120000   0.000000   2.120000 (  2.326393)
# >> Symbols Fetching
# >>   0.640000   0.000000   0.640000 (  0.700178)


#!/usr/bin/env ruby

require 'benchmark'

SIZE = 100
N = 10000

RUBY_VERSION                                       # => "1.8.4"

def make_str_keys
  (1..SIZE).collect { |i| "long key" * i}
end

def make_sym_keys(strs)
  strs.collect { |s| s.intern }
end

def populate(keys)
  result = {}
  keys.each_with_index do |k, i|
    result[k] = i
  end
  result
end

def fetch(keys, hash)
  keys.each do |key| hash[key] end
end

strs = make_str_keys
syms = make_sym_keys(strs)

str_hash = populate(strs)
sym_hash = populate(syms)

puts "Strings Filling"
puts Benchmark.measure {
  N.times do
    populate(strs)
  end
}

puts "Strings Fetching"
puts Benchmark.measure {
  N.times do
    fetch(strs, str_hash)
  end
}

puts
puts "Symbols Filling"
puts Benchmark.measure {
  N.times do
    populate(syms)
  end
}

puts "Symbols Fetching"
puts Benchmark.measure {
  N.times do
    fetch(syms, sym_hash)
  end
}


    rb_define_method(rb_mKernel, "hash", rb_obj_id, 0);
...

VALUE
rb_obj_id(VALUE obj)
{
    if (SPECIAL_CONST_P(obj)) {
	return LONG2NUM((long)obj);
    }
    return (VALUE)((long)obj|FIXNUM_FLAG);
}


    rb_define_method(rb_mKernel, "eql?", rb_obj_equal, 1);
...

static VALUE
rb_obj_equal(VALUE obj1, VALUE obj2)
{
    if (obj1 == obj2) return Qtrue;
    return Qfalse;
}
Fe9b2d0628c0943af374b2fe5b320a82?d=identicon&s=25 Eero Saynatkari (rue)
on 2005-12-29 02:44
Yohanes Santoso wrote:
> Alex Knaub <aknaub@gmail.com> writes:
>
>> 2005/12/28, Surgeon <biyokuantum@gmail.com>:
>>> Hi,
>>>
>>> I am a Ruby newbie. I wish I didn't post such a simple question here
>>> but I had to.
>>> What is the difference between :foo (a keyword) and "foo"(a string).
>>> Can they be used interchangeably? Are they fundamentally same and is
>>> the only difference performance?
>>
>> http://onestepback.org/index.cgi/Tech/Ruby/Symbols...
>
> What a coincidence. Seems like Jim and I finally had enough of people
> conflating symbols and immutable strings on the same day.
>
> http://microjet.ath.cx/WebWiki/2005.12.27_UsingSym...

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. As this thread quite well demonstrates,
a definition for Symbols is quite difficult to come up with.

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."

> YS.


E
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-29 03:28
(Received via mailing list)
On 12/28/05, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>
Along with Jim and Mauricio, my tests indicate that symbols are
consistently quicker, even on short strings.

Here's my benchmark
-------
  def bmark_string_symb
    require 'benchmark'
    strings, symbols=[], []
    n, m=100, 1000
    hash={}
    n.times {|x| strings<<strings<<x.to_s+"key"}
    strings.each {|s| symbols<<s.to_sym}
    # initialize hash
    strings.each {|s| hash[s]=1}
    symbols.each {|s| hash[s]=1}
    Benchmark.bm(10) do |b|
      b.report("string set") { m.times {|x| strings.each {|s|
hash[s]=x}}}
      b.report("symbol set") { m.times {|x| symbols.each {|s|
hash[s]=x}}}
      b.report("string get") { m.times {|x| strings.each {|s| hash[s]}}}
      b.report("symbol get") { m.times {|x| symbols.each {|s| hash[s]}}}
    end
  end
-------

and here are some results:
-------
irb(main):080:0> bmark_string_symb
                user     system      total        real
string set  0.219000   0.016000   0.235000 (  0.235000)
symbol set  0.141000   0.000000   0.141000 (  0.141000)
string get  0.078000   0.000000   0.078000 (  0.078000)
symbol get  0.047000   0.000000   0.047000 (  0.047000)
=> true
=> true
irb(main):083:0> bmark_string_symb
                user     system      total        real
string set  0.234000   0.000000   0.234000 (  0.235000)
symbol set  0.063000   0.000000   0.063000 (  0.062000)
string get  0.078000   0.000000   0.078000 (  0.078000)
symbol get  0.047000   0.000000   0.047000 (  0.047000)
=> true
-------


There's a fair amount of variation, but symbols appear to behave as
expected (quicker on average), meaning that my guess that symbol
lookup in hashes was done on the basis of their string value was
wrong.
I guess I should learn to refrain from speculating until I've checked
closer :)

jf
918c6daad03c85e51ad1a11f57017947?d=identicon&s=25 Devin Mullins (Guest)
on 2005-12-29 03:32
(Received via mailing list)
Jim Weirich wrote:

>I'm not sure if this helped, or just muddied the water more.
>
>
When I first was trying to learn about symbols, attempts to explain
their "intentions" (as names of things, for example), rather than to
explain what they are, just muddied the water for me. Sure, give me some
advice on when and when not to use them, but also, tell me what they
are, so I can decide for myself:
- Like a string, but:
- Object-level equality, so :foo.equal?(:foo) and not
'foo'.equal?('foo')
- That means, with strings, if you say 'foo' 5 times in the code, you're
creating 5 string objects, whereas with symbols, you're only creating
one.
- Share many properties with Fixnum (both being "immediate")--
immutable, no singleton classes, object equality, not picked up by
ObjectSpace.each_object...
- Not garbage collected.
- Looks cooler -- by using a different syntax, you can give some visual
distinction between your keys and your values, for instance.

(Also, Johannes Friestad's explanation was pretty good, IMO.)

Devin
D4d28bd014f9e7324bad99dcc3b0d390?d=identicon&s=25 Rich Morin (Guest)
on 2005-12-29 03:53
(Received via mailing list)
At 11:31 AM +0900 12/29/05, Devin Mullins wrote:
> - That means, with strings, if you say 'foo' 5 times in the code, you're
> creating 5 string objects, whereas with symbols, you're only creating one.

I can understand this as a possible implementation, but I
really wonder about the follow-on statement that I've seen,
saying that this can cause memory leaks.  If I define a
string and then discard it, shouldn't it be GCed?

-r
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-29 03:56
(Received via mailing list)
BTW: Ruby version 1.8.2, Win XP Pro, Pentium M 2.0 GHz

jf
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-29 04:11
(Received via mailing list)
On Thu, 29 Dec 2005, Johannes Friestad wrote:

>> programs have shown the opposite to be true.
>>
>
> Along with Jim and Mauricio, my tests indicate that symbols are
> consistently quicker, even on short strings.

<snip test>

that way well be true now.  however, if you look at my test it goes to
some
lengths to make the test a little more 'real-world':

   - creats  a large (2 ** 13) hash
   - poplate using a semi-random distribution
   - selects keys for lookup in a semi-random distribution
   - fork for each test to isolate tests somewhat
   - disable GC for each test
   - runs each test 4 times

in anycase, all i'm driving at is that a pretty heavy duty test (not
saying
mine is that test) is required to eliminate the differences data
distribution,
gc, and system load have on the results.  in particular i can see how a
linear
distribution might have a huge effect - seeing as symbols are
essentially
numbers and hash more predictably whereas making the jump from '9999' to
'10000' is likely to land in quite a different bucket.

it's nonetheless very interesting to see some tests though.

i use both btw.  ;-)

-a
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-29 04:35
(Received via mailing list)
On Thu, 29 Dec 2005, Johannes Friestad wrote:

> BTW: Ruby version 1.8.2, Win XP Pro, Pentium M 2.0 GHz

your test did show symbols being faster on my (linux - 2g cpu, 2g ram)
machine
too btw...


but this slightly modified version shows strings being a tiny bit
faster:

   harp:~ > cat a.rb
   require 'benchmark'

   n = 2 ** 16
   string_hash, symbol_hash = {}, {}

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

   string_keys = string_hash.keys.sort_by{ rand }
   symbol_keys = symbol_hash.keys.sort_by{ rand }

   Benchmark.bm(10) do |b|
     b.report("string get"){ string_keys.each{|k| string_hash[k]}}
   end
   Benchmark.bm(10) do |b|
     b.report("symbol get"){ symbol_keys.each{|k| symbol_hash[k]}}
   end



   harp:~ > ./build/ruby-1.8.4/ruby ./a.rb
                   user     system      total        real
   string set  0.470000   0.000000   0.470000 (  0.471459)
                   user     system      total        real
   symbol set  0.640000   0.020000   0.660000 (  0.661556)
                   user     system      total        real
   string get  0.100000   0.000000   0.100000 (  0.101498)
                   user     system      total        real
   symbol get  0.080000   0.000000   0.080000 (  0.077205)


i think all we are showing here is that there aren't good reasons for
one over
the other.  but that's good to i supose - since people certainly seem to
have
preferences.

cheers.

-a
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-29 04:44
(Received via mailing list)
On Dec 28, 2005, at 4:18 PM, Dan Diebolt wrote:

> How about devoting the next Ruby Quiz to coming up with the best-of-
> class examples, self paced-tutorial and documentation to settle
> the :symbol vs "string" issue?

Hmm, smells like work and documentation combined.  Two evils in one
quiz.  ;)

I suspect that would make for an unpopular topic.

James Edward Gray II
918c6daad03c85e51ad1a11f57017947?d=identicon&s=25 Devin Mullins (Guest)
on 2005-12-29 05:14
(Received via mailing list)
Devin Mullins wrote:

> - Share many properties with Fixnum (both being "immediate")--
> immutable, no singleton classes, object equality, not picked up by
> ObjectSpace.each_object...
> - Not garbage collected.
> - Looks cooler -- by using a different syntax, you can give some
> visual distinction between your keys and your values, for instance.

- Lacking all those cool String methods like #gsub and #[]

so... nothing like a string.

Yeah, I dunno, the "some named thing" was just a little iffy. The
PickAxe was especially annoying in this respect by trying to imply that
a symbol was the name of a method, variable, or class, specifically.
Maybe I'm just ranting about that.

Sorry for the mess,
Devin
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2005-12-29 06:22
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.

--
-- Jim Weirich
73803e9b62fe9b6499db6a7ca87c909c?d=identicon&s=25 Surgeon (Guest)
on 2005-12-29 09:04
(Received via mailing list)
Oh, so many replies to my poor question! What a wonderful community!
D36eff3004b39abc4b93fe8a410d8bd3?d=identicon&s=25 Ron M (Guest)
on 2005-12-29 11:46
(Received via mailing list)
ara.t.howard@noaa.gov 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."
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-29 14:41
(Received via mailing list)
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 Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
B000982a23d5c6a34292902caf225dd7?d=identicon&s=25 Yohanes Santoso (Guest)
on 2005-12-29 15:39
(Received via mailing list)
Eero Saynatkari <ruby-forum-reg@mailinator.com> 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."
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-29 16:18
(Received via mailing list)
Hi --

On Thu, 29 Dec 2005, Steve Litt 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
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-29 16:46
(Received via mailing list)
On Thursday 29 December 2005 10:16 am, dblack@wobblini.net wrote:
> s/RUBY/Ruby/ :-)  In Ruby, P[olicy]OLS refers to what does or does not
> 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 Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-29 17:04
(Received via mailing list)
Hi --

On Fri, 30 Dec 2005, Steve Litt wrote:

> On Thursday 29 December 2005 10:16 am, dblack@wobblini.net 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
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-29 17:10
(Received via mailing list)
On Dec 29, 2005, at 9:45 AM, Steve Litt wrote:

> 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
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2005-12-29 17:23
(Received via mailing list)
On Thursday 29 December 2005 8:45 am, Steve Litt 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 Haines
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-29 17:32
(Received via mailing list)
On 29/12/05, Steve Litt <slitt@earthlink.net> 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.

http://www.oreillynet.com/ruby/blog/2005/12/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
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-29 17:53
(Received via mailing list)
On Thu, Dec 29, 2005 at 11:37:59PM +0900, Yohanes Santoso 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 Perrin [ 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
7aa02977cf2fe210e354e2a358a88d77?d=identicon&s=25 Jonathan Simms (Guest)
on 2005-12-29 17:53
(Received via mailing list)
On Dec 29, 2005, at 12:22 AM, Jim Weirich 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
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-29 18:11
(Received via mailing list)
On Thursday 29 December 2005 11:20 am, Kirk Haines wrote:
> On Thursday 29 December 2005 8:45 am, Steve Litt 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 Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
036a1b88dafaab8ffd73a8b0a74b5b38?d=identicon&s=25 Edward Faulkner (Guest)
on 2005-12-29 18:11
(Received via mailing list)
On Fri, Dec 30, 2005 at 01:50:14AM +0900, Chad Perrin 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).
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-29 18:14
(Received via mailing list)
On Thursday 29 December 2005 11:30 am, Austin Ziegler wrote:
> On 29/12/05, Steve Litt <slitt@earthlink.net> 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.
>
> http://www.oreillynet.com/ruby/blog/2005/12/symbol....
>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
slitt@troubleshooters.com
05e48e632fdd0b2c25d27042f52c11d5?d=identicon&s=25 A LeDonne (Guest)
on 2005-12-29 18:14
(Received via mailing list)
On 12/29/05, Austin Ziegler <halostatue@gmail.com> wrote:
<snip>
>
> 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
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-29 18:23
(Received via mailing list)
On Fri, Dec 30, 2005 at 02:09:40AM +0900, Edward Faulkner 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 Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

print substr("Just another Perl hacker", 0, -2);
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-29 19:06
(Received via mailing list)
On Dec 29, 2005, at 11:08 AM, Steve Litt 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 Gray II
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2005-12-29 19:12
(Received via mailing list)
On Thursday 29 December 2005 10:08 am, Steve Litt 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 Haines
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-29 19:21
(Received via mailing list)
On 29/12/05, Steve Litt <slitt@earthlink.net> 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.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
B000982a23d5c6a34292902caf225dd7?d=identicon&s=25 Yohanes Santoso (Guest)
on 2005-12-29 21:09
(Received via mailing list)
Chad Perrin <perrin@apotheon.com> writes:

> 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.

>> 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.

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.
5c7bdd14d6885c8275eaf78be41d120a?d=identicon&s=25 Eero Saynatkari (Guest)
on 2005-12-29 21:15
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.29 23:37, Yohanes Santoso
<ysantoso-rubytalk@dessyku.is-a-geek.org> wrote:
> >>>> What is the difference between :foo (a keyword) and "foo"(a string).
> > While, technically speaking, both of you are absolutely and
> 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.

Yes, I like the rationale presented. Perhaps I should have worded
differently: conflating Symbols with immutable strings (not Strings)
makes it easier to understand their function in ruby. Any ambiguity
resulting from this is far easier to correct than it is the assumption
that Symbols are identifiers or references or variables (rather than
values, which is the first thing anyone needs to know about Symbols).

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

This makes no sense to someone just starting.

> 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'.

This makes sense but, as you notice, you are using 'strings' in
your explanation :)

> 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.

Very good until this part. Symbols, most empathically, are *not*
identifiers (and I am quite sure this was merely a mistype/-thought
on your part).

> > 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."
>
>
> >
> >> YS.


E


- --
"That sort of thing happens in bath tubs maybe. Not in real life."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDtEyGxvA1l6h+MUMRAnowAJsEyO25UhFG6VF6RbDZbzQ1XpKMWACfcEd4
HpUQm6vCasi8Yg5UPkzfAqE=
=hXPD
-----END PGP SIGNATURE-----
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-29 21:46
(Received via mailing list)
On 12/29/05, Chad Perrin <perrin@apotheon.com> wrote:
> 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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-29 22:58
(Received via mailing list)
Hi --

On Fri, 30 Dec 2005, dblack@wobblini.net wrote:

>> to
>
>  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
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 00:38
(Received via mailing list)
On Thursday 29 December 2005 01:03 pm, James Edward Gray II wrote:
[clip]
> > class variable @wilbur,
>
> That's an instance variable, not a class variable.

I knew that :-) Skipping from Perl to C to C++ to Python to Ruby, I
sometimes
forget the terminology.
>
> As Austin taught us yesterday, it doesn't make the variable either,
> just some methods.

My understanding of Ruby is the getters and setters it makes make the
variable, because the setter sets @wilber to its argument.

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
5c7bdd14d6885c8275eaf78be41d120a?d=identicon&s=25 Eero Saynatkari (Guest)
on 2005-12-30 00:44
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 08:35, Steve Litt <slitt@earthlink.net> wrote:
> > just some methods.
>
> My understanding of Ruby is the getters and setters it makes make the
> variable, because the setter sets @wilber to its argument.

The instance variable is not created by the attr_* statement,
however. Only if you call  obj.attribute = something will it
be created (unless you create it in #initialize or something).

irb(main):001:0> class Foo
irb(main):002:1>   attr_accessor 'bar'
irb(main):003:1> end
=> nil
irb(main):004:0> f = Foo.new
=> #<Foo:0xb7de9be8>
irb(main):005:0> f.inspect
=> "#<Foo:0xb7de9be8>"
irb(main):006:0> f.bar = 5
=> 5
irb(main):007:0> f.inspect
=> "#<Foo:0xb7de9be8 @bar=5>"                # <-- This here
irb(main):008:0>

> SteveT


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

iD8DBQFDtH2ZxvA1l6h+MUMRAudYAKCRQTHp/6p70j83waz8y3r56i4mwACeNkAW
5rX3d6mtf9XMuGZlu+zyk/U=
=ogE8
-----END PGP SIGNATURE-----
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 01:38
(Received via mailing list)
On Fri, Dec 30, 2005 at 05:07:35AM +0900, Yohanes Santoso wrote:
> Chad Perrin <perrin@apotheon.com> writes:
>
> > 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?

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.


>
> > 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.

I think it's probably more useful to start by describing the actual
functional nature of a symbol, then start in with the analogies if that
doesn't make a lightbulb go on in the person's head.


>
> > 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.

"A means for you, the programmer, to name/identify entities" is not a
description of what a symbol *is* so much as a description of how you
can use it.  It seems awfully odd to me that everything else in the
language tends to get described in terms of what it actually is under
the hood, then starts getting analogies only if the target of the
explanation doesn't get it, while for some reason nobody starts an
explanation of symbols that way in Ruby.

For example: while saying that a method is "a verb" does help one to
"get" how verbs are used in the language, nobody really knows what a
method is until it's explained that it's a mini-algorithm whose
definition is part of a class definition, accessible by way of instances
thereof.  As such, someone always starts explaining what a method is
under the hood pretty quickly when trying to get the point of a method
across in teaching OOP.  With symbols, though, I keep seeing bland
assertions that a symbol is "just a name", or "a name that is an
object", or something like that, without any explanation of what a
symbol actually does behind the scenes.

I seem to have missed the blog post that mentioned the relationship to
Lisp methods, but even that didn't really address the matter as clearly
as I would have expected.


> >From WordNet (r) 2.0 (August 2003) [wn]:
>
>   identifier
>       n : a symbol that establishes the identity of the one bearing it

. . . which, unfortunately, in no way explains what one does with a
"symbol" in a programming context in a helpful way.

A symbol is an element (or a reference to an element, though I hesitate
to use the term "reference" with its programming contextual baggage) in
a hash table.  A hash table is, in short, a list maintained "by the
language" rather than by the user.  From the programmer's point of view,
this list essentially has only values, not keys, though from the
language's point of view it most certainly has keys.  This is primarily
useful for applying names to things, thus the common assertion that "a
symbol is a name".

Is that close, or have I missed something?

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall
5c7bdd14d6885c8275eaf78be41d120a?d=identicon&s=25 Eero Saynatkari (Guest)
on 2005-12-30 02:44
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 09:36, Chad Perrin <perrin@apotheon.com> wrote:
> 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.

Nope, Symbols have nothing to do with Hashes. They are often used
as Hash keys because they are descriptive: h[:foo] is better than
h[1] if one wants to convey some meaning with the key. In other
languages, you might use a string instead of a Symbol (and you
can, of course, do so in ruby as well: h['foo']).

>
> "A means for you, the programmer, to name/identify entities" is not a
> definition is part of a class definition, accessible by way of instances
>
> >
> a hash table.  A hash table is, in short, a list maintained "by the
> language" rather than by the user.  From the programmer's point of view,
> this list essentially has only values, not keys, though from the
> language's point of view it most certainly has keys.  This is primarily
> useful for applying names to things, thus the common assertion that "a
> symbol is a name".
>
> Is that close, or have I missed something?


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

iD8DBQFDtJmoxvA1l6h+MUMRApdyAJ4tpDcrx5X9ZuP2J9xn5lNLhZfbMQCfbYqG
x9YzyZMOlgYTH1d8ZyBy2OM=
=6asn
-----END PGP SIGNATURE-----
5c7bdd14d6885c8275eaf78be41d120a?d=identicon&s=25 Eero Saynatkari (Guest)
on 2005-12-30 02:47
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 06:56, dblack@wobblini.net wrote:
> >>> Just out of curiosity:  can you describe how symbols would work if
> >  s = :sym
> reference to :sym; rather, s has the actual/immediate value :sym.
> Anyway, the main (obscured) point was that symbols are not references.

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

> Anyway, I just wanted to ungarble that post a little :-)
>
>
> David


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

iD8DBQFDtJqOxvA1l6h+MUMRAqwhAKCatKyxn2DGqWoPGUyfIrxMIgLRWACeN1CV
yZoLjAC5NQbaZY7mUfYZh/0=
=Z5I7
-----END PGP SIGNATURE-----
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 03:38
(Received via mailing list)
On Fri, Dec 30, 2005 at 10:42:33AM +0900, Eero Saynatkari wrote:
> > 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.
>
> Nope, Symbols have nothing to do with Hashes. They are often used
> as Hash keys because they are descriptive: h[:foo] is better than
> h[1] if one wants to convey some meaning with the key. In other
> languages, you might use a string instead of a Symbol (and you
> can, of course, do so in ruby as well: h['foo']).

Apparently, a more significant distinction needs to be made between a
"hash table" in the symbol sense of the term and a "hash" in the sense
of an associative array.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
918c6daad03c85e51ad1a11f57017947?d=identicon&s=25 Devin Mullins (Guest)
on 2005-12-30 03:38
(Received via mailing list)
Austin Ziegler wrote:

>The Symbol is just a name.
>
>
Er... a thing that /has/ a name. (That being, Symbol#to_s.)

A symbol's just a thing. :apple == :apple. :apple.to_s == "apple".
:apple.to_i == 23417. The end.*

AFAIK, you *can* use a String to do all the things you would do with a
Symbol (i.e. identify things)+, but using Symbols is more fun! (More
performant, possibly, for the purpose of static identifiers, and a
little less line noise, when used as the key to a hash, for example.
Plus, if you're using a text editor with syntax highlighting, they'll
show up a different color, which is fun.)

Devin
* Though I'm not a very good one, I'm a mathematician at heart, so I
like to define things by their properties.
+ This is because all the builtin methods that are meant to take a
Symbol as a parameter tend to call its #== or #eql? or #hash or #to_s
method (the properties of which String mimicks, to an isomorphism), or
allow a String to be passed in its place (as is the case with attr_*,
e.g.).
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 03:38
(Received via mailing list)
On Fri, Dec 30, 2005 at 10:46:23AM +0900, Eero Saynatkari wrote:
> 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 :/

I disagree.  If the underlying semantic mechanism of a symbol isn't
understood, symbols won't be understood.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
918c6daad03c85e51ad1a11f57017947?d=identicon&s=25 Devin Mullins (Guest)
on 2005-12-30 04:26
(Received via mailing list)
Devin Mullins wrote:

> Austin Ziegler wrote:
>
>> The Symbol is just a name.
>
> Er... a thing that /has/ a name. (That being, Symbol#to_s.)

OK, well, I RTFA, and sorry for blatantly contradicting what was an
intentional choice of words (and not, as I had thought, a slip-up)
without reason. Anyways, to quote you:

>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.
>
Calling it a "name" is just another analogy. Its name is its String
representation, just as Module#name == Module#to_s (for non-singletons).
Rather, :jazz is :jazz is :jazz. There is no reducing it to other
concepts.

Devin
Yeah, I know, total 540.
5c7bdd14d6885c8275eaf78be41d120a?d=identicon&s=25 Eero Saynatkari (Guest)
on 2005-12-30 05:39
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005.12.30 11:38, Chad Perrin <perrin@apotheon.com> wrote:
> >
> > 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 :/
>
> I disagree.  If the underlying semantic mechanism of a symbol isn't
> understood, symbols won't be understood.

Neither of the above is in any way essential to understanding the
concept of a Symbol (as it appears in ruby), they are implementation
details. Symbols could perform the exact same function they do now
even as a user-defined construct. I do not think it is at all necessary
to know either of these facts to be able to use Symbols.

I am, of course, only speaking from my own point of view but I
do have some experience in introducing ruby Symbols to new users.
Doing that I have found that it is simplest to introduce Symbols
as names or descriptive values, similar to regular strings in that
respect. This but-what-are-they-for foundation established it is
easy to introduce additional implementation details.

One size definitely does not fit all; people learn differently.

  1. Symbols are values.
     :foo is like 'foo' or 2 or f = FooObject.new

  2. Symbols are used to name, describe or label things.
     cd_drive_type = :dvd_rom
     socks = my_closet[:sock_drawer]

  3. Common usages.
     object.send :method_name, parameter    # Could use 'method_name'
     attr_accessor :property1, :property2   # Could use 'property1' etc.

  4. Implementation details.


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

iD8DBQFDtMJTxvA1l6h+MUMRApnZAJ9O8dm9GAw+NTVT5AibfIBWPqFzmgCglyXm
i0rCU+NMdYvNP7b1GA5wg+I=
=WSB5
-----END PGP SIGNATURE-----
Ace7fa5337acbdf5897a6fc035897580?d=identicon&s=25 J. Ryan Sobol (Guest)
on 2005-12-30 05:42
(Received via mailing list)
To whom who asked this question, open your console / terminal and type:

ri Symbol

Then type:

ri String

~ ryan ~
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-30 05:45
(Received via mailing list)
On Dec 29, 2005, at 9:38 PM, Chad Perrin wrote:
> I disagree.  If the underlying semantic mechanism of a symbol isn't
> understood, symbols won't be understood.

I think one of the hardest things to explain/comprehend
about symbols is that the *only* semantics associated
with a symbol is that there is a one to one mapping from a symbol
object to a sequence of characters. It is this isomorphism that
is the useful (and *only*) property of symbols.

The sequence of characters can be specified by
a literal symbol identifier (e.g. :red, :white, :"navy blue"), in which
case the mapping to a symbol reference is done by the parser, or the
sequence of characters can be specified by an instance of a String
("red") and mapped to a symbol reference via the String#to_sym method
("red".to_sym)

This is entirely analogous to how integer literals are handled.
A sequence of characters (ascii 51, ascii 53) is mapped by the
parser to a reference to an object that has the properties of the
number 35.
You can also take an instance of String ("35") and have String#to_i
map it to a reference of an object that has the properties of the
number 35
("35".to_i). That doesn't mean that the string "35" *is* the number
35, just that
there is an isomorphism from a sequence of digits to references to
integers.

I've been careful to say 'reference to an object' and not 'object'
because
the values stored in variables or constants are references to
objects, not
the objects themselves.  For some classes, such as Fixnum, Float, or
Symbol, the
objects are implicit and Ruby derives them from the reference itself
when needed
and for other objects, say String or Array, the reference is used to
locate the
object in memory.

With integers, the referenced object associated with the sequence of
digits
has nice numerical properties but symbols have no properties
other than their property of being uniquely identifiable.

So when your intent is to reference objects with distinct identities
but no
other properties, Symbols are the way to go.  You could use integers
of course, they also are unique and easily represented by
a sequence of characters, but which is more meaningful?

	flavors = [1,2,3]
	flavors = [:chocolate, :vanilla, :strawberry]

I think symbols get confused with methods, and classes, and instance
variables
because the concept of identity is just as useful to an application
programmer
as to a language implementor (that and the PickAxe incorrectly says
they are
directly related).  Ruby just happens to expose the identity of various
language internals using the same mechanism (symbols) as is available
to the
application programmer.  No one gets confused when an Array reports
its size
using the integer 5 even though the programmer may have also used the
number
5 to limit the size of a zipcode field.  Similarly the idea that Ruby
might
use the symbol identified by :size to uniquely identify an instance
method
in the class Array shouldn't be confused with a programmer using the
same
symbol to identify a method in a class they have defined.  The symbol
is the
same in both cases but the context is different so there is no
ambiguity.
B000982a23d5c6a34292902caf225dd7?d=identicon&s=25 Yohanes Santoso (Guest)
on 2005-12-30 06:12
(Received via mailing list)
Chad Perrin <perrin@apotheon.com> writes:

> 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.

Well, what can I say? Symbol is really meant to represent a
name/identifier.

Let's stop with analogies since obviously we are not
analogy-compatible, and get on with the concretes.

What is 1? A way to represent the number one. You said a way, what
others are there? 0x1, \001, "1". However, one does not use "1" to
represent the number one even if one doesn't plan to do any arithmetic
operations on that number because that representation is
ambiguous. Does he mean "1" as in number one or as in the character
"1"?

What is :server? A way to represent the name/identifier
``server``. What others are there? "server" is another one. But it is
also ambigious. Does he mean the name/identifier ``server`` or the
character sequence "s","e","r","v","e","r"?

I can see no way to describe 1 without involving number. Similarly, I
can see no way to describe :server without involving
name/identifier. Perhaps you can.

> "A means for you, the programmer, to name/identify entities" is not a
> description of what a symbol *is* so much as a description of how you
> can use it.

I really am not sure what you are saying there. That sentence
describes what a symbol is. That sentence does not describe/prescribe
how to use it.

Here, let me paraphrase my sentence: "[Symbol is] a means for you, the
programmer, to [represent the] name/identit[y] of entities". Did I
manage to preserve the meaning?  Let's do word substitution. "Number
is a means for you, the programmer, to represent numbers". In no way
am I describing/prescribing how to use instances of Number.

> object", or something like that, without any explanation of what a
> symbol actually does behind the scenes.

This is precisely the kind of explanation that I objected when
explaining what a symbol is to a newcomer. Any explanation that refer
to the implementation is doomed to be short-lived. There are many ways
to implement the class Symbol and the concept of symbol.

Do you explain what number does behind the scenes to someone asking
'What is a number?' Do you explain that ruby maps number less than
2^31-1 directly to native integer format? Quick question, then: does
this still hold on a 64-bit machine? How about in ruby 2.0? Will
Number behave differently and is used to represent different thing
there simply because what goes on behind the scene has changed?

If one is interested in how something is implemented in a specific
environment, one should ask for that (and there are posts in this
thread dwelving into how Symbol is implemented in current ruby VM).

In any case, if someone can give me a description of what 1 is without
involving number, then I'll show you a description of what symbol is
without involving name/identifier.

YS.
918c6daad03c85e51ad1a11f57017947?d=identicon&s=25 Devin Mullins (Guest)
on 2005-12-30 06:27
(Received via mailing list)
For the heck of it, I decided to come up with my own Symbol analogy.
Caveat reader:

A symbol is a bubble. In Ruby-land, there is this ever-present *ether*
wherein lies an abundance of bubbles.

<picture of a bunch of bubbles, each with a symbol literal inside --
feel free to Gimp it into existence -- here's a starter kit:
http://www.scrapbookerie.com/images/autocollants/S...

Every symbol you could ever want is out there, in the ether, bubbling
along. For every name, there is a single bubble. For every bubble, there
is a single name.

When you assign +x = :mr_t+, as with all variable assignments, you're
pointing x to the :mr_t object. Here, you're pointing at that bubble
that the Ruby interpreter recognizes as :mr_t. For plausability reasons,
the Ruby interpreter blows the :mr_t bubble the first time you mention
its name, but for your sake, you can assume that the :mr_t bubble has
always existed and always will exist -- it's just there, floating in the
ether, waiting to be pointed to.

So from that description right there, we already know one thing we can
do with bubbles--er, Symbols--determine equality. Are these two
variables pointing to the same bubble? Find me the Hash value whose
associated key is this bubble I'm pointing to right now. For programming
convenience, these bubbles have names associated with them, but as far
as your code is concerned, they're just bubbles. This is the magic
behind {:server => 'localhost', :port => 80}, etc.

The other (principal) thing you can do with a bubble--eh, Symbol--is
find out its name at runtime (thanks to #to_s or #id2name). Thus,
attr_accessor :mcklellan is born. I'm passing along a pointer to the
:mcklellan bubble. attr_accessor follows the pointer, talks to that
bubble, asks it what its name is, and uses that information to define
some methods. Here, :mcklellan is just used as a fancy shorthand for
'mcklellan'. (It happens to be one I like, but I digress...)

So, uh, yeah. That's it. The End.

Ha, yeah, so that description is probably more unsettling than settling,
but maybe it'll plant a seed of wisdom, or whatnot. Plus, I can rest
easy, now that I've solved everybody's problems.

Devin
Did I really just digress into "The End"?
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-30 06:48
(Received via mailing list)
On 29/12/05, Devin Mullins <twifkak@comcast.net> wrote:
> Austin Ziegler wrote:
> >The Symbol is just a name.
> Er... a thing that /has/ a name. (That being, Symbol#to_s.)

No, I think that the essential property of a Symbol is that it is an
object that is a name:

  keep = Symbol.all_symbols
  quuxl = nil
  puts Symbol.all_symbols - keep

You'll see that :quuxl is there. You can get a string representation
of that name (:quuxl.to_s) or an integer representation of that name
(:quuxl.to_i), but the canonical representation of that name is the
Symbol itself (:quuxl). Sure, you could get pedantically
philosophical, but the you'd be saying that 1 really isn't the number,
it's a thing that represents a quantity of one.

For all practical purposes, Symbols are atomic in the sense that they
are themselves. Who *cares* how it's actually represented in the
implementation? That can change. The fundamental nature of a Symbol is
that :quuxl will always be :quuxl and never anything else. Consider
these two IRB sessions:

irb(main):001:0> :bar.to_i
=> 23417
irb(main):002:0> :quuxl.to_i
=> 23425
irb(main):003:0>

irb(main):001:0> :quuxl.to_i
=> 23417
irb(main):002:0> :bar.to_i
=> 23425
irb(main):003:0>

A Symbol, like a number, is immediate and is identified by itself.

-austin
918c6daad03c85e51ad1a11f57017947?d=identicon&s=25 Devin Mullins (Guest)
on 2005-12-30 07:03
(Received via mailing list)
Heh, one of my emails to the list got eaten (by a grue?). Let's try this
again:

Devin Mullins wrote:

> Austin Ziegler wrote:
>
>> The Symbol is just a name.
>
> Er... a thing that /has/ a name. (That being, Symbol#to_s.)

OK, well, I RTFA, and sorry for blatantly contradicting what was an
intentional choice of words (and not, as I had thought, a slip-up)
without reason. Anyways, to quote you:

> 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.

Calling it a "name" is just another analogy. Its name is its String
representation, just as Module#name == Module#to_s (for non-singletons).
Rather, :jazz is :jazz is :jazz. There is no reducing it to other
concepts.

Devin
Yeah, I know, total 540.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 08:00
(Received via mailing list)
On Fri, Dec 30, 2005 at 02:10:09PM +0900, Yohanes Santoso wrote:
> Chad Perrin <perrin@apotheon.com> writes:
>
> What is 1? A way to represent the number one. You said a way, what
> others are there? 0x1, \001, "1". However, one does not use "1" to
> represent the number one even if one doesn't plan to do any arithmetic
> operations on that number because that representation is
> ambiguous. Does he mean "1" as in number one or as in the character
> "1"?

Then why not simply say:

    :symbol is to "symbol" as 1 is to "1"

That would get the point across far more clearly than saying "A symbol
is just a name," especially since strings can be names (from another
perspective), and since variables are "names" in another sense of the
term, and so on.  Saying it's "a name" doesn't explain jack, as far as I
can tell.

Being vague doesn't help.


>
> > "A means for you, the programmer, to name/identify entities" is not a
> > description of what a symbol *is* so much as a description of how you
> > can use it.
>
> I really am not sure what you are saying there. That sentence
> describes what a symbol is. That sentence does not describe/prescribe
> how to use it.

Let's take a look at that sentence's structure and meaning:

    A [something] is a means [. . .] to [do something].

Gee, looks like a description of how one uses it.  A symbol is a means
to name/identify entities.  A screwdriver is a means to turn screws.  A
mug is a means to transport coffee.  By the same token, however,
telekinesis is a means to turn screws, as is a centrifuge if you really
want to put screws into one, for some definition of "turn".  Also, a
hose, a Folger's can, and an eighteen wheeler might be a means for
transporting coffee.  It's vague and, ultimately, useless for getting
the point across, that point being:  What *is* it?

A screwdriver is a handle affixed to a metal shaft with a bit on the end
that serves as the interface for the screw -- the torque point, if you
will.  A mug is a drinking vessel that is ideally suited to beverages
such as coffee, allow you to transport the hot beverage from the coffee
pot to your lips after it has been prepared and poured.

For someone who doesn't already know what a mug or screwdriver actually
is, the mere description of what each is a means to do is far too vague
to actually impart much understanding.


>
> > object", or something like that, without any explanation of what a
> > symbol actually does behind the scenes.
>
> This is precisely the kind of explanation that I objected when
> explaining what a symbol is to a newcomer. Any explanation that refer
> to the implementation is doomed to be short-lived. There are many ways
> to implement the class Symbol and the concept of symbol.

It may be doomed to be short lived, but without some kind of example
that is recognizable, the prospective student is more likely than not to
learn very little of anything.


>
> Do you explain what number does behind the scenes to someone asking
> 'What is a number?' Do you explain that ruby maps number less than
> 2^31-1 directly to native integer format? Quick question, then: does
> this still hold on a 64-bit machine? How about in ruby 2.0? Will
> Number behave differently and is used to represent different thing
> there simply because what goes on behind the scene has changed?

Unlike symbols, numbers are pretty well understood, particularly for
someone coming from another programming language (any language except
the original, archetypal "lisp", pre-implementation, involves numbers).
Symbols are another matter entirely.

The problem with most of the descriptions of symbols I've seen is that
they try to define symbols in terms of themselves to people who don't
already understand those terms.  A framistan is a thing.  Whee.  That
taught me nothin'.

This approach to explaining symbols is equivalent to trying to teach
object oriented programming with nothing more than the statement that
"an object is a thing".  Okay, great.  What kind of thing?  What are all
these terms like "method/message" and "class" and "instance" and so on?
There are entire college courses devoted (almost) solely to imparting a
rudimentary understanding of what an "object" is and how it is used.
Why can't someone come up with a better explanation of a symbol than the
five-word sentences that are so common here?

--
Chad Perrin [ 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
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 08:12
(Received via mailing list)
On Fri, Dec 30, 2005 at 01:36:05PM +0900, Eero Saynatkari wrote:

    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.
>      attr_accessor :property1, :property2   # Could use 'property1' etc.
>
>   4. Implementation details.

Am I wrong?

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

print substr("Just another Perl hacker", 0, -2);
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-30 08:22
(Received via mailing list)
On Dec 30, 2005, at 12:45 AM, Austin Ziegler wrote:
> Sure, you could get pedantically
> philosophical, but the you'd be saying that 1 really isn't the number,
> it's a thing that represents a quantity of one.

But 1 (as in the ascii character code 49) is *not* the number/object
one.
And the reference value that the Ruby parser constructs when it sees
the ascii character code 49 is also *not* the number/object one.

I don't think it is possible to have a coherent discussion of Ruby
semantics without clearly and consistently differentiating between
an object, a reference to an object, and an identifier that is
bound to a reference to the object.  In particular, the semantics
of assignment/equality/identity can't be fully explained without
carefully distinguishing between these ideas.

Yes it sounds very pedantic but the devil is in the details.

Gary Wright
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 08:46
(Received via mailing list)
On Fri, Dec 30, 2005 at 01:42:39PM +0900, gwtmp01@mac.com wrote:
>
> I think one of the hardest things to explain/comprehend
> about symbols is that the *only* semantics associated
> with a symbol is that there is a one to one mapping from a symbol
> object to a sequence of characters. It is this isomorphism that
> is the useful (and *only*) property of symbols.

If you want a useful introductory description of symbols for someone
that hasn't encountered them before, the above is the only part of your
previous email that is taking steps in that direction.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

print substr("Just another Perl hacker", 0, -2);
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 08:58
(Received via mailing list)
On Fri, Dec 30, 2005 at 03:01:34PM +0900, Devin Mullins wrote:
>
> Calling it a "name" is just another analogy. Its name is its String
> representation, just as Module#name == Module#to_s (for non-singletons).
> Rather, :jazz is :jazz is :jazz. There is no reducing it to other concepts.

That's something I've been trying to get across in other emails, but I
don't think I've done a very good job.  Thus, using the "symbol is just
a name" analogy doesn't actually explain what a symbol *is*.  Analogies
are essentially useless without the technically correct explanation for
them to illustrate.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-30 09:19
(Received via mailing list)
On Dec 30, 2005, at 2:44 AM, Chad Perrin wrote:

> your
> previous email that is taking steps in that direction.

I wasn't trying to produce a useful introductory description
of symbols.  Nor do I really think that first paragraph would be all
that appropriate for that purpose.  'Isomorphism' isn't exactly in
common use.

Gary Wright
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2005-12-30 09:19
(Received via mailing list)
On 12/30/05, Chad Perrin <perrin@apotheon.com> wrote:

> That's something I've been trying to get across in other emails, but I
> don't think I've done a very good job.  Thus, using the "symbol is just
> a name" analogy doesn't actually explain what a symbol *is*.  Analogies
> are essentially useless without the technically correct explanation for
> them to illustrate.
>

You know.  I'm tired of hearing about how incorrect everyone is and
how they haven't found a solution that meets your needs.  It's frankly
becoming insulting.

kill-filed.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 09:40
(Received via mailing list)
On Fri, Dec 30, 2005 at 05:17:43PM +0900, gwtmp01@mac.com wrote:
> >
> >If you want a useful introductory description of symbols for someone
> >that hasn't encountered them before, the above is the only part of
> >your
> >previous email that is taking steps in that direction.
>
> I wasn't trying to produce a useful introductory description
> of symbols.  Nor do I really think that first paragraph would be all
> that appropriate for that purpose.  'Isomorphism' isn't exactly in
> common use.

Sorry.  I didn't mean to suggest that you must intend to produce a
useful introduction.  I guess I wasn't clear.  I was just saying that
*if* "you" (for some definition of "you") wanted to produce such an
introduction, that one part of your message seemed to be a step in the
right direction.  The language wasn't particularly accessible (as you
point out), but the concepts were, and didn't require a firm grounding
in Ruby to understand them.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 09:40
(Received via mailing list)
On Fri, Dec 30, 2005 at 05:18:46PM +0900, Gregory Brown wrote:
> You know.  I'm tired of hearing about how incorrect everyone is and
> how they haven't found a solution that meets your needs.  It's frankly
> becoming insulting.
>
> kill-filed.

hallelujah

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2005-12-30 11:06
(Received via mailing list)
On 12/30/05, Chad Perrin <perrin@apotheon.com> wrote:
>     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
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2005-12-30 14:07
(Received via mailing list)
Steve Litt <slitt@earthlink.net> writes:

> 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.

That just means you didn't dig deep enough into Ruby (yet). ;-)
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 15:56
(Received via mailing list)
On Thursday 29 December 2005 07:36 pm, Chad Perrin wrote:
> 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
slitt@troubleshooters.com
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-30 16:21
(Received via mailing list)
Hi --

On Fri, 30 Dec 2005, Eero Saynatkari wrote:

> 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
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 16:37
(Received via mailing list)
On Friday 30 December 2005 08:06 am, Christian Neukirchen wrote:
> Steve Litt <slitt@earthlink.net> writes:
> > 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.
>
> 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
slitt@troubleshooters.com
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-30 16:40
(Received via mailing list)
On 30/12/05, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
> On Dec 30, 2005, at 12:45 AM, Austin Ziegler wrote:
>> Sure, you could get pedantically philosophical, but the you'd be
>> saying that 1 really isn't the number, it's a thing that represents a
>> quantity of one.
> But 1 (as in the ascii character code 49) is *not* the number/object
> one. And the reference value that the Ruby parser constructs when it
> sees the ascii character code 49 is also *not* the number/object one.

Um. I was not referring to "1" as in the ASCII value, but "1" in the
sense of an Arabic numeral. You're right; ASCII 49 is the ASCII glyph
for the Arabic numeral "1" and said glyph *means* an integer value
greater than zero and less than two.

Only mathematicians and pedants (is there a difference? ;) tend to care
about the distinction between the symbolic representation and actual
value.

Inasmuch as 1 represents the integer value one, any given Symbol
represents itself. Really, only other immediate values can remotely be
said to do that in Ruby. :wilbur represents :wilbur. No more, no less.

> I don't think it is possible to have a coherent discussion of Ruby
> semantics without clearly and consistently differentiating between an
> object, a reference to an object, and an identifier that is bound to a
> reference to the object.

Um. There's no meaningful difference in Ruby between an object and a
reference to that object. There is a difference between the identifier
holding an object (or its reference, if you wish to be pedantic) and the
object, but it is a difference that many programmers new to Ruby have to
unlearn and learn (variables are labels, not memory slots, in Ruby).

Some objects are created such that there can only be one object with a
particular representation: immediate values. "foo" and "foo" creates two
different objects; :foo and :foo create a single object. It's atomic and
self-identifying.

-austin
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-30 16:59
(Received via mailing list)
On 30/12/05, Steve Litt <slitt@earthlink.net> wrote:
> 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	# => :wilbur

You can *convert* a Symbol to a string:

  puts :wilbur.to_s		# => wilbur

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

  puts :wilbur.to_i		# => 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		# => 1

Look at what Symbol.instance_methods(false) returns:

  ["inspect", "to_int", "===", "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
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 17:08
(Received via mailing list)
On Friday 30 December 2005 10:55 am, Austin Ziegler wrote:
>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
slitt@troubleshooters.com
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2005-12-30 18:43
(Received via mailing list)
Steve Litt <slitt@earthlink.net> writes:

> 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!

Oh, I'm sorry.  I think you got me wrong.  I was refering to the "most
suprising element" for you.  There are mystic parts of ruby that are
far more suprising.  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.
Af95bdaf87958c40150b813e94381bfd?d=identicon&s=25 Christer Nilsson (christer)
on 2005-12-30 19:00
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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2005-12-30 19:07
(Received via mailing list)
On 12/30/05, Christian Neukirchen <chneukirchen@gmail.com> wrote:

> 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/understand...

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
Af95bdaf87958c40150b813e94381bfd?d=identicon&s=25 Christer Nilsson (christer)
on 2005-12-30 19:08
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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2005-12-30 19:19
(Received via mailing list)
On Dec 30, 2005, at 1:08 PM, Christer Nilsson wrote:
> 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!

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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2005-12-30 19:28
(Received via mailing list)
On 12/30/05, gwtmp01@mac.com <gwtmp01@mac.com> wrote:

> 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)
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 20:53
(Received via mailing list)
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
slitt@troubleshooters.com
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-30 21:05
(Received via mailing list)
On 30/12/05, Steve Litt <slitt@earthlink.net> wrote:
> 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
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2005-12-30 21:30
(Received via mailing list)
On Friday 30 December 2005 1:03 pm, Austin Ziegler wrote:

> 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
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 21:36
(Received via mailing list)
On Friday 30 December 2005 03:03 pm, Austin Ziegler wrote:
> > >
>    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
slitt@troubleshooters.com
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 21:42
(Received via mailing list)
On Friday 30 December 2005 03:29 pm, Kirk Haines wrote:
> > value of a Symbol is not its String value or its Fixnum value, but
> :
>
> 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
slitt@troubleshooters.com
9c7f2f44463d1d4890f73e8a8229dd29?d=identicon&s=25 Caleb Tennis (Guest)
on 2005-12-30 21:51
(Received via mailing list)
> 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.
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2005-12-30 21:54
(Received via mailing list)
On Friday 30 December 2005 1:40 pm, Steve Litt wrote:

> 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
9c7f2f44463d1d4890f73e8a8229dd29?d=identicon&s=25 Caleb Tennis (Guest)
on 2005-12-30 21:57
(Received via mailing list)
> When I do the following:
>
>   attr_accessor :foo

For me, the colon was the most confusing part.  Ignoring the colon, it
logically made sense to me that you'd want to do a:

attr_accessor  foo1, foo2, foo3

Then, you realize "hey, I can't do that, because foo1, foo2, and foo3
represent local variables or methods or some object in the system".

Then I pull out my C/C++ hat and say:

attr_accessor "foo", "foo2", "foo3"

And that makes much more sense, because I have to pass the names somehow
to
attr_acessor - and it's very common to using strings to do this in the
C++
world.

Then you learn that every time Ruby sees a string it has to create a new
String object, and there's overhead involved.  Instead, there's a
special
class called Symbol which works kind of like a String, at least for
these
purposes, and once you've ever created one it's always around.

Then it isn't profound until you see code like this:

1000.times do
  some_object.getProperty("name")
end

and you realize that every time that gets executed a new "name" string
has to
be created, and that's not so nice.  But if you do a:

1000.times do
  some_object.getProperty(:name)
end

Wow, that's much more fantastic.

And eventually you just "get it".
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2005-12-30 22:03
(Received via mailing list)
On Friday 30 December 2005 03:50 pm, Caleb Tennis wrote:
> 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.

I understand what you're saying Caleb. Austin -- is that what you meant?

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-30 22:55
(Received via mailing list)
On 30/12/05, Steve Litt <slitt@earthlink.net> wrote:
> >
> > 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.
>
> I understand what you're saying Caleb. Austin -- is that what you meant?

Yes. I've just sent you a VERY lengthy VERY critical review of your
document that emphasizes that it is a conversion at all times. Symbols
have neither string nor integer values, but has converters.

-austin
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-30 23:28
(Received via mailing list)
On Sat, Dec 31, 2005 at 12:55:55AM +0900, Austin Ziegler wrote:
>
> Hopefully that's a bit clearer. It's not that different from Perl
> barewords.

My understanding is that barewords are not persistent atomic elements of
code the way symbols are -- they are immediately slotted into some other
syntactic meaning by context, and if context doesn't suggest any meaning
in particular, they're assumed to be strings.  In general, what this
means is that if you use a word without hints to what it is, it's a
subroutine if you have defined a subroutine by that name, and otherwise
it's just a shorthand way of using a literal string by omitting quotes.

To compare a symbol to that seems to be short-changing the potential
uses of symbols.

There is a Symbol module for Perl, which I haven't used and
unfortunately don't know much about, but my understanding is that it's
pretty limited in comparison with Lisp (or, now, Ruby) symbols, in that
it's just a wrapper for globs.  It seems to me that if you want to draw
a comparison between Ruby symbols and something in Perl, globs are the
better choice, in fact, as far as the way they "act" under pressure,
though they are limited in that where a Ruby symbol is "a name" for
anything, a Perl glob is "a name" only within a filehandle context.

I haven't really thought about it before this, but I'm actually kinda
disappointed that Perl doesn't have a fully operational death star . . .
err, I mean that it doesn't have anything like symbols, except in a very
limited sense.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 00:22
(Received via mailing list)
Note:  This reply is sent directly to you, not to the list.

On Sat, Dec 31, 2005 at 04:51:22AM +0900, Steve Litt wrote:
>
> The Ruby Newbie Guide to Symbols is here:
>
> http://www.troubleshooters.com/codecorn/ruby/symbols.htm

Excellent.  Hopefully, I'm not overstepping myself by sending critiques,
but I have some suggestions:

1.  The third paragraph kinda comes across as apologetic and hedging too
much.  I thought about possible ways to rephrase it, but ultimately, I
think it would best be simply deleted.  It doesn't seem to actually
serve any useful purpose within the text of the tutorial.

2.  The "What do they resemble in other languages?" should probably have
something in it, or be removed entirely without any reference to
resembling something in another language.  You might consider making a
note about it being a work in progress, with a solicitation for comments
from readers who understand symbols about what they resemble from other
languages.  If you do so, I'd recommend a very strong disclaimer to the
effect that resemblance is not the same as equivalency, and one should
take care in thinking of symbols as being similar to features in other
languages.  In particular, you might mention:

    a.  Ruby symbols bear a superficial resemblance to barewords in
    Perl, but are not much the same in practice.

    b.  Ruby symbols bear some resemblance to globs, though globs are
    limited to use in relation to filehandles.  By extension (and,
    unsurprisingly) Ruby symbols also bear some resemblance to the
    treatment of globs by the Perl module, Symbol, though it is only an
    unreasonable facsimile of Ruby symbols because it is just a wrapper
    for globs meant to make them more symbol-like in appearance.

    c.  Ruby symbols are similar to Lisp symbols, with the exception
    that in addition to the characteristics of symbols in Lisp, they are
    also objects in Ruby.

3.  In "What are symbols?" you might consider drawing a direct
comparison between symbols and numbers (or even integers), in particular
as regards their relationship to strings.  What I mean by this is that
you might say:
    :symbol is to "symbol" as 1 is to "1"

4.  Another possible section to include in your tutorial might actually
be a transition between the "What do they resemble in other languages?"
and "What are symbols?" sections:  "What else do they resemble in Ruby?"
This occurs to me mostly as a (perhaps better) place to put my
comparison of symbols to numbers:
    :symbol is to "symbol" as 1 is to "1"

5.  In the "What are symbols?" section, when you bring up the results of
:steve.to_i, you might consider mentioning that the integer to which a
symbol is translated will be different in one program than in another,
and that the reason for this is that Ruby is simply using this integer
to keep track of the symbol internally, so it's not a "random" number.
As a point of academic interest, this is because there's a hash table in
which Ruby keeps track of these things, essentially using integers as
keys by which it keeps track of symbols, though I'm not sure that's
something useful to an explanation of symbols at the level of this
tutorial.  In short, I think it's a good idea to mention something about
why :symbol.to_i produces an immutably set integer so that new Rubyists
won't start making assumptions about where the number arises and try to
use it improperly as a result.

6.  When you talk about capitalizing a string derived from a symbol, you
might also mention that you could, rather than using
:steve.to_s.capitalize, just use :Steve.  This is more in keeping with
the point of a symbol, I think, if your capitalized version isn't meant
to have a direct connection in the program logic to :steve itself.  If
it were me writing it, I might end up using an example that looks like
this, to demonstrate that from a program output perspective, both
approaches render the same result:
    #!/usr/bin/env ruby
    mystring = :steve.to_s.capitalize
    puts mystring
    puts :Steve

7.  I think you forgot a colon in "A symbol is not (Just) a Name".
Either that, or I didn't understand what you were trying to demonstrate.
You also seem to have forgotten a closing parenthesis in the same
section.  I might also suggest replacing the words "to hold" with "as",
when discussing the practical relationship between a symbol and a name,
since a symbol technically doesn't "hold" anything -- though I only
recommend the substitution, really, to forestall potential criticism.

8.  In "What can symbols do for you?" you might consider, in addition to
mentioning that you can create a string from one using .to_s, revisiting
the fact that a symbol is essentially treated as a string when used in a
string context (such as puts :symbol).

9.  In "What are the advantages and disadvantages of symbols?" you say
"The granddaddy of all advantages is also the granddaddy of
advantages:".  I don't get it, unless that was a typo.

10.  You might also mention another advantage of symbols, which pertains
more to metaprogramming than to the sort of programming with which most
programmers are familiar: symbols don't exist until you refer to them,
but when you do so, they spring into existence as though they had always
been there.  This allows for programming logic that acts almost like
time-travel, in that you can do something with a thing that acts like
it has always existed without having to create it before you use it, and
that thing can be any arbitrary thing at all, rather than having to be
part of some intrinsic language construct.  This is exactly the sort of
dynamism that makes Lisp (and, now, Ruby) so powerful.

11.  I'm sure you've noticed by now, but you might consider editing the
first sentence of the "Summary" to say that symbols prompted a thread of
"more than 100 posts" rather than saying it was a "97 post thread".

Hopefully you won't take any of this amiss.  Overall, I'm impressed with
the tutorial, and only recommend alterations because I'm pretty sure you
can handle it, and I would like to see your tutorial be the best it can
be.  Use or ignore the foregoing advice at your leisure, of course.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2005-12-31 00:28
(Received via mailing list)
On Dec 30, 2005, at 5:19 PM, Chad Perrin wrote:

> Note:  This reply is sent directly to you, not to the list.

It was sent to both, actually.

James Edward Gray II
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 00:28
(Received via mailing list)
On Sat, Dec 31, 2005 at 05:03:20AM +0900, Austin Ziegler wrote:
> itself.
That depends on how one understands the word "has" in this context.  For
instance, as you say, a symbol does not contain or consist of parts
including an integer and a string.  On the other hand, a symbol "has"
associated with it, if and when you place it within the correct context,
both a string and an integer.  The string association springs into being
when one uses .to_s, and the integer association exists because of the
hash table in which symbols are stored "behind the scenes".  Actually,
one might make a case for the string association existing from the word
go, but I have no idea how that could be explained succinctly.


>
> 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.

I'm afraid I disagree with the implication that what strings do from
Ruby's perspective is not useful information.  Simply saying that a
symbol is "something that represents itself" might explain it perfectly
to you, as it might to legions of (for instance) Python programmers used
to using names rather than variables, or whatever it is that Python
programmers do, but it clearly didn't help Steve or me very much.  This
indicates that another approach is needed, at least sometimes, and that
approach might involve an understanding of *why* symbols act the way
they do in context so that symbol behavior in code can be predicted when
one is writing said code.

. . . and please don't point out that symbols don't "do" anything, or
have any "behavior".  You (should) know what I mean from context.

--
Chad Perrin [ 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
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 00:31
(Received via mailing list)
On Sat, Dec 31, 2005 at 08:19:49AM +0900, Chad Perrin wrote:
> Note:  This reply is sent directly to you, not to the list.

Oops.

--
Chad Perrin [ 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
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 00:34
(Received via mailing list)
On Sat, Dec 31, 2005 at 08:26:02AM +0900, James Edward Gray II wrote:
> On Dec 30, 2005, at 5:19 PM, Chad Perrin wrote:
>
> >Note:  This reply is sent directly to you, not to the list.
>
> It was sent to both, actually.

Yeah, I noticed.  I'll go have my time-out in the corner now.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-31 01:37
(Received via mailing list)
On 30/12/05, Chad Perrin <perrin@apotheon.com> wrote:
>
> . . . and please don't point out that symbols don't "do" anything, or
> have any "behavior".  You (should) know what I mean from context.

Except that by trying to suggest that Symbols "act" a particular way
is nonsense. They don't do anything, they don't have any behaviour;
they just are simple names. In 99% of all uses of Symbols, that's
absolutely all that matters.

Do I *really* care that they're stored in Ruby on the internal symbol
table?

No. Not in the last two and a half years have I cared once. Sure, it's
nice that they only end up representing a single object, but I really
have never cared how they're represented. I use them for what they
*are*, not how they're implemented. And what they are, is names.

-austin
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 01:40
(Received via mailing list)
On Sat, Dec 31, 2005 at 09:37:00AM +0900, Austin Ziegler wrote:
> On 30/12/05, Chad Perrin <perrin@apotheon.com> wrote:
> >
> > . . . and please don't point out that symbols don't "do" anything, or
> > have any "behavior".  You (should) know what I mean from context.
>
> Except that by trying to suggest that Symbols "act" a particular way
> is nonsense. They don't do anything, they don't have any behaviour;
> they just are simple names. In 99% of all uses of Symbols, that's
> absolutely all that matters.

I'm guessing you either didn't read the preceding "you know what I mean"
statement, or you don't actually know what I mean, or you're being
intentionally combative.

--
Chad Perrin [ 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-31 01:46
(Received via mailing list)
On 30/12/05, Chad Perrin <perrin@apotheon.com> wrote:
> I'm guessing you either didn't read the preceding "you know what I mean"
> statement, or you don't actually know what I mean, or you're being
> intentionally combative.

No, I *didn't* know what you meant. I still don't. Talking about the
behaviour of Symbols is nonsense. Talking about the implementation of
Symbols is (mostly) nonsense. Talking about what Symbols provide
(immediate values that are self-descriptive, like enums or consts) is
NOT nonsense. Trying to say much else about Symbols is, again, mostly
nonsense.

-austin
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2005-12-31 01:46
(Received via mailing list)
Austin Ziegler wrote:
...

> Do I *really* care that they're stored in Ruby on the internal symbol table?
>
> No. Not in the last two and a half years have I cared once. Sure, it's
> nice that they only end up representing a single object, but I really
> have never cared how they're represented. I use them for what they
> *are*, not how they're implemented. And what they are, is names.


After trying to follow all this, I've come to see Symbols as being more
akin to numbers than strings.

They're numbers with a human face.


James
--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 03:20
(Received via mailing list)
On Sat, Dec 31, 2005 at 09:43:54AM +0900, Austin Ziegler wrote:
> > > absolutely all that matters.
> > I'm guessing you either didn't read the preceding "you know what I mean"
> > statement, or you don't actually know what I mean, or you're being
> > intentionally combative.
>
> No, I *didn't* know what you meant. I still don't. Talking about the
> behaviour of Symbols is nonsense. Talking about the implementation of
> Symbols is (mostly) nonsense. Talking about what Symbols provide
> (immediate values that are self-descriptive, like enums or consts) is
> NOT nonsense. Trying to say much else about Symbols is, again, mostly
> nonsense.

rephrase:
"the behavior of the language as regards the use of symbols"

Does that help?

Just replace all references to the behavior of symbols with whatever is
necessary, in your world-view, to map to the concept of what happens
when you use symbols in your source code.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 03:20
(Received via mailing list)
On Sat, Dec 31, 2005 at 09:46:00AM +0900, James Britt wrote:
>
> After trying to follow all this, I've come to see Symbols as being more
> akin to numbers than strings.
>
> They're numbers with a human face.

That's actually, from what I can see, a very good description -- though
for a complete newbie to the concept, you'd probably need to expand on
that a little bit.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-31 03:53
(Received via mailing list)
On 30/12/05, Chad Perrin <perrin@apotheon.com> wrote:
> rephrase:
> "the behavior of the language as regards the use of symbols"
>
> Does that help?
>
> Just replace all references to the behavior of symbols with whatever is
> necessary, in your world-view, to map to the concept of what happens
> when you use symbols in your source code.

Not really. I think James's description is pretty good, and agree that
it needs expansion. However, I don't think that the Ruby language
behaves in any particular way relating to Symbols or their use. I'm
not sure how to get it clearer than that. The Ruby language doesn't
really behave in a particular way with respect to Fixnums that impacts
most developers who *use* the language. The implementation has to deal
with them specially, and there are corner cases related to the current
implementation's use of 31 bits and the upsize and downsize between
BigDecimal, but that is, as I'm saying, an implementation issue and
not something I see as intrinsic to the language.

-austin
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 04:14
(Received via mailing list)
On Sat, Dec 31, 2005 at 11:50:27AM +0900, Austin Ziegler wrote:
> not something I see as intrinsic to the language.
Let me put it this way, then:  Why don't we remove symbols from the
language?

Once you answer that, I'll take your phrasing and fit it into what I was
saying, and this ridiculous back-and-forth wherein you refuse to
communicate effectively with me can end.

--
Chad Perrin [ 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2005-12-31 05:20
(Received via mailing list)
On 30/12/05, Chad Perrin <perrin@apotheon.com> wrote:
> > not something I see as intrinsic to the language.
> Let me put it this way, then:  Why don't we remove symbols from the
> language?

Strictly speaking, I do not believe that there is a *need* for them in
the language as such. They are, after all, just immediate objects.
(Which, combined with a "native" constructor syntax, is perhaps the
only reason to make them part of the interpreter.) Aside from that,
however, if they didn't exist in the language, there would likely be
some similar concept created.

Ruby-the-language probably doesn't need them as much as
ruby-the-interpreter does. But they don't actually *do* anything
special within the language, so far as I can tell. I suggest you look
at it realistically, instead of wanting to make them into something
they aren't.

> Once you answer that, I'll take your phrasing and fit it into what I was
> saying, and this ridiculous back-and-forth wherein you refuse to
> communicate effectively with me can end.

I'm communicating. You're just not listening. Effective communication
requires a willing listener, and you seem to be uninterested in such.

-austin
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2005-12-31 05:35
(Received via mailing list)
On 12/30/05, Austin Ziegler <halostatue@gmail.com> wrote:

> I'm communicating. You're just not listening. Effective communication
> requires a willing listener, and you seem to be uninterested in such.

I traded a few emails off list with Chad and he seems to basically be
only interested in telling everyone how wrong they are and how he
doesn't understand our 'inadequate' explanations.

Just killfile the annoying bastard, you've explained symbols great
already.

By the way, I'm currently working on a sort of abstract document class
for Ruport that will let you use XML, YAML or pure ruby to set up a
structured document and then output it as a PDF using your library, or
in other formats.

I thought you might find that interesting.  Ruport will soon depend on
PDF::Writer, as I'm going to begin putting some major PDF support to
it.  If i make any progress in the way of things that can be
generalized down and put into PDF::Writer (such as charts), I'll let
you know.

Any word on the SVG status in PDF::Writer?

Cheers,
Greg
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2005-12-31 05:50
(Received via mailing list)
On 12/30/05, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> On 12/30/05, Austin Ziegler <halostatue@gmail.com> wrote:
>
> > I'm communicating. You're just not listening. Effective communication
> > requires a willing listener, and you seem to be uninterested in such.
>
> I traded a few emails off list with Chad and he seems to basically be
> only interested in telling everyone how wrong they are and how he
> doesn't understand our 'inadequate' explanations.
[further private conversation snipped]

You guys really need to watch it when you hit reply.

Also, could we for goodness sakes let this thread die?!? Please?!?

Ryan
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2005-12-31 06:05
(Received via mailing list)
Ryan Leavengood wrote:
>>doesn't understand our 'inadequate' explanations.
>
> [further private conversation snipped]
>
> You guys really need to watch it when you hit reply.
>
> Also, could we for goodness sakes let this thread die?!? Please?!?

Recent threads (here and elsewhere) considered, 2006 can't come soon
enough; time to start fresh.


Happy Hacking New Year!


James


--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2005-12-31 06:08
(Received via mailing list)
On 12/30/05, Ryan Leavengood <leavengood@gmail.com> wrote:
> On 12/30/05, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> > On 12/30/05, Austin Ziegler <halostatue@gmail.com> wrote:
> >
> > > I'm communicating. You're just not listening. Effective communication
> > > requires a willing listener, and you seem to be uninterested in such.
> >
> > I traded a few emails off list with Chad and he seems to basically be
> > only interested in telling everyone how wrong they are and how he
> > doesn't understand our 'inadequate' explanations.

> You guys really need to watch it when you hit reply.

Whoa! Sorry about that.  That's twice in one day for me :(
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 06:08
(Received via mailing list)
On Sat, Dec 31, 2005 at 01:19:37PM +0900, Austin Ziegler wrote:
>
> I'm communicating. You're just not listening. Effective communication
> requires a willing listener, and you seem to be uninterested in such.

My point exactly: I used sloppy phrasing to try to get a point across,
made sure I identified it as sloppy phrasing, and you've done everything
in your power to nitpick my phrasing rather than grok my meaning.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

print substr("Just another Perl hacker", 0, -2);
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2005-12-31 06:11
(Received via mailing list)
On Sat, Dec 31, 2005 at 01:34:26PM +0900, Gregory Brown wrote:
>
> I traded a few emails off list with Chad and he seems to basically be

Funny, I don't recall receiving said off-list emails.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

print substr("Just another Perl hacker", 0, -2);
Ace7fa5337acbdf5897a6fc035897580?d=identicon&s=25 J. Ryan Sobol (Guest)
on 2005-12-31 06:36
(Received via mailing list)
Please end this thread, for the sake of all things good and decent.

~ ryan ~
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2005-12-31 06:45
(Received via mailing list)
On 12/31/05, J. Ryan Sobol <ryansobol@gmail.com> wrote:
> Please end this thread, for the sake of all things good and decent.

Agreed.  I apologize for throwing fuel on the fire accidentally.

If nothing else, the difference between "foo" and :foo has been
answered.

Let's all be friends ;)
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2005-12-31 06:48
(Received via mailing list)
On 12/31/05, Chad Perrin <perrin@apotheon.com> wrote:
> On Sat, Dec 31, 2005 at 01:34:26PM +0900, Gregory Brown wrote:
> >
> > I traded a few emails off list with Chad and he seems to basically be
>
> Funny, I don't recall receiving said off-list emails.

Look back through this thread, a few of my messages were sent just to
you and not to the list.  The post to Austin was also meant to be
private.  Okay, I'm done with this thread now :)

Happy new year, all
C3274d0d109830f7f5121a7d8f7ead98?d=identicon&s=25 Malte Milatz (Guest)
on 2005-12-31 12:27
(Received via mailing list)
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
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 Ross Bamford (Guest)
on 2005-12-31 12:39
(Received via mailing list)
On Fri, 30 Dec 2005 13:05:48 -0000, Malte Milatz
<malte__@gmx-topmail.de>
wrote:

> 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?
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2005-12-31 14:30
(Received via mailing list)
Malte Milatz <malte__@gmx-topmail.de> writes:

> 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.

In the current implementation, no.  It doesn't matter to the
programmer, though.
C3274d0d109830f7f5121a7d8f7ead98?d=identicon&s=25 Malte Milatz (Guest)
on 2005-12-31 18:44
(Received via mailing list)
Christian Neukirchen:
> Malte Milatz:
>> 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.
> In the current implementation, no.  It doesn't matter to the programmer,
> though.

I'm happy I'm not forced to dig into the details of Ruby's immediate
values...

Malte
8c29c0373ef64e5c3a607d8a961439b6?d=identicon&s=25 unknown (Guest)
on 2005-12-31 21:15
(Received via mailing list)
Steve Litt wrote:
> 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).

I'm somewhat new to ruby, and for me it has made most sense to do an ri
on Symbol to check out the api.  When I first ran across symbols in the
Pickaxe it didn't make much sense.  I started out just taking it on
blind faith how they get used in different frameworks api's.  Seems
like what symbols are is different from how they might be best used.
Here's something I wrote up to play around with how they work.  I was
surprized to find out that any identifier (class, method, variable,
etc) in a ruby script gets turned into a symbol.

Bill

# Definition: A symbol is an object of class Symbol.  The symbol
# has only one instance with given name that can be found by
# calling the method id2name or to_s.  The symbol has a unique
# integer value that can be found by calling  the to_i method.
# The Symbol class method all_symbols will give an array of all
# symbols.  A symbol is automatically generated for any
# identifier used or seen within a ruby program including
# constants, classes, methods, variables, etc.  Once a symbol is
# created it is never garbage collected.

def find_and_display_symbol(symbol_name)
  found_symbol = Symbol.all_symbols.find { |s| s.to_s == symbol_name }
  if (found_symbol != nil)
    puts "symbol found with name: #{found_symbol.to_s} and " +
         "id: #{found_symbol.to_i}\n\n"
  else
  	puts "unable to find symbol #{symbol_name}\n\n"
  end
end

# create a symbol object called symbol_name
:my_new_symbol

# display the newly created symbol by going through all symbols
# see find_and_display_symbol function below
find_and_display_symbol('my_new_symbol')

# symbols apparently don't have to be a legal identifier
:"Hello World!"
find_and_display_symbol("Hello World!")

#local variable creates a symbol
silly_local_variable = "Hello"
find_and_display_symbol('silly_local_variable')

# Any referenced identifier will create a symbol, even if the symbol is
# undefined:
defined? undefined_variable
find_and_display_symbol('undefined_variable')

# Symbols already exist for builtin classes and methods
find_and_display_symbol('String')
find_and_display_symbol('each')
find_and_display_symbol('$LOAD_PATH')

# list all symbols
sym_array = Symbol.all_symbols
sym_array.sort! {|a,b| a.to_s <=> b.to_s }
sym_array.each {|s| puts "name: #{s.to_s} id: #{s.to_i}\n" }
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 Ross Bamford (Guest)
on 2005-12-31 21:54
(Received via mailing list)
On Sat, 31 Dec 2005 20:10:13 -0000, <Bill.Dolinar@gmail.com> wrote:

>
> # Definition: A symbol is an object of class Symbol.  The symbol
> # has only one instance with given name that can be found by
> # calling the method id2name or to_s.  The symbol has a unique
> # integer value that can be found by calling  the to_i method.
> # The Symbol class method all_symbols will give an array of all
> # symbols.  A symbol is automatically generated for any
> # identifier used or seen within a ruby program including
> # constants, classes, methods, variables, etc.  Once a symbol is
> # created it is never garbage collected.
>

S'funny, my RI says:

      +Symbol+ objects represent names and some strings inside the Ruby
      interpreter. They are generated using the +:name+ and +:"string"+
      literals syntax, and by the various +to_sym+ methods. The same
      +Symbol+ object will be created for a given name or string for the
      duration of a program's execution, regardless of the context or
      meaning of that name. Thus if +Fred+ is a constant in one context,
      a method in another, and a class in a third, the +Symbol+ +:Fred+
      will be the same object in all three contexts.

But anyway,

> # create a symbol object called symbol_name
> #local variable creates a symbol
> find_and_display_symbol('each')
> find_and_display_symbol('$LOAD_PATH')
>
> # list all symbols
> sym_array = Symbol.all_symbols
> sym_array.sort! {|a,b| a.to_s <=> b.to_s }
> sym_array.each {|s| puts "name: #{s.to_s} id: #{s.to_i}\n" }
>

Hey, that could be a good basis for a nuby file for my collection
(http://roscopeco.co.uk/code/noob), maybe as part of an expanded version
of the existing syms-methods thing (which isn't too hot anyway to be
honest). Mind me doing that?

Cheers,
06c1bab0fb222c7426c02887cd728936?d=identicon&s=25 Johannes Friestad (Guest)
on 2006-01-01 04:09
(Received via mailing list)
> did
>    a, b = 4, 4
> 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?

The 'pass by reference/value' terminology isn't used much in Ruby (or
in Smalltalk, Java, Python...), from the programmer's point of view
there's only one type of assignment and parameter passing.

But technically, a variable can hold either a reference to an object
or an immediate value. All normal objects are assigned by reference,
so in
a=Object.new
or
a="some string"
'a' holds a reference. The reference is a pointer to the object's
location in memory.

Fixnums and a few other special types (symbols, true/false/nil,
floats?) are assigned as immediate values: Instead of storing a
pointer (or reference) to the value object, the variable stores the
value directly. So in
a=4
'a' does not hold a reference, technically speaking, but rather the
immediate value 4.
This is an implementation issue, and is done for efficiency.

But the difference is largely transparent to the programmer, so I
guess it's mostly of interest to those who want to know how the
language works behind the scenes.

jf
8c29c0373ef64e5c3a607d8a961439b6?d=identicon&s=25 unknown (Guest)
on 2006-01-01 06:00
(Received via mailing list)
Not at all.  Use whatever parts you would like.

Bill
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-01-01 10:25
(Received via mailing list)
James Britt wrote:
>
> After trying to follow all this, I've come to see Symbols as being more
> akin to numbers than strings.
>
> They're numbers with a human face.
>

Thanks, James. That's great.

Incidentally, I was out of town for over a week, so I have just now
read (most of) this 100+ post thread in a single sitting. This is
not an experience I recommend.

I had to reply here, though I held back many times.

If you are an old enough user of Ruby, you remember when a symbol
"really was" a number. There was no Symbol class. If you did a
puts of :foo, you got a number out. :foo could be added to another
number, and basically always acted like a number.

I'm assuming that this number was just the index into a list of
symbols, enabling us to get the string representation back given
the symbol (number).

Anyway, happy new year! This is my first post of 2006.


Hal
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-01 10:31
(Received via mailing list)
On 1/1/06, Hal Fulton <hal9000@hypermetrics.com> wrote:
> Incidentally, I was out of town for over a week, so I have just now
> read (most of) this 100+ post thread in a single sitting. This is
> not an experience I recommend.
>
> I had to reply here, though I held back many times.
>
> If you are an old enough user of Ruby, you remember when a symbol
> "really was" a number. There was no Symbol class. If you did a
> puts of :foo, you got a number out. :foo could be added to another
> number, and basically always acted like a number.

That's interesting.  What version did the Symbol class get added in?
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-01-01 10:37
(Received via mailing list)
Gregory Brown wrote:
>>Thanks, James. That's great.
>>number, and basically always acted like a number.
>
>
> That's interesting.  What version did the Symbol class get added in?
>

I'm not certain. I guess it was 1.6.


Hal
C6eb5252ee440a2bde0339f2caf614ca?d=identicon&s=25 szpak (Guest)
on 2006-01-01 20:30
(Received via mailing list)
A symbol in Ruby is similar to a symbol in Lisp in that the symbol is a
name, or more precisely a named atom which can also respond to a
request to expose itself as a number (to_i) or a string (to_s). In this
case a Ruby symbol is similar to a Lisp keyword symbol (which is also
prefixed by a colon (:), at least in some versions of Lisp). However,
in Lisp a symbol has much greater functionality. For example, a Lisp
symbol can also be bound to a value, a property list, or a function.

In briefest, my understanding of symbol in Ruby is that it is an
interned string used as a name ("interned" meaning that it is entered
into memory as a single, atomic entity, a monad - there is just one of
it, with a single pointer to it).
4fea1ef11180adaaa299d503ca6010d0?d=identicon&s=25 John W. Kennedy (Guest)
on 2006-01-01 20:33
(Received via mailing list)
James Britt wrote:
>
>
> After trying to follow all this, I've come to see Symbols as being more
> akin to numbers than strings.
>
> They're numbers with a human face.

In some ways, a comparison with interned strings in Java can be helpful.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-02 00:26
(Received via mailing list)
Hi --

On Sun, 1 Jan 2006, Malte Milatz wrote:

> values...
It's actually not that complex -- basically:

   a = "string" # a contains a reference to that string
   a = 1        # a contains the actual (immediate) value 1

("string" itself is a literal string.)

I think that Fixnums, Symbols, true, false, and nil are the only
objects that appear in variables as immediate values.  Most of the
time you're dealing with references.

In practical terms, it doesn't normally matter too much.  You always
use the same syntax for sending messages to objects through variables,
whether the variable contains a reference or an immediate value.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-02 01:21
(Received via mailing list)
On 1/1/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

> It's actually not that complex -- basically:

I decided to throw up some examples for those who like examples.

>    a = "string" # a contains a reference to that string

irb(main):007:0> a = "foo"
=> "foo"
irb(main):008:0> b = "foo"
=> "foo"
irb(main):009:0> c = "foo"
=> "foo"
irb(main):010:0> a.object_id
=> -605890256
irb(main):011:0> b.object_id
=> -605898166
irb(main):012:0> c.object_id
=> -605912906

>    a = 1        # a contains the actual (immediate) value 1

 irb(main):001:0> a = 1
=> 1
irb(main):002:0> b = 1
=> 1
irb(main):003:0> c = 1
=> 1
irb(main):004:0> a.object_id
=> 3
irb(main):005:0> b.object_id
=> 3
irb(main):006:0> c.object_id
=> 3


> ("string" itself is a literal string.)

But keep in mind, "string" is not an immediate value.

irb(main):013:0> "string".object_id
=> -605956386
irb(main):014:0> "string".object_id
=> -605962596

Symbols, OTOH, are: (Seeing as they're just named numbers :))
irb(main):015:0> :my_sym.object_id
=> 4073742
irb(main):016:0> :my_sym.object_id
=> 4073742

Hope these examples help.
This topic is locked and can not be replied to.