View mode: basic / threaded / horizontal-split · Log in · Help
March 14, 2012
Replacing AA's in druntime
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
March 14, 2012
Re: Replacing AA's in druntime
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.
March 14, 2012
Re: Replacing AA's in druntime
On 14 March 2012 14:37, Daniel Murphy <yebblies@nospamgmail.com> wrote:
> Welcome to Hell. =D

Sounds fun.

(Seasoned DF player)

--
James Miller
March 14, 2012
Re: Replacing AA's in druntime
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
March 14, 2012
Re: Replacing AA's in druntime
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.
March 14, 2012
Re: Replacing AA's in druntime
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
March 14, 2012
Re: Replacing AA's in druntime
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.
March 14, 2012
Re: Replacing AA's in druntime
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
March 14, 2012
Re: Replacing AA's in druntime
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.
March 14, 2012
Re: Replacing AA's in druntime
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home