www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is it bad for object.di to depend on core.exception?

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Mar 03 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Mar 03 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 03 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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?
Mar 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Mar 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Mar 03 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 T

to the runtime and switch the compiler after that has settled?
Mar 03 2012