Rick,

Aren't we confusing symbol with operator in this discussion. If I am 
dealing
with a program as a string or group of strings, as any compiler 
initially must,
not having symbols as a part of strings makes my initial task almost 
impossible.

Everett L.(Rett) Williams II

Rick DeNatale wrote:
> On 5/12/07, Trans <transfire / gmail.com> wrote:
>
>>
>> There are a number of advantages to sub-classing that I can think of:
>>
>>   1)  No need to do x.to_s.some_string_method.to_sym
>
> Well, let's see. Why do we do symbol.to_s ?
>
>    1). When we want a string representation of the symbol so that we
> can say mutate it.  Subclassing won't help here.
>    2) If we want to compare a string with a symbol.  Making Symbol a
> subclass of string alone won't do this, and if we change Symbol#== so
> that :a == "a" is true we destroy one of big advantages of Symbols
> which is the speed of determining that two symbols are equal based on
> their identity, this is why, for example, symbols rather than strings
> are used as method selectors.
>
> And why do we do string.to_sym, primarily because we want the speed
> advantages of symbols in comparisons.
>
>>   2)  Hash keys could efficiently equate symbol and string keys (it's
>> the distinction that should be optional)
>
> No I think that we'd actually get the worst here, it falls out of #2
> above.  Symbol hash keys are more efficient than String hash keys
> because of identity.
>
>
>>   3)  It's conceptually simpler: a Symbol is an immutable String.
>   No it isn't. A symbol is an object with an immutable string as a
> name, and which is the sole instance with that name.
>
> Now an interesting idea might be to add more string methods to Symbol
> so that for example one could do
>
>   :a + :b #=> :ab
>
> So that there was more of a Symbol algebra which was still closed so
> that the results were still Symbols.
>