From: Matthew Kerwin <matthew@...>
Date: 2012-06-20T08:36:52+09:00
Subject: Re: Symbols and Strings.

On 20 June 2012 02:58, Dan Connelly <lists@ruby-forum.com> wrote:
> I've liked the distinction between symbols and strings since I first
> encountered it in LISP.   Symbols to me are abstract entities which
> happen to be typically represented with characters, while strings are
> explicitly series of characters.  With this perspective, it makes sense
> that "b" > "a", but :b > :a gives an error, and :a + :b gives an error.
> If symbols became immutable strings, this distinction would be lost.
>
> But in the end, the proof is in the code.  I suspect functionally
> there'd not be much difference, but I'm just a beginner.

I'm pretty sure I'm not a beginner (although programming changes so
fast it's almost impossible to be old-hat in anything relevant) but I
agree pretty much in whole with what you're saying.  In a
compiled/pre-parsed/JIT environment there _could_ be a dramatic
difference between symbols and immutable strings – symbols could
easily be replaced with some enumerator type, or integers, or even
completely optimised away, depending on context.

To my way of thinking symbols, when they're called symbols, are
"valueless data" – their worth is in their name. Immutable strings
_do_ contain valuable data, even if you're not allowed to modify it.
(If that wasn't the case, Java would be an even harder place to get
anything useful done.)

By extension I'd argue that a symbol is atomic; the whole name is
valuable, but no part of it is.  As such an .each_char iterator could
make perfect sense for an immutable string, but not for a symbol.

I always thought the :"foo" syntax was handy (for :"foo#{bar}baz"
cases), but it only ever served to confuse the issue for me.
Personally I tend to use String#to_sym for those cases that I want to
dynamically generate a symbol; it's an explicit cast, and provides a
clear boundary between "creating the name" and then "using it".  Note:
it may be more or less optimal at runtime to do it this way, but I
don't care; I'm after maintainability and easing my own understanding
here.

I should get back to work.
-- 
  Matthew Kerwin, B.Sc (CompSci) (Hons)
  http://matthew.kerwin.net.au/
  ABN: 59-013-727-651

  "You'll never find a programming language that frees
  you from the burden of clarifying your ideas." - xkcd