AAs [was Re: bigfloat]

[bearophile]

Andrei Alexandrescu:

>To me it is painfully obvious that there should be as little magic as possible for elaborate types. Literals and simple type syntax are useful. Keep those, but stop there and let actual code take off from there.<

So far I have expressed similar ideas three times, so I agree :-)


>These are great ideas. I'd be glad to implement them but currently my hands are tied by the way things are handled today.<

We are talking about a D module here, so you can write it and add it to the std lib. It can be used even without compiler support, and probably compared to the built-in ones it will be an improvement anyway, even without the syntax support. So go for it :-)
Regarding the name of such data structure, HashMap sounds good, it's a very standard name.
Once that module is done and works well enough, Walter can (eventually) change his mind and remove the current AAs and add the regex thing you have explained me, for the nice syntax support.

Later a similar strategy may be even used for a HashSet data structure and its syntax.
Implementing a set with a hashmap is easy, but a true set data structure supports other operations, like interection, union, difference, etc, that a HashMap usually doesn't need to implement. My experience (with Python) shows me that such set operations are useful to write short and readable high-level code.

-------------------

dsimcha:

>Even better would be if only the default implementation were in Object, and a user could somehow override which implementation of AA is given the blessing of pretty syntax by some pragma or export alias or something, as long as the implementation conforms to some specified compile-time interface.<

This is another step. I don't know how much easy/difficult it is to implement. As you may guess this is also a step toward a more modern pluggable compiler/language. (There are experimental Scheme compilers designed like this).


>Also, does anyone besides me have a use for an AA implementation that is designed to be used with a second stack-based allocator (TempAlloc/SuperStack as discussed here previously)?<

The default AA has to be flexible, even if it's not always top performance. Your implementation may be useful in a std lib, and not as built-in.


>From the code comments:
>Allocate a StackHash with an array size of nums.length / 2. This is the size of the array used internally, and is fixed.<

Do you use the alloca() function for this?

----------------

Andrei Alexandrescu:

dsimcha>>Even better would be if only the default implementation were in Object, and a user could somehow override which implementation of AA is given the blessing of pretty syntax by some pragma or export alias or something, as long as the implementation conforms to some specified compile-time interface.<<

>Further improvements of the scheme will then become within reach!<

At the moment I don't know what syntax/semantics it can be used to implement dsimcha's idea.

Thank you,
bye,
bearophile