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