Yield & associations (was Proc / def /yield semantics)

[Markus]

If Association is a subclass of Array or Values, then it should be
possible to splat it. Here's an extremely bare-bones version
demonstrating the possible behavior:

This looks to be very much along the lines I have been thinking,
except that I am totally ignorant of the class Values. Can you give me
a little background?

It's a neat idea, but I would wonder how practical it would be; I get
the feeling our nice fast hash lookups would be ruined... But since I
don't know the internals...

I'm thinking it could be done in a way that was almost pure sugar.
The key would be finding a way to decompose the current syntax into
cogent chunks that, when combined in the usual ways would have the usual
meanings, but could also be meaningfully combined in _new_ ways.

For example (WARNING: this should be a 2.0-at-the-earliest change
and in any case I'm still in the process of thinking it out):

* Define a class Association < Array with the methods key & value
(perhaps as synonyms for first and last), and Association#hash
returns self.key.hash.
* Open up the set of user-definable operators to include anything
that matches /[+-*/=<>.&^%!~]+/ or what have you.
* Make Object#=>(other) return Association.new(self,other)
* Make a hash work on anything that responds to "hash" (in other
words, anything) by storing the object under its hash.
* Make { v1,v2,v3...} build a hash, analogous to the way in which
[ v1,v2,v3...] builds an array. Note:
* This doesn't depend on the v's being constructed by =>,
but if they are the semantics would be the same as
always.
* The semantics of { k1,v1, k2,v2, k3,v3,... } would
change; it would produce something more like a set, with
the k's & v's as elements.
* The semantics of [ k1=>v1, k2=>v2...] would change;
instead of producing an array containing a single hash,
it would produce an (ordered) array of associations.
* The semantics of implicit hash arguments might change
* The semantics of Hash#to_a perhaps ought to be changed
* Let people implement their own functionality with these building
blocks (e.g., all the flavours of "ordered" hashes discussed a
few weeks ago should be trivial).
* Deprecate some of the functions that have been added to array to
support sets, associations, etc. and could now be better
implemented with these tools.

I'd call this a taste of my grand vision if I was more convinced
that it wasn't a whiff of my temporary hallucination. I'm in the
process of trying to puzzle out: 1) what does it break, 2) what would
break it (e.g. cause it to exhibit counter-intuitive behavior), and 3)
could it in fact be implemented.
Any thought/comments/questions/criticisms are welcome.

-- Markus

 

[Mark Hubbart]

This looks to be very much along the lines I have been thinking,
except that I am totally ignorant of the class Values. Can you give me
a little background?

IIRC, Values is the encapsulation class for parameter lists and
multiple assignment lists. I could easily be wrong, but I think that in
the future when you use the splat operator to collect items, you will
end up getting a Values object, not an Array. I think.

cheers,
Mark