March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wed, Mar 14, 2012 at 11:58:01PM -0500, Andrei Alexandrescu wrote: > On 3/14/12 6:16 PM, H. S. Teoh wrote: > >- Declaring an AA with non-const array keys will cause reams and reams > > of compile errors. I'm not *too* worried about this at the moment > > since it doesn't make sense to have non-const AA keys anyway. I'm > > also seriously considering forcing *all* AA keys to be immutable, > > in which case this will become a non-issue. > > I think the built-in associative array must allow non-constant keys. As long as there's no memory safety issue, the AA should work with types that the user doesn't change for comparison purposes but can otherwise modify. > > A practical matter is that if we introduce this restriction we'll break a ton of code. [...] Understood. But if the user changes the keys then the AA will malfunction. (This is no worse than the current behaviour, I suppose.) So now I've to track down why non-const keys trigger a ton of errors... :-/ T -- "No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev |
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Wed, Mar 14, 2012 at 08:47:23PM -0400, bearophile wrote: > H. S. Teoh: > > > - I haven't stress-tested AA performance yet. (Any volunteers? ;-)) > > I have just seen that the performance of the Sokoban solver is unchanged. I've just run the Sokoban solver in a loop that runs the solve 20 times in a row. I consistently get around 7 seconds in total for both the current aaA.d AA implementation and my new implementation. So far it they seem to perform about the same. > > In spite of its flaws, this implementation already addresses quite a few AA-related issues in the bugtracker, > > How efficiently is this AA working with keys like: > AssociativeArray!(immutable char[60], bool) aa; > Built-in AAs become snail-slow with such keys. [...] I'll try something like this next. Thanks for the feedback! T -- PNP = Plug 'N' Pray |
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Wednesday, 14 March 2012 at 23:14:42 UTC, H. S. Teoh wrote:
> Alright, I've finished the basic functionality of my AA implementation.
> I still haven't solved that problem with using suffixless string
> literals to index X[dstring], so you'll have to write aa["abc"d] instead
> of just aa["abc"]. But I thought I should post my code now so that
> people can take a look at it:
>
> https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d
>
>
> T
Thanks for tackling the AA problem.
I have one slight issue / comment regarding AAs: I really dislike the idea of cramming everything under the sun into object.d. In general, cramming lots'o'code into a single mega file is a code smell which Phobos greatly stinks from.
At the very least, object.d can publicly import your newAA.d module which gives the exact same outcome while keeping separate features separate.
|
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to foobar | On 2012-03-15 08:59, foobar wrote: > On Wednesday, 14 March 2012 at 23:14:42 UTC, H. S. Teoh wrote: >> Alright, I've finished the basic functionality of my AA implementation. >> I still haven't solved that problem with using suffixless string >> literals to index X[dstring], so you'll have to write aa["abc"d] instead >> of just aa["abc"]. But I thought I should post my code now so that >> people can take a look at it: >> >> https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d >> >> >> T > > Thanks for tackling the AA problem. > I have one slight issue / comment regarding AAs: I really dislike the > idea of cramming everything under the sun into object.d. In general, > cramming lots'o'code into a single mega file is a code smell which > Phobos greatly stinks from. > At the very least, object.d can publicly import your newAA.d module > which gives the exact same outcome while keeping separate features > separate. I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d -- /Jacob Carlborg |
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg <doob@me.com> wrote:
> On 2012-03-15 08:59, foobar wrote:
>> On Wednesday, 14 March 2012 at 23:14:42 UTC, H. S. Teoh wrote:
>>> Alright, I've finished the basic functionality of my AA implementation.
>>> I still haven't solved that problem with using suffixless string
>>> literals to index X[dstring], so you'll have to write aa["abc"d] instead
>>> of just aa["abc"]. But I thought I should post my code now so that
>>> people can take a look at it:
>>>
>>> https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d
>>>
>>>
>>> T
>>
>> Thanks for tackling the AA problem.
>> I have one slight issue / comment regarding AAs: I really dislike the
>> idea of cramming everything under the sun into object.d. In general,
>> cramming lots'o'code into a single mega file is a code smell which
>> Phobos greatly stinks from.
>> At the very least, object.d can publicly import your newAA.d module
>> which gives the exact same outcome while keeping separate features
>> separate.
>
> I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d
I think the compiler would have to change for that to happen.
I would support such a change, but then again, it seems like we'd get little measurable benefit for it, making it difficult to get through Walter.
-Steve
|
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 2012-03-15 11:39, Steven Schveighoffer wrote: > On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg <doob@me.com> wrote: >> I think object.d should be empty except for the definition of Object. >> The rest should be located in their own modules and publicly imported >> in object.d > > I think the compiler would have to change for that to happen. > > I would support such a change, but then again, it seems like we'd get > little measurable benefit for it, making it difficult to get through > Walter. > > -Steve Why would the compiler need to be changed for that? -- /Jacob Carlborg |
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Thu, 15 Mar 2012 06:47:00 -0400, Jacob Carlborg <doob@me.com> wrote:
> On 2012-03-15 11:39, Steven Schveighoffer wrote:
>> On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg <doob@me.com> wrote:
>>> I think object.d should be empty except for the definition of Object.
>>> The rest should be located in their own modules and publicly imported
>>> in object.d
>>
>> I think the compiler would have to change for that to happen.
>>
>> I would support such a change, but then again, it seems like we'd get
>> little measurable benefit for it, making it difficult to get through
>> Walter.
>>
>> -Steve
>
> Why would the compiler need to be changed for that?
Isn't full name of TypeInfo object.TypeInfo? Is that not hard-coded into the compiler?
-Steve
|
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 2012-03-15 11:52, Steven Schveighoffer wrote: > Isn't full name of TypeInfo object.TypeInfo? Is that not hard-coded into > the compiler? > > -Steve I have no idea if object.TypeInfo is hard-coded into the compiler. -- /Jacob Carlborg |
March 15, 2012 Re: Standalone AA implementation ready for review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu: > I think the built-in associative array must allow non-constant keys. As long as there's no memory safety issue, the AA should work with types that the user doesn't change for comparison purposes but can otherwise modify. > > A practical matter is that if we introduce this restriction we'll break a ton of code. Related to this I have one E.R.: http://d.puremagic.com/issues/show_bug.cgi?id=6253 Opinions welcome :-) Bye, bearophile |
March 15, 2012 Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 15/03/12 00:16, H. S. Teoh wrote:
> On Tue, Mar 13, 2012 at 09:30:45PM -0500, Andrei Alexandrescu wrote:
>> 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.
>
> Alright, I've finished the basic functionality of my AA implementation.
> I still haven't solved that problem with using suffixless string
> literals to index X[dstring], so you'll have to write aa["abc"d] instead
> of just aa["abc"]. But I thought I should post my code now so that
> people can take a look at it:
>
> https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d
>
> Currently, this code is still standalone, not integrated with druntime
> yet. Since that will require compiler changes and is potentially a very
> big change, I've decided to polish up the standalone version as much as
> possible before attempting druntime integration.
This is good, and very, very important. Do *not* make any attempt at compiler integration until it is *completely* ready.
This includes AA literals. They need to be accepted somehow. The compiler will give you syntax sugar and *nothing* more.
One possibility might be to accept a pair of array literals, representing keys and values.
Possibly it should call a CTFE function to convert them into some other form?
|
Copyright © 1999-2021 by the D Language Foundation