Comments on Programming and Debugging (in my Underhøøsen): Associative Arrays in D.NET

It was easier to go the helper / delegate way beca...

2009-03-25T12:08:00.000-07:00

It was easier to go the helper / delegate way because the front-end (which I did not write) does the lambda-extract already.

My first instinct when I sat down to implement foreach over associative arrays was exactly what you are suggesting -- but then I ran into the "foreach over opApply" language feature.

As for the ordering question: I believe that if some code depends on a particular order of the elements in the associative array then something is wrong with the design, and a different data structure should be used. In C++ for example, if you needed the elements to be ordered you would use a map over a hash_map (which BTW in C++ox will be renamed to unordered_map, to make it unambiguous that one should not rely on any particular ordering).

Feel free to email if you prefer that medium over the comment format.

For the most part, I meant in your CIL emission ph...

2009-03-25T11:36:00.000-07:00

For the most part, I meant in your CIL emission phase. Rather than utilize a helper class which uses a lambda-extract (based upon how I'm guessing you call it, for it to properly maintain scope. Though what I do know of D, sub-methods are simply a feature, so it was probably easy once that feature was implemented), you could have emitted CIL similar to how C# implements its for-each iterations on enumerable targets. Replacing references of 'key' and 'value', or whatever the named elements resolve to, with KeyValuePair<..., ...>.Key and ..Value respectively. This should be pretty simple once you properly resolve all symbols, right?

Also, couldn't there be issues with alternative implementations of core constructs (ie. associative arrays)? Especially when related to basic behavior, the code on two compilers would yield different functionality, ignoring the semantic differences between versions (such as version(D_NET)). Such functional differences would make code confusing in cases where you use conditional compilation arguments, since one would think that the native compiler and the D_NET compiler would emit functionally equal code.

Certain predictability assumptions would be more difficult to make until you became fully aware of the differences between the versions maintained in the code (for example, the order in which elements in an associative array might be important in certain cases, it's not related to a system feature either, so different functionality would be odd, to say the least).

Naturally, I might be missing something, I stumbled upon your blog while reading about 'D' from another link I received from someone else (so what I know about it is 5 minutes worth of reading, your blog was listed in a page about The Astoria Seminar).

If there's something I missed about D, implementing it, and so on, please clue me in (I'm interested in language design and implementation, code generation, and so on).

Good observation. The order is implementation-depe...

2009-03-25T10:35:00.000-07:00

Good observation. The order is implementation-dependent:

In D.NET the associative array is a generic Dictionary while the native D compiler rolls its own hash container under the wraps.

The D language spec leaves the implementation of associative arrays up to the compiler.

Throwing an exception from the iteration loop does not break the internals of the array, if that's what you meant.

The transactional flavor was unintentional, and it is easy to eliminate. I am not sure that I understand what you mean by "forgo a transformation on the foreach iteration of the associative array".

object.Exception: kaboomtwo, 0three, 3one, 1Just c...

2009-03-25T08:29:00.000-07:00

object.Exception: kaboom
two, 0
three, 3
one, 1

Just curious, I'm not overly familiar with D; however, if the entire set was iterated over, what determines the order? From the example above, you defined the elements in a different order (ala: int [string] x = ["two" : 2, "three" : 3, "one" : 1];) from the example provided. Just noticed by the fact that "one":1 was still 1.

If you didn't use a different set of code, could the exception be de-synchronizing the associative array (based upon the underlying implementation, of course)? I'm probably over-thinking this.

On a side note, why did you forgo a transformation on the foreach iteration of the associative array? Wouldn't it be easier, were you to omit the transactional flavor, to emit the proper CIL to handle a C#-ish foreach block (to get proper code flow on exceptions)?