It would be nice to have a static associative array syntax analogous to the static array syntax. Something like this perhaps:

char[][char[]] a = [ "a" : "Apple", "b" : "Banana", "c" : "Cantelope", ... ];

This syntax is unambiguous (though admittedly complex) even for arbitrarily complex AAs:

char[int][char[][char[]]] a = [ [ "a" : "b", "c" : "d" ] : [ 0 : 'e', 1 : 'f' ] ];

It also has the added advantage of being similar to the static struct syntax.


To be honest, I don't need static associative arrays desperately, but I also don't think I need to explain why it would be useful.

 - Gregor Richards

On Thu, 15 Feb 2007 23:07:54 -0800, Gregor Richards wrote:

> It would be nice to have a static associative array syntax analogous to the static array syntax. Something like this perhaps:
> 
> char[][char[]] a = [ "a" : "Apple", "b" : "Banana", "c" : "Cantelope", ... ];
> 
> This syntax is unambiguous (though admittedly complex) even for arbitrarily complex AAs:
> 
> char[int][char[][char[]]] a = [ [ "a" : "b", "c" : "d" ] : [ 0 : 'e', 1
>: 'f' ] ];
> 
> It also has the added advantage of being similar to the static struct syntax.
> 
> 
> To be honest, I don't need static associative arrays desperately, but I also don't think I need to explain why it would be useful.

I still prefer then syntax ...


 char[][char[]] a = [ "a" = "Apple", "b" = "Banana", "c" = "Cantelope",
 ... ];


 char[int][char[][char[]]] a = [ [ "a" = "b", "c" = "d" ] = [ 0 = 'e', 1
= 'f' ] ];

because the '=' makes it more obvious what data is being assigned to which key.


-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Gregor Richards wrote:
> It would be nice to have a static associative array syntax analogous to the static array syntax. Something like this perhaps:
> 
> char[][char[]] a = [ "a" : "Apple", "b" : "Banana", "c" : "Cantelope", ... ];
> 
> This syntax is unambiguous (though admittedly complex) even for arbitrarily complex AAs:
> 
> char[int][char[][char[]]] a = [ [ "a" : "b", "c" : "d" ] : [ 0 : 'e', 1 : 'f' ] ];
> 
> It also has the added advantage of being similar to the static struct syntax.

Yep, what we need, is sort of 'AA Literals' which can be used to initialize either static or dynamic associative array.

-- 
serg.

> Yep, what we need, is sort of 'AA Literals' which can be used to initialize either static or dynamic associative array.
> 
> -- 
> serg.

Well, currently dynamic arrays are initialized by dup'ing a static array, or by assigning one thing at a time (ick).

Associative Arrays should be no different really.  I think the issue with this is that the hash function he's using runs on pointers, which means you can't build the hashtables until runtime and therefore can't have static associative arrays without changes.  Am I correct?

For my needs (small associative arrays as objects), I would prefer not to use hashing, and instead use a median-left, low-left binary search array (x << 1 goes left, x << 1 + 1 goes right, and cache stays coherent.)  The plan was to again use the char[] structs (not the actual strings) I'm going to look into what I can do to override Associative Arrays in D.

On that note, has anyone found evidence of a median-left low-left binary search array?  I think (currently) I may be the first to use such a device, in spite of it's obviousness?  I'd love to hear evidence otherwise.

Thanks,
Dan

> I think the issue with this is that the hash function he's using runs on pointers, which means you can't build the hashtables until runtime and therefore can't have static associative arrays without changes.  Am I correct?

Walter?

Dan wrote

> I'd love to hear evidence otherwise.

It's well known

http://commons.wikimedia.org/wiki/Image:Binary_tree_in_array.svg

-manfred

Dan Wrote:
<snip>
> Associative Arrays should be no different really.  I think the issue with this is that the hash function he's using runs on pointers, which means you can't build the hashtables until runtime and therefore can't have static associative arrays without changes.  Am I correct?
<snip>

But it should still work on built-in types.  Moreover, even if for a given type doing it at compiletime doesn't work, it could generate a module constructor that does the initialisation.

Stewart.