On Tuesday, 9 June 2015 at 18:49:04 UTC, Brad Anderson wrote:
>  We also have map in the form of RedBlackTree. I think you might be able to use RedBlackTree for a set too but I haven't tried it.

You can, but it's a bit of a pain, because you have to keep passing it a tuple where the value gets ignored. We really need a wrapper around it to make it cleaner.

> I think RedBlackTree isn't a very good name though. It's long and is an implementation detail.

The decision was previously made to name the containers after what they actually are rather than what they're used for, and I still agree with that decision. However, I do think that we should have wrappers and aliases where appropriate (e.g. SortedMap could be an alias to RedBlackTree, and SortedSet could be a wrapper around RedBlackTree) in order to provide names which are based on what you use them for (rather than what they are) as folks frequently expectA nd in some cases (like SortedSet), it's pretty much necessary unless you have a lot of code duplication, since the same data structure is used for multiple container types, but the API needs to be slightly different to be truly user-friendly.

Regardless, I'm very much in favor of having the core container types be named after what they are rather than what they do, since I think that that often gets lost when it shouldn't.

- Jonathan M Davis

On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
>
> Please help me choose what to work on next.

Containers!

On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu wrote:
> Regarding projects that we discussed you are considering, I suggest we focus on putting std.container in good shape and opt for a redesign only if there are great benefits. Also, I think we should stay with libc-based I/O.

Honestly, I think that std.container's API is a very good start. The main problems lie with ranges. We need to make sure that all of the range-based functions are consistent (e.g. accepting Take!R, TakeOne!R, TakeExactly!R, etc. where R is the range type for that container - we do that to some extent, but we're not consistent about it), and we need to add more functions that don't use ranges - in particular, remove functions which remove keys or values without having to use a range to do it. Honestly, while it's flexible, it's not exactly the finest hour for ranges when you have to do something like

container.remove(container[].find(value).takeOne());

just to remove a value for the container. Most folks just want to do something like

container.removeFirst(value);

And containers are really the main place, I think, where iterators actually do better than ranges. So, while I definitely want the containers to continue to support ranges, I think that we should do a better job of having alternative functions which don't involve ranges if they don't need to for many of the basic cases. Then the simple cases won't have to use ranges just to do stuff like remove elements, and generic code and more complicated cases can use ranges as appropriate.

But in general, while I do think that some polishing is needed for the std.container API, I also think that it's a very solid start.

- Jonathan M Davis

On Tuesday, 9 June 2015 at 17:15:46 UTC, Dennis Ritchie wrote:
> On Tuesday, 9 June 2015 at 17:12:53 UTC, Liam McSherry wrote:
>> I think containers would be the better option. D sorely needs to have basics like (de)queues and stacks in the standard library, as well as any other popular and useful containers.
>
> And `set`.

We have it via RedBlackTree; it's just ugly to use, since you have to keep passing in tuples with values that are ignored. But with a convenience wrapper around RedBlackTree, that's easily fixed. So, we _do_ have it. It's just nowhere near as user-friendly as it should be.

- Jonathan M Davis

On Tuesday, 9 June 2015 at 21:20:14 UTC, Jonathan M Davis wrote:
> So, I think that it would make more sense if we std.container were completed than to embark on std.database.

I should probably add that since we already have std.container, doing containers next is a matter of polishing it and finishing it; it doesn't necessarily need a lot of bake time at this point. However, I expect that if we want a top-notch database implementation, it's going to need some bake time. So, while it might make sense to start bouncing around ideas on a database API to get that process started, it would make a lot more sense to focus on std.container first.

- Jonathan M Davis

A container similar to folly's small_vector would be great to have ( https://github.com/facebook/folly/blob/master/folly/docs/small_vector.md)

