Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)

[H. S. Teoh]

On Thu, Mar 15, 2012 at 11:50:47PM +0400, Dmitry Olshansky wrote:
[...]
> >This is one major area that I forgot to mention, and that is, making
> >AA literals work at compile-time. Currently things like this don't
> >work:
> >
> >	enum myAA = ["abc":123, "def":456];
> >
> >I'd like to make that work. That would require compile-time
> >construction of the AA and storing it in some form that the compiler
> >can put into the object file.
> 
> What's wrong with AA structure itself, it's link-pointer based?  At
> any rate, I stored complex structs as immutable, though links were
> index-based.

Yes, that's what I had in mind.

In fact, I've starting testing a statically-declared AA (written by hand
for now), that uses the same structures as heap-allocated AA's. The
basic stuff (declaring Slots statically, linking them together, etc.)
works, and in principle can be generated by mixins at compile-time to
give us "true" compile-time AA literals (as in, the AA struct is
computed at compile-time and stored in the static data segment in the
object file). This can be used for implementing immutable AA's at
compile-time (and maybe also "fast" initialization of AA literals which
can be .dup'd at runtime into mutable AA's when needed).

However, I've run into a major roadblock: the hash computation of the
keys itself. Unfortunately, currently there's no (reliable) way to
compute the hash of built-in types unless you use its TypeInfo, and
TypeInfo's are currently not CTFE-accessible, so hash values cannot be
computed at compile-time. :-(


T

-- 
He who laughs last thinks slowest.