View mode: basic / threaded / horizontal-split · Log in · Help
March 04, 2012
Is it bad for object.di to depend on core.exception?
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.
March 04, 2012
Re: Is it bad for object.di to depend on core.exception?
"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.
March 04, 2012
Re: Is it bad for object.di to depend on core.exception?
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
March 04, 2012
Re: Is it bad for object.di to depend on core.exception?
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.
March 04, 2012
Re: Is it bad for object.di to depend on core.exception?
"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?
March 04, 2012
Re: Is it bad for object.di to depend on core.exception?
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
March 04, 2012
Re: Is it bad for object.di to depend on core.exception?
> T
>
Wasn't the latest proposal that we add a working AA implementation
to the runtime and switch the compiler after that has settled?
Top | Discussion index | About this forum | D home