On 9 June 2015 at 18:11, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu wrote:
>
>> Regarding projects that we discussed you are considering, I suggest we focus on putting std.container in good shape and opt for a redesign only if there are great benefits. Also, I think we should stay with libc-based I/O.
>>
>
> Honestly, I think that std.container's API is a very good start. The main problems lie with ranges. We need to make sure that all of the range-based functions are consistent (e.g. accepting Take!R, TakeOne!R, TakeExactly!R, etc. where R is the range type for that container - we do that to some extent, but we're not consistent about it), and we need to add more functions that don't use ranges - in particular, remove functions which remove keys or values without having to use a range to do it. Honestly, while it's flexible, it's not exactly the finest hour for ranges when you have to do something like
>
> container.remove(container[].find(value).takeOne());
>
> just to remove a value for the container. Most folks just want to do something like
>
> container.removeFirst(value);
>
> And containers are really the main place, I think, where iterators actually do better than ranges. So, while I definitely want the containers to continue to support ranges, I think that we should do a better job of having alternative functions which don't involve ranges if they don't need to for many of the basic cases. Then the simple cases won't have to use ranges just to do stuff like remove elements, and generic code and more complicated cases can use ranges as appropriate.
>
> But in general, while I do think that some polishing is needed for the std.container API, I also think that it's a very solid start.
>
> - Jonathan M Davis
>



-- 
   -=Miles Stoudenmire=-
   miles.stoudenmire@gmail.com
   emiles@pitp.ca
   http://itensor.org/miles/

On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu wrote:
> Also, I think we should stay with libc-based I/O.

Um, won't this mean that the library then won't be usable by any application that will want to do more than a few simultaneous queries? Database engines usually concentrate on concurrency, not latency, so non-asynchronous I/O is only adequate for simple programs.

On 6/9/15 3:11 PM, Jonathan M Davis wrote:
> And containers are really the main place, I think, where iterators
> actually do better than ranges.

I think iterators would need to add huge value to warrant addition. -- Andrei

On 6/9/15 3:17 PM, Jonathan M Davis wrote:
> On Tuesday, 9 June 2015 at 21:20:14 UTC, Jonathan M Davis wrote:
>> So, I think that it would make more sense if we std.container were
>> completed than to embark on std.database.
>
> I should probably add that since we already have std.container, doing
> containers next is a matter of polishing it and finishing it; it doesn't
> necessarily need a lot of bake time at this point. However, I expect
> that if we want a top-notch database implementation, it's going to need
> some bake time. So, while it might make sense to start bouncing around
> ideas on a database API to get that process started, it would make a lot
> more sense to focus on std.container first.
>
> - Jonathan M Davis

Well what do you know. I got http://spottedtiger.tripod.com/D_Language/D_Support_Projects_XP.html going and have a branch with etc.c.odbc working like a charm. I'll submit that soon.

With regard to which to work on, I've made my decision: http://38.media.tumblr.com/c51baf89e2f85065d669f3080c2b5cdb/tumblr_inline_n3rsrwCCcQ1qj3ir1.jpg


Andrei

On Tuesday, 9 June 2015 at 22:05:27 UTC, Jonathan M Davis wrote:
> [snip]
>> I think RedBlackTree isn't a very good name though. It's long and is an implementation detail.
>
> The decision was previously made to name the containers after what they actually are rather than what they're used for, and I still agree with that decision. However, I do think that we should have wrappers and aliases where appropriate (e.g. SortedMap could be an alias to RedBlackTree, and SortedSet could be a wrapper around RedBlackTree) in order to provide names which are based on what you use them for (rather than what they are) as folks frequently expectA nd in some cases (like SortedSet), it's pretty much necessary unless you have a lot of code duplication, since the same data structure is used for multiple container types, but the API needs to be slightly different to be truly user-friendly.

I suppose an alias would be fine. I can't think of any other standard library that uses the actual data structures as the names. Doing it that way exclusively would be unfriendly to newcomers and downright hostile to people who never have (or have yet to) study computer science.

Thinking about it more I actually like the idea now of naming them by the data structure and using aliases. That would also open the possibility of relegating more sophisticated template argument container configuration options (bucket sizes, sparse/dense, etc.) to the data structure to which they apply and letting the container concept aliases be a sane default.