On Sun, 2004-09-26 at 15:11, Mark Hubbart wrote:
> On Sep 26, 2004, at 11:54 AM, Markus wrote:
> 
> >      Perhaps.  I keep feeling that there is an "Ah ha!" lurking in  
> > here somewhere--if we just look at things on the right way, we could
> > (for 2.0) get nearly full backward compatibility, cleaner semantics,
> > and nice route for expanded expressiveness.  I'll post more if the
> > idea still seems reasonable after I think on it for a day or so...
> 
> 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