Call for arms: associative array reimplementation

Dmitry Olshansky dmitry.olsh at gmail.com
Thu Feb 21 09:33:53 PST 2013


21-Feb-2013 14:49, Dicebot пишет:
> I have had a small e-mail conversation with H. S. Teoh recently
> regarding his old attempt to reimplement built-in associative arrays and
> fix various issues they create. His experience and memories are written
> down in wiki now:
>
> http://wiki.dlang.org/AA_Implementation_Issues
>
> I still do want to continue this task, but this happened to be much more
> tricky and I just been walking circles around so far. So if anyone has
> some spare time and wants to show his D Kung Fu - this wiki article is
> probably worth checking out :) As far as I know this is kind of
> "pre-approved" change.

I'd love to help but I've got my hands full already.

In essence the only way I see this ball rolling:

a) make a hacked version of compiler that actually **cking gets rid of 
V[K] by replacing it with __AA!(V, K) the moment it sees it. Literals 
are structs of type __AALiteral!(V,K), both could be defined anywhere 
but are expected in object.d.

Yes, that means error messages, is(...) matching and so on all see and 
expose this template. NO reverse conversion or special casing to have it 
as built-in type must be done anywhere, period. Technically advanced 
users should be able to replace built-in __AA template with something 
custom.

b) The aforementioned compiler probably won't be able to compile much of 
anything excpet druntime. The way to go is to hack away on this__AA 
template in druntime object.d and compile test cases in isolation.

c) Once the stuff is stable enough integrate Phobos.

d) Only then when all works, and AA is plain temaplted type done via 
lowering we should try to make error messages look more pretty and 
replace __AA!(K, V) with V[K] in error logs alone.

The tricky part about immutable values isn't tricky at all. At the 
moment you just blast your way through with casts. Since AA 
implementation is in sole control of memory and it's definitely on HEAP 
there is no risk of writing to ROM/protected stuff. It's more an act of 
courage then trickery ;)

P.S. The new AA implementation IMHO would fix as much as it would break 
simply because the current one is half-magic, half-bug. That's one of 
reasons it should be done by reaping it off, then doing it from scratch 
in the clean room at the side and then re-introduced it again.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list