True -- I fudged the facts a little bit. I should have done that
differently.
···
On Thu, Mar 08, 2007 at 02:55:34PM +0900, Gary Wright wrote:
On Mar 8, 2007, at 12:46 AM, Chad Perrin wrote:
>You might also differentiate by pointing out that string
>literals are not necessarily unique, while symbols are -- duplicate
>string literals may be stored in several different variables at once.
This doesn't sound right to me. String literals are part of the
source code. They aren't stored in variables at all (let's just
agree to ignore eval for the moment).
And a single symbol can be represented by several different literals:
:alpha, :'alpha', :"alpha"
So you have to be careful about talking about unique literals.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
True -- which brings it back to the "strings are fleeting" thing.
Thus, the comment in my previous email about symbols being kind of like
string literals, except that they are persistent. Because strings are
fleeting, they're actually different incidences of a string every time
they're evaluated.
···
On Thu, Mar 08, 2007 at 04:02:02PM +0900, Brian Candler wrote:
On Thu, Mar 08, 2007 at 02:46:43PM +0900, Chad Perrin wrote:
> On Thu, Mar 08, 2007 at 04:21:10AM +0900, Bharat Ruparel wrote:
> > I think of symbols is immutable strings that are useful only in
> > referring to some values? Seems like a nice way for using pointers
> > without all the warps?
>
> "Immutable strings" doesn't work so well, since a string literal is
> "immutable" anyway.
Well maybe that's technically right, in the sense that the source code
itself is immutable. However, every time a string literal is 'executed' a
new, mutable string object is instantiated:
5.times { puts "hello".object_id }
So there's no way in practice to make use of the 'immutable' property you
describe, because every String object your program sees is mutable.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors. A program
is what you give the audience." - Larry Wall
I like to use this analogy too. An integer has a string
representation, which is what is embedded in the code as a literal.
This string representation is not actually the integer, but every
integer corresponds to a unique string of digits, and if you use the
same string twice in your code, you're referring to the same integer.
martin
···
On 3/8/07, David A. Black <dblack@wobblini.net> wrote:
I'll add yet another way of thinking about symbols, namely that they
are very integer-like. All of the immutable, unique, immediate-value
stuff is not so much a modification of how strings behave as a rather
exact replication of how integers behave.
As Obi-wan Kenobi would say, "that's (only) true from a certain point of view."
irb(main):002:0> :a + :b
NoMethodError: undefined method `+' for 
Symbol
from (irb):2
···
On 3/8/07, David A. Black <dblack@wobblini.net> wrote:
Hi --
On 3/8/07, Gary Wright <gwtmp01@mac.com> wrote:
>
> On Mar 8, 2007, at 12:41 AM, Chad Perrin wrote:
> > Obviously, a symbol is different in easily explained ways from string
> > variables, without having to drag implementation into it. Things
> > aren't
> > quite so clear-cut between symbols and string *literals*, though.
>
> I'm not sure that the problem you are describing has anything to do with
> symbols. Anyone learning Ruby is going to have to understand the
> difference between "1", 1, 1.0, /1/, and :1. Symbol literals
> aren't really special in this regard.
I'll add yet another way of thinking about symbols, namely that they
are very integer-like. All of the immutable, unique, immediate-value
stuff is not so much a modification of how strings behave as a rather
exact replication of how integers behave.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
And a single symbol can be represented by several different literals:
:alpha, :'alpha', :"alpha"
So you have to be careful about talking about unique literals.
It's a pity you can't do this, though.
muppet = "kermit"
=> "kermit"
:kermit
=> :kermit
:"kermit"
=> :kermit
:#{muppet}
?> ;
?> end
SyntaxError: compile error
(irb):5: syntax error, unexpected ';', expecting tSTRING_CONTENT or
tSTRING_DBEG or tSTRING_DVAR or tSTRING_END
from (irb):6
Although I admit, wanting to do it in the first place, that's probably
just the Perl monkey in me. Besides, this works fine:
muppet.to_sym
=> :kermit
···
--
Giles Bowkett
http://www.gilesgoatboy.org
http://giles.tumblr.com/
Giles Bowkett wrote:
It's a pity you can't do this, though.
:"kermit"
=> :kermit
:#{muppet}
Silly rabbit.
>> :"#{muppet}"
=> :kermit
hahahaha
duh, whoops.
Well, just so I can say I contributed something to this discussion
other than my own brainlessness, I was just going through "Programming
Ruby" out of boredom and ran into this:
"Other languages...call symbols atoms." (pg 308 in what I think is edition 2)
Seems like an endorsement of the Lisp interpretation, although going
to that kind of trouble seems very un-Lispy.
···
On 3/8/07, Devin Mullins <twifkak@comcast.net> wrote:
Giles Bowkett wrote:
> It's a pity you can't do this, though.
>>> :"kermit"
>
> => :kermit
>
>>> :#{muppet}
Silly rabbit.
>> :"#{muppet}"
=> :kermit
--
Giles Bowkett
http://www.gilesgoatboy.org
http://giles.tumblr.com/
