March 15, 2012
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
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
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
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
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
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
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
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
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
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?