OK... :) question about hash and array literals

ruby-talk
1

It has always bothered me a little that [...] and {...} do not
call Array.new and Hash.new respectively.

I assume this is handled closer to parse time, for speed?

Is there a method that does get called (I think not), or could
in theory such a thing be implemented?

Example:

   class Hash
     def Hash.literal(*pairs)
       pairs.each do |pair|
         k, v = pair
         puts "Adding key #{k}, value #{v}"
       end
       super # or whatever
     end
   end

   x = {1=>2, 3=>4} # Output: Adding key 1, value 2
                       # Adding key 3, value 4

And yes, this is related again to my wanting an ordered arbitrarily
indexable collection with a convenient literal notation.

Just curious...

Hal

2

Hi,

Is there a method that does get called (I think not), or could
in theory such a thing be implemented?

Not planned, just because changing semantics of literals are too
dangerous, as dangerous as macros for my eyes.

              matz.

p.s.
I'm thinking of preserving Hash order by not re-implement it by using
Tree or something, but by saving key order information along with hash
tables.

···

In message "Re: OK... :slight_smile: question about hash and array literals" on Sat, 4 Sep 2004 12:54:52 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

3

"Hal Fulton" <hal9000@hypermetrics.com> schrieb im Newsbeitrag
news:41393C84.9090002@hypermetrics.com...

It has always bothered me a little that [...] and {...} do not
call Array.new and Hash.new respectively.

I assume this is handled closer to parse time, for speed?

Is there a method that does get called (I think not), or could
in theory such a thing be implemented?

Example:

   class Hash
     def Hash.literal(*pairs)
       pairs.each do |pair|
         k, v = pair
         puts "Adding key #{k}, value #{v}"
       end
       super # or whatever
     end
   end

   x = {1=>2, 3=>4} # Output: Adding key 1, value 2
                       # Adding key 3, value 4

And yes, this is related again to my wanting an ordered arbitrarily
indexable collection with a convenient literal notation.

Even if a ordered map would be added you would not want to change literals
default behavior. Too much code depends on this. I remember, we had a
similar discussion with String literals a while ago. See also my post in
the other thread.

Kind regards

    robert

4

Hi --

···

On Sat, 4 Sep 2004, Yukihiro Matsumoto wrote:

Hi,

In message "Re: OK... :slight_smile: question about hash and array literals" > on Sat, 4 Sep 2004 12:54:52 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

>Is there a method that does get called (I think not), or could
>in theory such a thing be implemented?

Not planned, just because changing semantics of literals are too
dangerous, as dangerous as macros for my eyes.

