Re: General hash keys for colon notation

Hi --

On Sun, 28 Oct 2007, murphy wrote:

> Dear language designer(s) and parser wizards,
>
> can we allow hash literals like {1:2, 3:4, 5:6} (for numbers, or even
> better, for general keys)? I think that would be the best replacement
> for the old list notation. my guess is that people are using the
> following types of keys most (sorted by importance):
> - Symbols
> - Strings
> - Special objects (not containers)
> - Fixnums
> - constants (eg. classes)
> - (who uses containers for keys? yugh!)
>
> I'd love Ruby 1.9 to allow the following:
>
> Symbols:  { foo: 23, bar: 42 }  (already supported in 1.9)
>
> Strings:  { 'foo': 23, 'bar': 42 }  (used a lot)
>
> Numbers:  { 1:1, 3:9, 2:4 }  (shortcut, looks like a multiset)
>
> Objects: typically given as variables. Tricky, because if foo is a local
> variable, { foo: 3 } would be ambiguous. So we need parentheses:
>
>  foo = Foo.new 313
>  { default: 0, (foo): 'Hash me!', (Math::PI): 3.14 }

I think it's much more straightforward just to say: foo => 'Hash me!'.
After all, => is already there as a generalized hash separator; I
don't think (): adds anything. (I'm still hoping that the => for
lambda will go away before 1.9.1....)

> That would of course allow basically everything:
>
>  { (/default/): 0, (()): (()), ({a:0}):0, ([1,2,3])::a,
>    (ENV.keys.map(&:upcase)): :":", (foo): 7, (Foo): 7, foo: 7 }
>
> but the classic => notation also allows this:
>
>  { /default/ => 0, () => (()), {:a=>0} => 0, [1,2,3] => :a,
>    ENV.keys.map(&:upcase) => :":", foo => 7, Foo: 7, :foo => 7 }
>
> Another solution would be just to handle keys that look like identifiers
> (local variables, methods and constants) special and interpret them as
> Symbols, and make the colon an alternative to => for everything else.
> you only have to use parentheses around local variables and constants then:
>
>  { /default/: 0, (): (()), {a:0}:0, [1,2,3]::a,
>    ENV.keys.map(&:upcase): :":", (foo): 7, (Foo): 7, foo: 7 }
>
> (code golfers, cheer!)

Line noise fans, likewise :-)  Sorry, but that really is the first
thing that springs to mind. (): (()) for nil => nil is not my cup of
tea. (It actually looks remarkably like a left-rotated Fred Flintstone
in my font, which is kind of cool, but it's not very nice-looking as
Ruby code.)

> Since the current implementation even allows => and : to be mixed in a
> literal, it seems already to be smart enough to parse everything up to
> the colon:
>
>  SyntaxError: (irb):10: parse error, expecting `tASSOC'
>  { {a: 3}: 3}
>           ^
>
> So, are there design or technical reasons not to allow general hask keys
> in the new colon notation?
>
> (or am I asking an old question that can be answered with a link?)

I would argue (strongly) against it on style grounds. I don't know
about the parsing.


David

-- 
Upcoming training by David A. Black/Ruby Power and Light, LLC:
   * Advancing With Rails, Edison, NJ, November 6-9
   * Advancing With Rails, Berlin, Germany, November 19-22
   * Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!