Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

unifying hash and proc syntax

0 views
Skip to first unread message

Joel VanderWerf

unread,
Mar 22, 2005, 12:02:12 AM3/22/05
to
Hey, crazy idea. Why not use the same syntax for hashes and arrays? For
example:

{
1 => 2,
2 => 3,
3 => 4,
|x|
x + 1
}

This is essentially a hash with a default_proc that adds 1 to its argument.

Leave out the => pairs and you get something that acts like a proc.
Leave out the |...|... construct and you get something that acts like a
hash. With both, it's a hash with a default proc.

It's backwards compatible.

Are there any syntactic ambiguities?


Hal Fulton

unread,
Mar 22, 2005, 1:18:16 AM3/22/05
to
Joel VanderWerf wrote:
> Hey, crazy idea. Why not use the same syntax for hashes and arrays? For
> example:
>
> {
> 1 => 2,
> 2 => 3,
> 3 => 4,
> |x|
> x + 1
> }
>
> This is essentially a hash with a default_proc that adds 1 to its argument.
>
> Leave out the => pairs and you get something that acts like a proc.
> Leave out the |...|... construct and you get something that acts like a
> hash. With both, it's a hash with a default proc.

It's a fllor wax AND a dessert topping!

> It's backwards compatible.

Delicious! And just look at that shine!

> Are there any syntactic ambiguities?

Hmm, not sure. But it certainly gives me a headache to think about it.


Hal

Joel VanderWerf

unread,
Mar 22, 2005, 12:43:45 AM3/22/05
to
Joel VanderWerf wrote:
> Hey, crazy idea. Why not use the same syntax for hashes and arrays? For
^^^^^^
erm, procs


Csaba Henk

unread,
Mar 22, 2005, 1:57:51 AM3/22/05
to
On 2005-03-22, Joel VanderWerf <vj...@PATH.Berkeley.EDU> wrote:
> example:
>
> {
> 1 => 2,
> 2 => 3,
> 3 => 4,
> |x|
> x + 1
> }
>
> This is essentially a hash with a default_proc that adds 1 to its argument.

Witty! What's somewhat dubious in it is melting two things which are so
different as objects. A hash is basicly transparent, a proc is basicly
opaque. And an object which has a proc as an attribute in some sense
won't just become a proc...

But, hm, all-in-all, I like it. I always tend to think of hashes as
mappings defined at finitely many places, abstracting from the data
structure which implements it (and gives it its name).

Csaba

Robert Klemme

unread,
Mar 22, 2005, 10:25:54 AM3/22/05
to

"Berger, Daniel" <Daniel...@qwest.com> schrieb im Newsbeitrag
news:8FE83020B9E1A248A18...@itomae2km07.AD.QINTRA.COM...

> > -----Original Message-----
> > From: Joel VanderWerf [mailto:vj...@PATH.Berkeley.EDU]
> > Sent: Monday, March 21, 2005 10:02 PM
> > To: ruby-talk ML
> > Subject: unifying hash and proc syntax
> >
> >
> > Hey, crazy idea. Why not use the same syntax for hashes and
> > arrays?
>
> If Ruby had a "List" superclass from which Array and Hash descended,
> instead of the Enumerable mixin strategy, this would have been easier I
> think. Presumably (and I'm totally guessing here) a list would have
> been anything between square brackets:
>
> [1,2,3,4].kind_of?(List) # true
> [1,2,3,4].kind_of?(Array) # true
> [1,2,3,4].kind_of?(Hash) # false
>
> [1 => 2, 3 => 4].kind_of?(List) # true
> [1 => 2, 3 => 4].kind_of?(Hash) # true
> [1 => 2, 3 => 4].kind_of?(Array) # false
>
> (I believe someone else proposed this syntax earlier.)

Enumerable does serve the purpose of defining a common abstract interface
already. Note also, that lists are usually ordered and their elements
don't change positions unless explicit told to. This is not true for a
Hash - at least not as it's implemented right now. Personally I dislike
changing Hash to add the overhead of remembering insertion order as this
is likely to slow down Hash typical operations.

The other problem with a common superclass / mixin of Array and Hash is,
that sometimes you want them treated similar (i.e. both have [] and []=
and can be accessed indexed; you can view an Array as a specialized Hash
that allows only Fixnum keys) and sometimes you don't. I still haven't
seen something that would consolidate this better than Enumerable does.

> This is more along the path that Perl took, where hashes and arrays are
> both lists. Then the {} would then be free, FREE, to be used for
> whatever nefarious purposes we could devise.

The sole fact that you mention perl here makes the whole proposal
suspicious to me. :-) I'd rather find a ruby solution than to look at
other languages.

> Not being a language designer, I have no idea if this is better or
> worse, if the List superclass is really necessary (i.e. could we still
> use a mixin strategy?), or if it would even be possible to implement in
> Ruby 2.0.

Personally I don't think we really need this change. Just my 0.02EUR...

Kind regards

robert

Berger, Daniel

unread,
Mar 22, 2005, 10:06:37 AM3/22/05
to
> -----Original Message-----
> From: Joel VanderWerf [mailto:vj...@PATH.Berkeley.EDU]
> Sent: Monday, March 21, 2005 10:02 PM
> To: ruby-talk ML
> Subject: unifying hash and proc syntax
>
>
> Hey, crazy idea. Why not use the same syntax for hashes and
> arrays?

If Ruby had a "List" superclass from which Array and Hash descended,
instead of the Enumerable mixin strategy, this would have been easier I
think. Presumably (and I'm totally guessing here) a list would have
been anything between square brackets:

[1,2,3,4].kind_of?(List) # true
[1,2,3,4].kind_of?(Array) # true
[1,2,3,4].kind_of?(Hash) # false

[1 => 2, 3 => 4].kind_of?(List) # true
[1 => 2, 3 => 4].kind_of?(Hash) # true
[1 => 2, 3 => 4].kind_of?(Array) # false

(I believe someone else proposed this syntax earlier.)

This is more along the path that Perl took, where hashes and arrays are


both lists. Then the {} would then be free, FREE, to be used for
whatever nefarious purposes we could devise.

Not being a language designer, I have no idea if this is better or


worse, if the List superclass is really necessary (i.e. could we still
use a mixin strategy?), or if it would even be possible to implement in
Ruby 2.0.

Who knows? Maybe I'll learn to design a language someday and give this
a shot to see how it pans out. :)

Regards,

Dan


0 new messages