This is just a thought (not even an "idea" :slight_smile: but what about a
%-style constructor:

  %H{ k1 => v1, k2 => v2, ... }

or something.

David

--
David A. Black
dblack@wobblini.net

5

Yukihiro Matsumoto wrote:

Hi,

>Is there a method that does get called (I think not), or could
>in theory such a thing be implemented?

Not planned, just because changing semantics of literals are too
dangerous, as dangerous as macros for my eyes.

              matz.

p.s.
I'm thinking of preserving Hash order by not re-implement it by using
Tree or something, but by saving key order information along with hash
tables.

Yes, that is what I was thinking. That would also be the smallest impact
on the internals.

However, if order in literals is irrelevant, then hashes are not truly
ordered entities, are they?

See my other post about a [=>] notation... not an ideal solution perhaps,
but does preserve hash literals as they are.

Hal

···

In message "Re: OK... :slight_smile: question about hash and array literals" > on Sat, 4 Sep 2004 12:54:52 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

6

David A. Black ha scritto:

Hi --

Hi,

Is there a method that does get called (I think not), or could
in theory such a thing be implemented?

Not planned, just because changing semantics of literals are too
dangerous, as dangerous as macros for my eyes.

This is just a thought (not even an "idea" :slight_smile: but what about a
%-style constructor:

  %H{ k1 => v1, k2 => v2, ... }

please no.
This is just my very little unvaluable opinion, but %-stuff literals are one of the few things I don't like about ruby.
Nothing is telling me what they mean, It's something a user can't have control over and there are subtle differencies beetween one and another that are just... well.. _too_ subtle.

But as I write I'm getting the idea you're suggesting overridable % constructors? If that is the suggestion.. well, interesting :slight_smile:

···

On Sat, 4 Sep 2004, Yukihiro Matsumoto wrote:

In message "Re: OK... :slight_smile: question about hash and array literals" >> on Sat, 4 Sep 2004 12:54:52 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

7

David A. Black wrote:

Is there a method that does get called (I think not), or could
in theory such a thing be implemented?

Not planned, just because changing semantics of literals are too
dangerous, as dangerous as macros for my eyes.

This is just a thought (not even an "idea" :slight_smile: but what about a
%-style constructor:

  %H{ k1 => v1, k2 => v2, ... }

or something.

Good idea, though I shy away from changing syntax more than I
shy away from changing and adding classes.

I was thinking something similar, now that you mention it: An array-like
notation with hash-like arrows inside:

    x = {1=>2, 3=>4} # hash
    y = [3,4] # array
    z = [1=>2, 3=>4] # ordered association

Is this reasonable at all? Matz??

Hal

···

In message "Re: OK... :slight_smile: question about hash and array literals" >> on Sat, 4 Sep 2004 12:54:52 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

8

Hi,

···

In message "Re: OK... :slight_smile: question about hash and array literals" on Sun, 5 Sep 2004 01:38:42 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

However, if order in literals is irrelevant, then hashes are not truly
ordered entities, are they?

My opinion is preserving order reduces some "pitfalls". Reducing
pitfalls is a good thing. To be honest, I don't care whether Hash
being "true" ordered entity or not.

              matz.

9

Hi --

···

On Sat, 4 Sep 2004, gabriele renzi wrote:

David A. Black ha scritto:

> Hi --
>
> On Sat, 4 Sep 2004, Yukihiro Matsumoto wrote:
>
>
>>Hi,
>>
>>In message "Re: OK... :slight_smile: question about hash and array literals" > >> on Sat, 4 Sep 2004 12:54:52 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:
>>
>>>Is there a method that does get called (I think not), or could
>>>in theory such a thing be implemented?
>>
>>Not planned, just because changing semantics of literals are too
>>dangerous, as dangerous as macros for my eyes.
>
>
> This is just a thought (not even an "idea" :slight_smile: but what about a
> %-style constructor:
>
> %H{ k1 => v1, k2 => v2, ... }
>

please no.
This is just my very little unvaluable opinion, but %-stuff literals are
  one of the few things I don't like about ruby.
Nothing is telling me what they mean, It's something a user can't have
control over and there are subtle differencies beetween one and another
that are just... well.. _too_ subtle.

But as I write I'm getting the idea you're suggesting overridable %
constructors? If that is the suggestion.. well, interesting :slight_smile:

I wasn't really suggesting anything concretely -- just looking for a
direction to go in to solve Hal's problem about no available literal
syntax. I think user-defined %-notation is probably impossible, since
any given notation could be defined by multiple libraries and
conflict.

David

--
David A. Black
dblack@wobblini.net

10

But as I write I'm getting the idea you're suggesting overridable %
constructors? If that is the suggestion.. well, interesting :slight_smile:

Maybe this is a good moment to bring this up: user defined % literals. A
way to define your own % literals or redefine existing ones. It is also
possible to have your own private redefinition of a literal thus avoiding
the problem of breaking other people's code. The proposal can be found
here:

  http://www.rubygarden.org/ruby?UserDefinedLiterals

and as of today also at RCRchive:

  RCR::RCR279 - RCRchive home

Peter

11

    z = [1=>2, 3=>4] # ordered association

This is a nice syntax, and ruby really like it :slight_smile:

svg% ruby -e 'p [1=>2, 3=>4]'
[{1=>2, 3=>4}]
svg%

Guy Decoux

12

Hello,

My main use for using ordered hashes is to express repeated regexp string transformations. For example, in php I use this series of regexp's to clean up html spacing:

   foreach( array( '/\n|\f|\r/' => " ",
                               '/\s+/' => " ",
                               '/\s*<\/p>/i' => "</p>",
                               '/<p><(&nbsp;)?\/p>/i' => "",
                               '/<p>/i' => "\n\n<p>",
                               '/<p>$/i' => "", ) as $p => $r ) {
     $string = preg_replace( $p, $r, $string );
   }

There are of course other uses, but has been a real handy one for me.

Cheers,

Patrick

13

Yukihiro Matsumoto wrote:

Hi,

>However, if order in literals is irrelevant, then hashes are not truly
>ordered entities, are they?

My opinion is preserving order reduces some "pitfalls". Reducing
pitfalls is a good thing. To be honest, I don't care whether Hash
being "true" ordered entity or not.

I defer to your judgment of course.

But a large part of my desire for an ordered collection of this nature
is the desire to write ordered literals.

Arrays and hashes in Ruby would not be nearly so convenient and clear
if one had to write:

   arr = Array.new(3,5,7,9,11)
   hsh = Hash[1,2,3,6,9,12)

If a Hash object preserved order, but a literal did not guarantee an order --
then to preserve the order with literals, we would have to do something like:

   hash = {1=>2}.update(3=>4).update(5=>6)

instead of just

   hash = {1=>2, 3=>4, 5=>6}

Is it a possible option to change the semantics of [x=>y] ?

   h1 = {1=>2, 3=>4} # order not guaranteed
   h2 = [1=>2, 3=>4] # order guaranteed

I realize (now) that [x=>y] is currently an array with a
single element which is a hash.

Hal

···

In message "Re: OK... :slight_smile: question about hash and array literals" > on Sun, 5 Sep 2004 01:38:42 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

14

David A. Black ha scritto:

I wasn't really suggesting anything concretely -- just looking for a
direction to go in to solve Hal's problem about no available literal
syntax. I think user-defined %-notation is probably impossible, since
any given notation could be defined by multiple libraries and
conflict.

David

yes, but no more than it is possible to have two classes with the same name or two methods with the same name in Kernel.
If %something{blabla} worked like, say, a call to PercentLiterals.something('blabla') (but somewhat done at compile time) it could provide ri-able documentation, an extensible system, and possibly, with time, the death of q/Q/w/W//s/x/.
Yeah, I really dislike them, sorry :slight_smile:

15

ts wrote:

"H" == Hal Fulton <hal9000@hypermetrics.com> writes:

> z = [1=>2, 3=>4] # ordered association

This is a nice syntax, and ruby really like it :slight_smile:

svg% ruby -e 'p [1=>2, 3=>4]'
[{1=>2, 3=>4}]
svg%

Haha... but I would like to combine its love of the
syntax with a love of a new semantics. :slight_smile:

Hal

16

"Patrick May" <patrick@hexane.org> schrieb im Newsbeitrag news:4916C543-FEA8-11D8-81CB-000A95848050@hexane.org...

Hello,

My main use for using ordered hashes is to express repeated regexp string transformations. For example, in php I use this series of regexp's to clean up html spacing:

  foreach( array( '/\n|\f|\r/' => " ",
                              '/\s+/' => " ",
                              '/\s*<\/p>/i' => "</p>",
                              '/<p><(&nbsp;)?\/p>/i' => "",
                              '/<p>/i' => "\n\n<p>",
                              '/<p>$/i' => "", ) as $p => $r ) {
    $string = preg_replace( $p, $r, $string );
  }

There are of course other uses, but has been a real handy one for me.

In this case nested arrays are sufficient since you don't need efficient lookup. The only access is iteration as far as I can see. Example:

transformations = [
  [/foo/, "bar"],
  [/baz/, "xxx"],
  [/\s+/, " "],
]

text = "xxx foo ddddd bar bazsiud"

transformations.each {|rx, repl| text.gsub!(rx, repl) }

Kind regards

    robert

17

Hi,

···

In message "Re: OK... :slight_smile: question about hash and array literals" on Mon, 6 Sep 2004 03:36:08 +0900, Hal Fulton <hal9000@hypermetrics.com> writes:

Is it a possible option to change the semantics of [x=>y] ?

  h1 = {1=>2, 3=>4} # order not guaranteed
  h2 = [1=>2, 3=>4] # order guaranteed

I realize (now) that [x=>y] is currently an array with a
single element which is a hash.

Are there any reason to make hash literals not to guarantee order?
I thought

  h = {1=>2, 3=>4}

will preserve the order, when ordering is implemented.

              matz.

18

Yes -- this is why it's usually bad to add methods to Kernel, unless
you're sure you're standalone.

David

···

On Sat, 4 Sep 2004, gabriele renzi wrote:

David A. Black ha scritto:

>
>
> I wasn't really suggesting anything concretely -- just looking for a
> direction to go in to solve Hal's problem about no available literal
> syntax. I think user-defined %-notation is probably impossible, since
> any given notation could be defined by multiple libraries and
> conflict.
>
>
> David
>

yes, but no more than it is possible to have two classes with the same
name or two methods with the same name in Kernel.

--
David A. Black
dblack@wobblini.net

19

Yukihiro Matsumoto wrote:

Are there any reason to make hash literals not to guarantee order?
I thought

  h = {1=>2, 3=>4}

will preserve the order, when ordering is implemented.

Oh! I misunderstood completely, then.

My original understanding was that

     {1=>2, 3=>4} == {3=>4, 1=>2}

implied that order was not preserved in literals.

Hal

20

It would depend on what the ordering is used for, no?
If ordering is only used to feed 'next', then the compare above would
still be true.

Personally, I'd like it to remember the order you added things in, use
that ordering when iterating through the hash, and _optionally_ use it
for compares.

Something like...
{1=>2, 3=>4} == {3=>4, 1=>2}
{1=>2, 3=>4}.ordered != {3=>4, 1=>2}.ordered

···

On Mon, 6 Sep 2004 08:31:38 +0900, Hal Fulton <hal9000@hypermetrics.com> wrote:

Yukihiro Matsumoto wrote:
> Are there any reason to make hash literals not to guarantee order?
> I thought
>
> h = {1=>2, 3=>4}
>
> will preserve the order, when ordering is implemented.

Oh! I misunderstood completely, then.

My original understanding was that

     {1=>2, 3=>4} == {3=>4, 1=>2}

implied that order was not preserved in literals.

--
Bill Guindon (aka aGorilla)