So I'm still working on fixing issue 5030, which *should* have been a trivial fix. But I'm running into a bunch of circumstantial problems, among which is this new method in AssociativeArray(Key,Value):

    Value opIndex(Key key, string file=__FILE__, size_t line=__LINE__)
    {
    	auto p = key in *cast(Value[Key]*)(&p);
	if (p) return *p;
	throw new RangeError(file, line);
    }

Originally it was simply Value opIndex(Key key) without any range check, which is probably a bad idea, so I added the throw RangeError in there.

However, this introduces a dependency from object.di to core.exception. So this requires import core.exception in object.di, without which Phobos doesn't compile (for obvious reasons). But adding the import causes druntime to fail to compile, because, for example, core.stdc.stdio is compiled withouth druntime/src in the compiler's search path, so the compiler can't find core.exception.

So I'm wondering, is it OK to add druntime/src to the compiler's search path when building druntime? Or is there a reason for the omission?

But perhaps a more pertinent question is, why is there so much duplication between aaA.d and object.AssociativeArray? For example, object.AssociativeArray basically copies (with modifications!) a bunch of implementation-dependent details from aaA.d, and sometimes uses that, and sometimes uses the other. Is it possible to dispense with this schizophrenic code duplication (which is very fragile, since changing the AA implementation in aaA.d will almost certainly break the Range stuff in AssociativeArray)?


T

-- 
People say I'm arrogant, but they're just ignorant fools.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.370.1330829036.24984.digitalmars-d@puremagic.com...
> So I'm still working on fixing issue 5030, which *should* have been a trivial fix. But I'm running into a bunch of circumstantial problems, among which is this new method in AssociativeArray(Key,Value):
>
>    Value opIndex(Key key, string file=__FILE__, size_t line=__LINE__)
>    {
>    auto p = key in *cast(Value[Key]*)(&p);
> if (p) return *p;
> throw new RangeError(file, line);
>    }
>
> Originally it was simply Value opIndex(Key key) without any range check, which is probably a bad idea, so I added the throw RangeError in there.
>
> However, this introduces a dependency from object.di to core.exception. So this requires import core.exception in object.di, without which Phobos doesn't compile (for obvious reasons). But adding the import causes druntime to fail to compile, because, for example, core.stdc.stdio is compiled withouth druntime/src in the compiler's search path, so the compiler can't find core.exception.
>
> So I'm wondering, is it OK to add druntime/src to the compiler's search path when building druntime? Or is there a reason for the omission?
>
> But perhaps a more pertinent question is, why is there so much duplication between aaA.d and object.AssociativeArray? For example, object.AssociativeArray basically copies (with modifications!) a bunch of implementation-dependent details from aaA.d, and sometimes uses that, and sometimes uses the other. Is it possible to dispense with this schizophrenic code duplication (which is very fragile, since changing the AA implementation in aaA.d will almost certainly break the Range stuff in AssociativeArray)?
>

Ok, let me tell you a story.  Once apon a time AAs were part of the language proper, doing anything with them resulted in calls to druntime c linkage functions, which you can see in aaA.d.  Then, a few of years ago they were moved into druntime, so that the implementation and interface could be improved without modifying the compiler.  While only about three things were ever added to the AA interface, this had the major side effect of introducing dozens of ice bugs and _increasing_ the amount of code needed to support AAs, especially in the interpreter and the glue layer.  On top of this, most of the functionality is still done with the compiler emitting druntime calls.

In the last release, Andrei made things worse by copying the AA implementation layout into object.di in order to make ranges work.  (To be fair there isn't really a better way to do this with the current setup.)

We're basically stuck with this until someone comes up with a solution that lets everything work as it should, with AAs completely in the runtime or the compiler.

On 3/3/12 9:19 PM, Daniel Murphy wrote:
> We're basically stuck with this until someone comes up with a solution that
> lets everything work as it should, with AAs completely in the runtime or the
> compiler.

I think we must migrate the arrays into the runtime.

Andrei

On Sat, Mar 03, 2012 at 09:47:49PM -0600, Andrei Alexandrescu wrote:
> On 3/3/12 9:19 PM, Daniel Murphy wrote:
> >We're basically stuck with this until someone comes up with a solution that lets everything work as it should, with AAs completely in the runtime or the compiler.
> 
> I think we must migrate the arrays into the runtime.
[...]

What are the issues that currently prevent this?


T

-- 
Blunt statements really don't have a point.

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jiuol3$rqb$1@digitalmars.com...
> On 3/3/12 9:19 PM, Daniel Murphy wrote:
>> We're basically stuck with this until someone comes up with a solution
>> that
>> lets everything work as it should, with AAs completely in the runtime or
>> the
>> compiler.
>
> I think we must migrate the arrays into the runtime.
>
> Andrei

I know.  It was before my time, but I assume you were the one who pushed for this in the first place?

The one advantage I can see to having them in druntime gives is that it means they can be fully templated, and therefore do comparisons etc without going through typeinfo.  This is it right?

On Sun, Mar 04, 2012 at 03:24:47PM +1100, Daniel Murphy wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jiuol3$rqb$1@digitalmars.com...
[...]
> > I think we must migrate the arrays into the runtime.
> >
> > Andrei
> 
> I know.  It was before my time, but I assume you were the one who pushed for this in the first place?
> 
> The one advantage I can see to having them in druntime gives is that it means they can be fully templated, and therefore do comparisons etc without going through typeinfo.  This is it right?
[...]

Not just comparisons, but size of values, etc., all need typeinfo currently. Pretty much all the code in aaA.d needs to dig under the hood and do lots of black magic like pointer arithmetic based on typeinfo stuff in order to do stuff. Perhaps _aaLen might be the only exception. While it's cool that D lets you do this when needed, it's also a sign that some cleanup might be in order. :-)

How feasible is it to migrate AA's into object_.d, say, and have the stuff in aaA.d simply wrap around AssociativeArray? I suppose this can't really happen without some major changes in the compiler, since I don't know how to instantiate AssociativeArray given only the typeinfo's (not the actual types) of the key/value.


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall

> T
>
Wasn't the latest proposal that we add a working AA implementation
to the runtime and switch the compiler after that has settled?