On Fri, Dec 30, 2005 at 01:36:05PM +0900, Eero S. 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.
- Implementation details.
Am I wrong?
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
print substr(“Just another Perl hacker”, 0, -2);
On Fri, Dec 30, 2005 at 02:10:09PM +0900, Yohanes S. wrote:
Chad P. [email protected] 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 P. [ CCD CopyWrite | http://ccd.apotheon.org ]
“Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts.” - Paul Graham
On Dec 30, 2005, at 12:45 AM, Austin Z. 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 W.
On Fri, Dec 30, 2005 at 01:42:39PM +0900, [email protected] 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 P. [ CCD CopyWrite | http://ccd.apotheon.org ]
print substr(“Just another Perl hacker”, 0, -2);
On Fri, Dec 30, 2005 at 03:01:34PM +0900, Devin M. 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 P. [ CCD CopyWrite | http://ccd.apotheon.org ]
This sig for rent: a Signify v1.14 production from
On Dec 30, 2005, at 2:44 AM, Chad P. 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 W.
On 12/30/05, Chad P. [email protected] 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.
On Fri, Dec 30, 2005 at 05:18:46PM +0900, Gregory B. 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 P. [ CCD CopyWrite | http://ccd.apotheon.org ]
“A script is what you give the actors. A program
is what you give the audience.” - Larry Wall
On 12/30/05, Chad P. [email protected] 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
On Fri, Dec 30, 2005 at 05:17:43PM +0900, [email protected] 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 P. [ 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.
Steve L. [email protected] 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). 
On Thursday 29 December 2005 07:36 pm, Chad P. 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 L.
Hi –
On Fri, 30 Dec 2005, Eero S. 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
[email protected]
“Ruby for Rails”, from Manning Publications, coming April 2006!
On Friday 30 December 2005 08:06 am, Christian N. wrote:
Steve L. [email protected] 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 L.
On 30/12/05, [email protected] [email protected] wrote:
On Dec 30, 2005, at 12:45 AM, Austin Z. 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
On 30/12/05, Steve L. [email protected] 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
On Friday 30 December 2005 10:55 am, Austin Z. wrote:
It’s not that different from Perl
barewords.
I plead ignorance on Perl barewords. I use “use strict” every time.
SteveT
Steve L.
Steve L. [email protected] 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.
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
On 12/30/05, Christian N. [email protected] 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 C. gives a good
explanation of Ruby Symbols in his article Understanding Ruby
Symbols
http://glu.ttono.us/articles/2005/08/19/understanding-ruby-symbols
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
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs