[OT] Re: DIP 1027---String Interpolation---Format Assessment

[H. S. Teoh]

On Thu, Feb 27, 2020 at 10:11:07AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote:
[...]
> Large hidden invisible types are not the problem (look at normal
> dynamic arrays, the large hidden type built into the runtime is a huge
> success I think). The problem is that the compiler gives special
> features to such types.
> 
> In the case of AA, the ONLY missing piece that cannot be implemented
> by user types is this:
> 
> int[string][string] aalist;
> 
> aalist["hello"]["world"] = 5;
> 
> In essence, the compiler knows how to make this work. The operators
> available do not allow this expression to be captured properly by user
> code (i.e. we don't have opIndexIndexAssign or
> opIndexIndexIndexAssign, nor does that scale).

It's not that hard:

	https://issues.dlang.org/show_bug.cgi?id=7753

Somebody just has to do it, that's all.


> I believe the last person to try and implement a full template type
> that could replace AAs is H. S. Teoh. He would have a better
> explanation (and possibly contradict me, I don't know).

Actually, I may have been the *first* one to try to do this, but I don't
think I was the last.  Over the years various pieces of the AA
implementation has been templatized and moved to druntime, though the
core implementation is still in aaA.d.  I think, on the basis of this
other work, that we're in a far better position now to fully move AA's
into a template implementation.  I haven't been keeping track, though,
so I don't know what issues might remain that hinder this migration.


> Other than that, we've ripped out all other "magic" into templates in
> the language. If we could get that one feature (not sure how to do
> this in a scalable way), I think we have a full library type that can
> be further factored out of the compiler. We might even be able to
> avoid using TypeInfo, and make CTFE AAs compatible with runtime ones.
[...]

Yeah, most of the work on removing AA magic from the compiler has been
done by someone else, IIRC Martin Nowak among them, and probably others.

Making CTFE AAs usable at runtime is somewhat of a different beast,
though.  The main problem is that you need to be able to instantiate the
binary representation of a runtime AA (the main hash table, and each of
the buckets) at compile-time, and do so in a way that the compiler can
turn into data in the data segment of the executable.  Regardless of
what the CTFE representation is, it needs an explicit transformation
step to turn it into something the runtime code can decipher.

Basically, you have to create an .init value for the final object that
doesn't require calling a runtime memory allocation function, but
nonetheless still points to legit instances of AA buckets and their
contents.  This cannot be directly cast from the CTFE AA, because CTFE
AA buckets won't have legit runtime addresses that can be assigned to
the hash table's pointers.

I think this *might* be possible to do via a string mixin that creates
explicit variables for each AA bucket then the main hash table by taking
their addresses.  Of course, some hackish casts will probably be
required to make it all work with the current runtime AA implementation.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL