Hi all,

My AA implementation is slowly inching closer to being ready to replace aaA.d. So far I've been writing the implementation outside of object_.d for ease of testing & development; now I'm ready to start moving stuff into object_.d to start working on integration with druntime. So I'm wondering how the current stuff works.

Is it correct that when the compiler sees a declaration like:

	int[string] aa;

it automatically translates that to struct AssociativeArray(K,V)?

What about the functions in aaA.d? I presume the compiler generates calls to them whenever it sees an AA construct like "x in y", "x[y]", etc?

Right now, I've implemented opBinaryRight!"in", opIndexAssign, and opIndex; will the compiler know to invoke these methods, or will it still go through aaA.d? I presume the latter? If so, I was thinking that I can simply forward these calls to struct AssociativeArray, but the problem is I wouldn't know which instance to forward it to since the aaA.d functions only get typeinfos and an opaque pointer.

(There are also other issues, such as potential code bloat from instantiating AssociativeArray(K,V), since everything is in the template struct member now. But I'm not too worried about that yet; once the AA implementation is fully dissocciated from aaA.d, it should be relatively easy to factor out common code and/or replace the implementation with something better.)


T

-- 
Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn

Welcome to Hell. =D

Some of the things you can do with AAs are recognized by the compiler during semantic and turned into druntime calls, sometimes the constructs survive all the way to the glue layer (e2ir) and are turned into druntime calls there and sometimes the type of an expressions is magically rewritten to AssociativeArray and the methods are looked up normally.  (this one caused problems with literals)

The type needs to stay as V[K] _not_ AssociativeArray, so that error messages work properly.  Something needs to be done about literals too... Don't forget template arg deduction!

There's a function AAGetSym (or something like that) that can be searched for to find where dmd emits druntime calls, but there might be other places it generates them.

Enjoy.

On 14 March 2012 14:37, Daniel Murphy <yebblies@nospamgmail.com> wrote:
> Welcome to Hell. =D

Sounds fun.

(Seasoned DF player)

--
James Miller

On 3/13/12 7:54 PM, H. S. Teoh wrote:
> Hi all,
>
> My AA implementation is slowly inching closer to being ready to replace
> aaA.d.

Great! This will need compiler restructuring, and in fact offers the perfect opportunity for it. I suggest you to post your implementation here for review first, and assume only the minimal lowerings from the compiler.

Here's something that I thinks we should have:

int[string] aa;
char[] b;
...
aa[b] = 42;

The implementation should be clever enough to work, and only duplicate the string if it wasn't already present.


Thanks,

Andrei

On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:
> Hi all,
>
> My AA implementation is slowly inching closer to being ready to replace aaA.d. So far I've been writing the implementation
> outside of object_.d for ease of testing & development; now I'm
> ready to start moving stuff into object_.d to start working on
> integration with druntime.

Hi,

If I'm understanding this correctly you are moving the entire
implementation of the AA into object.d and as such letting
programs be purview to its inner working? In sort meaning you
are making the entire AA implementation D ABI locked.

This will make it impossible to either change the AA
implementation in any ABI breaking fashion or make it impossible
to pass AA's between libraries compiled against different
versions of druntime.

Is this what we really want?

Cheers, Jakob.

On 14.03.2012 6:39, Jakob Bornecrantz wrote:
> On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:
>> Hi all,
>>
>> My AA implementation is slowly inching closer to being ready to
>> replace aaA.d. So far I've been writing the implementation
>> outside of object_.d for ease of testing & development; now I'm
>> ready to start moving stuff into object_.d to start working on
>> integration with druntime.
>
> Hi,
>
> If I'm understanding this correctly you are moving the entire
> implementation of the AA into object.d and as such letting
> programs be purview to its inner working? In sort meaning you
> are making the entire AA implementation D ABI locked.
>
> This will make it impossible to either change the AA
> implementation in any ABI breaking fashion or make it impossible
> to pass AA's between libraries compiled against different
> versions of druntime.

I will just point out that the major point of ABI is to make sure different D compiler produce compatible object code. Thus it makes AA implementation locked already anyway, right?

>
> Is this what we really want?
>
> Cheers, Jakob.


-- 
Dmitry Olshansky

On 14/03/12 03:39, Jakob Bornecrantz wrote:
> On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:
>> Hi all,
>>
>> My AA implementation is slowly inching closer to being ready to
>> replace aaA.d. So far I've been writing the implementation
>> outside of object_.d for ease of testing & development; now I'm
>> ready to start moving stuff into object_.d to start working on
>> integration with druntime.
>
> Hi,
>
> If I'm understanding this correctly you are moving the entire
> implementation of the AA into object.d and as such letting
> programs be purview to its inner working? In sort meaning you
> are making the entire AA implementation D ABI locked.
>
> This will make it impossible to either change the AA
> implementation in any ABI breaking fashion or make it impossible
> to pass AA's between libraries compiled against different
> versions of druntime.

Much less so than the existing AA implementation.

On Tue, 13 Mar 2012 22:39:25 -0400, Jakob Bornecrantz <wallbraker@gmail.com> wrote:

> On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:
>> Hi all,
>>
>> My AA implementation is slowly inching closer to being ready to replace aaA.d. So far I've been writing the implementation
>> outside of object_.d for ease of testing & development; now I'm
>> ready to start moving stuff into object_.d to start working on
>> integration with druntime.
>
> Hi,
>
> If I'm understanding this correctly you are moving the entire
> implementation of the AA into object.d and as such letting
> programs be purview to its inner working? In sort meaning you
> are making the entire AA implementation D ABI locked.
>
> This will make it impossible to either change the AA
> implementation in any ABI breaking fashion or make it impossible
> to pass AA's between libraries compiled against different
> versions of druntime.
>
> Is this what we really want?

This is unavoidable, whether it's a template or not.  What changes do you envision would be transparent using an opaque pImpl model (as was done in previous versions of phobos), but would break using templates?

-Steve

On Wednesday, 14 March 2012 at 09:07:40 UTC, Dmitry Olshansky wrote:
> On 14.03.2012 6:39, Jakob Bornecrantz wrote:
>> On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:
>>> Hi all,
>>>
>>> My AA implementation is slowly inching closer to being ready to
>>> replace aaA.d. So far I've been writing the implementation
>>> outside of object_.d for ease of testing & development; now I'm
>>> ready to start moving stuff into object_.d to start working on
>>> integration with druntime.
>>
>> Hi,
>>
>> If I'm understanding this correctly you are moving the entire
>> implementation of the AA into object.d and as such letting
>> programs be purview to its inner working? In sort meaning you
>> are making the entire AA implementation D ABI locked.
>>
>> This will make it impossible to either change the AA
>> implementation in any ABI breaking fashion or make it impossible
>> to pass AA's between libraries compiled against different
>> versions of druntime.
>
> I will just point out that the major point of ABI is to make sure different D compiler produce compatible object code. Thus it makes AA implementation locked already anyway, right?

Not true, as Steven said a opaque pImpl implementation would
work, most modern C library design follow this principle with
only using opaque except for pointers. This is because the ABI
will then only require you call a certain set of functions (that
can be extended to) not what that pointers points to, the
details can be completely hidden.

Cheers, Jakob.

On Wednesday, 14 March 2012 at 13:55:23 UTC, Don Clugston wrote:
> On 14/03/12 03:39, Jakob Bornecrantz wrote:
>> On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:
>>> Hi all,
>>>
>>> My AA implementation is slowly inching closer to being ready to
>>> replace aaA.d. So far I've been writing the implementation
>>> outside of object_.d for ease of testing & development; now I'm
>>> ready to start moving stuff into object_.d to start working on
>>> integration with druntime.
>>
>> Hi,
>>
>> If I'm understanding this correctly you are moving the entire
>> implementation of the AA into object.d and as such letting
>> programs be purview to its inner working? In sort meaning you
>> are making the entire AA implementation D ABI locked.
>>
>> This will make it impossible to either change the AA
>> implementation in any ABI breaking fashion or make it impossible
>> to pass AA's between libraries compiled against different
>> versions of druntime.
>
> Much less so than the existing AA implementation.

In what way moving the entire implementation into templates
that gets compiled into the object code of all the uses, got
to be worse (for ABI) then having the implementation separate?

I think you are not seeing the implementation off calling
into the opaque implementation as two separate things. Yes the
current implementation off calling into is bad and should be
replaced.

Ponder this for example:

struct AA(K, V)
{
  void *ptr;

  void init() { ptr = rt_aaInit(typeinfo!K, typeinfo!V; }

  static if (isData!K)
     void add(K k, V ref v) { rt_aaAddData(ptr, cast(ulong)k, v); }
  else static if (isPointer!K)
     void add(K k, V ref v) { rt_aaAddPointerWithHash(ptr, k, toHash!K(k), v); }
  else
     void add(K ref k, V ref v) { rt_aaAdd(ptr, k, v); }
}

Adding to this implementation wouldn't require changing DMD
at all only _object.d and the aa implementation in druntime.

The use of the AA struct isn't required by the ABI, only
that functions gets called for doing things to a AA.


Cheers, Jakob.