"Walter" <walter@digitalmars.com> wrote in message news:c3jo7a$q25$1@digitaldaemon.com...
>
> "Ben Hinkle" <bhinkle4@juno.com> wrote in message news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
> > yeah, I shouldn't have said "just because Java/C++ have one"... It's natural to want to add one, just as it is natural to want to add a String class of some sort. I really hope we can keep 90% of D code using dynamic arrays - no offense to Vector but multiple ways to do very similar things is a pain in the butt when writing APIs.
>
> One point I tried to make in my sdwest talk was I just did not like having arrays, Vectors, and Strings as separate types. They really should be the same thing, and it was a significant design goal of D to make them the
same
> (i.e., add sufficient power to arrays).

It's nice if it can be done. I'm skeptical that it can be done and, even if it can, whether that covers all the cases that will arise.

I've plenty of ideas for how to have these things built in. For example, a queue could be denoted by

    int [<<] q_of_ints;

Some possibilities for the operations:

    //
    q_of_ints.is_empty; // is empty?
    q_of_ints.length;     // number of items in queue
    q_of_ints.capacity; // current capacity

    // PUSH
    q_of_ints << 10; // pushes one on
    q_of_ints ~= 10;
    q_of_ints.push(10);

    //TOP
    int top_value = q_of_ints[0]; // other indexes are banned.
    int top_value = q_of_ints; // uses implicit conversion
    int top_value = q_of_ints.top;

    // POP
    <<= q_of_ints; // I don't really like this, and imagine it'll cause
ambiguous parsing anyway
    q_of_ints.pop();

There are other ideas I've had for other types, stacks, lists etc.

But I think we make a serious mistake to throw the baby out with the C++ bathwater. There is enormous flexibility in the fact that things are in libraries and not in language in C++. As I've said many times before, I'm highly skeptical that all such flexibility is achievable in D in the language. If that's true, then the last thing we want is to breed conflict between the language and one or more libraries. It makes much more sense to have things in libs to begin with if that's going to happen.

One example of this is the current Queue implementation. It uses a built-in array, and does smart shuffling/resizing to prevent the array growing indefinitely. Naturally, such a thing can become a policy to the template. If this was a built-in, how would the user specify such policies, without us having guts-out whitebox approach to the language constructs. We've achieved this with foreach in a nice way, but opApply() is still a little bit uncomfortably whitebox, especially given the use of ints for the loop control return values.

What I think is a sensible approach is to go for the libraries-focused approach first in DTL - though not doing things like my stupid Map blunder where they're completely unneeded - and then consider what we want built into the language. It's easier to change libraries than language, after all.

> You're right, though, that people coming from Java/C++ will look for a String or Vector and initially wonder why it isn't there. I'd like the collection classes in DTL to be more advanced things than what really
ought
> to be in the core language.

Agreed. There's also the fact that I believe we can support Java-like/runtime flexibility and STL-like/compile-time flexibility in one code base. I'm pretty confident that that is not achievable in language.

> I think we can show, using DTL, that D is more
> expressive with far less code than C++ STL.

That's the intention (and one of the main motivations).

> Anyone want to throw out ideas on collection types that would be cool in DTL?

Please do.

More:

int [] array_of_ints;
int [<<] queue_of_ints;    // The chevron denotes that things go in one
direction
int[<>] stack_of_ints;       //  the <> denotes in one way, out the other. I
also thought of [|<], and [|<>]
int<-> slist_of_ints;        // Singly-linked list
int<<->> dlist_of_ints;    // Doubly-linked list

I confess that I'm only really enamoured of the queue one. Better suggestions would be good for the other types, if they did indeed get into the language, rather than stay in libraries (as I think they should).

"Matthew" <matthew@stlsoft.org> wrote in message news:c3jpr6$sg2$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:c3jo7a$q25$1@digitaldaemon.com...
> >
> > "Ben Hinkle" <bhinkle4@juno.com> wrote in message news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
> > > yeah, I shouldn't have said "just because Java/C++ have one"... It's natural to want to add one, just as it is natural to want to add a String class of some sort. I really hope we can keep 90% of D code using dynamic arrays - no offense to Vector but multiple ways to do very similar things is a pain in the butt when writing APIs.
> >
> > One point I tried to make in my sdwest talk was I just did not like
having
> > arrays, Vectors, and Strings as separate types. They really should be
the
> > same thing, and it was a significant design goal of D to make them the
> same
> > (i.e., add sufficient power to arrays).
>
> It's nice if it can be done. I'm skeptical that it can be done and, even
if
> it can, whether that covers all the cases that will arise.
>
> I've plenty of ideas for how to have these things built in. For example, a queue could be denoted by
>
>     int [<<] q_of_ints;
>
> Some possibilities for the operations:
>
>     //
>     q_of_ints.is_empty; // is empty?
>     q_of_ints.length;     // number of items in queue
>     q_of_ints.capacity; // current capacity
>
>     // PUSH
>     q_of_ints << 10; // pushes one on
>     q_of_ints ~= 10;
>     q_of_ints.push(10);
>
>     //TOP
>     int top_value = q_of_ints[0]; // other indexes are banned.
>     int top_value = q_of_ints; // uses implicit conversion
>     int top_value = q_of_ints.top;
>
>     // POP
>     <<= q_of_ints; // I don't really like this, and imagine it'll cause
> ambiguous parsing anyway
>     q_of_ints.pop();
>
> There are other ideas I've had for other types, stacks, lists etc.
>
> But I think we make a serious mistake to throw the baby out with the C++ bathwater. There is enormous flexibility in the fact that things are in libraries and not in language in C++. As I've said many times before, I'm highly skeptical that all such flexibility is achievable in D in the language. If that's true, then the last thing we want is to breed conflict between the language and one or more libraries. It makes much more sense
to
> have things in libs to begin with if that's going to happen.
>
> One example of this is the current Queue implementation. It uses a
built-in
> array, and does smart shuffling/resizing to prevent the array growing indefinitely. Naturally, such a thing can become a policy to the template. If this was a built-in, how would the user specify such policies, without
us
> having guts-out whitebox approach to the language constructs. We've
achieved
> this with foreach in a nice way, but opApply() is still a little bit uncomfortably whitebox, especially given the use of ints for the loop control return values.
>
> What I think is a sensible approach is to go for the libraries-focused approach first in DTL - though not doing things like my stupid Map blunder where they're completely unneeded - and then consider what we want built into the language. It's easier to change libraries than language, after
all.
>
> > You're right, though, that people coming from Java/C++ will look for a String or Vector and initially wonder why it isn't there. I'd like the collection classes in DTL to be more advanced things than what really
> ought
> > to be in the core language.
>
> Agreed. There's also the fact that I believe we can support Java-like/runtime flexibility and STL-like/compile-time flexibility in one code base. I'm pretty confident that that is not achievable in language.
>
> > I think we can show, using DTL, that D is more
> > expressive with far less code than C++ STL.
>
> That's the intention (and one of the main motivations).
>
> > Anyone want to throw out ideas on collection types that would be cool in DTL?
>
> Please do.
>
>
>

> I haven't done much D yet, but...
> Aren't the typedefs like map_t.key_type and map_t.value_type good for
> generic programming, instead of hardcoding types using the built in
arrays?

Yes. All DTL containers will have an appropriate and complete set of member types.

> Or can you figure them out in a template which takes the assoc array's
type
> as a parameter?
>
> > >> What is the equivalent of Java's Vector in D?
> > >
> > >     Note that the Map's foreach returns key&value pairs, which the
> built-in
> > > assoc arrays do not, so we get to do this:
> > >
> > >
> > >    Map!(int, int).Map    m;
> > >    . . .
> > >    foreach(map_t.pair_type p; m)
> > >    {
> > >        printf("[%d]: %d ", p.key, p.value);
> > >    }
> >
> > they do, no need for that.
> >
> > int[int] m;
> > . . .
> > foreach(int key, int value ; m)
> > {
> > printf("[%d] %d\n", key, value);
> > }
> >
> >
> > I fail to see the necessity of Map at all...
>
> > I'll wait to see.
> >
> > >    foreach(int i; new IntRange(-20, +20, 2))
> >     foreach(int i; Range!(int)(-20, +20, 2))
> >
> > why is this better then:
> >
> >      for(int i=-20; i<20 ; i+=2)
> >
> >
> >
> > Ant
>
>

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
> On Sat, 20 Mar 2004 17:52:48 -0000, "Matthew" <matthew@stlsoft.org> wrote:
>
> >
> >"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:ggro5099etn7cu5i6c3skaairgvi7u25ib@4ax.com...
> >> On Sat, 20 Mar 2004 06:51:24 -0000, "Matthew" <matthew@stlsoft.org> wrote:
> >>
> >> >> What is the equivalent of Java's Vector in D?
> >> >
> >> >The DTL's Vector!! :)
> >>
> >> I should probably wait until DTL is more baked, but...
> >> why have a Vector class when we have dynamic arrays
> >> in D already?
> >
> >1. The length and capacity are clearly distinguished.
>
> The capacity of dynamic arrays is a pretty hot topic and there are several possible ways to support capacity without making a Vector class.

I'm a pragmatist, so took this opportunity to address it here, rather than wait - potentially for ever - for a resolution in the built-ins.

>
> >2. The containers will be bolt-ins (see
> >the other thread in which I talk about this "popular" technique), to
allow
> >them to subclass abstract container interfaces, or abstract classes, or
> >whatever you want/think appropriate, so that they can work with more
> >flexible
> >inheritance-based/runtime-polymorphic code just as well as with more
> >efficient/type-safe generic code.
>
> I'm trying to dig up those posts but I'm having trouble finding them... oh well. I'll wait for DTL.

Just search for "bolt-in"

> >3. They will all work with Ranges. Alas this is all still well up in the blue-skies as far as D goes. I've pretty much got it all worked out for
C++,
> >along with John Torjo - I've been doing the concepts and the
abstractions,
> >and John's been doing some mind bending things with filters. I *know* it
> >will
> >work for D because I worked it out on a bike ride a couple of weeks ago,
> >but I forgot it again before I could get to some paper, so it's a case of
> >arsing
> >around in code, or doing something else, until the code pixie comes by
and
> >whispers it in my ear again. <G>
> >
> >(Please don't be concerned if this sounds like the ravings of a madman: I
> >get the
> >majority of my ideas in this way, and they often tantalise me from afar
for
> >days/weeks
> >before I can crystalise them onto paper.)
>
> no problem. I know what you mean. I'll wait for more details.

I'm not the only nutter, then

> >> Unless there are really good reasons
> >> to have one we should avoid making a Vector class.
> >>
> >> I can imagine a couple of possible reasons for Vector:
> >> 1) Vector subclasses some abstract list class or
> >>    interface
> >
> >That will be possible, via the bolt-in mechanism
> >
> >> 2) Vector would use iterator classes to be consistent
> >>    with other classes in DTL
> >
> >DTL classes will all work with algorithms and built-in language features
in
> >the form of ranges/slices, rather than STL-like iterators.
>
> cool!

I hope so.

> >FYI, I'm going to try and complete the C++ Ranges stuff (for STLSoft;
JT's
> >doing a Boost version) before, so the concept's are clear, and then the D Range stuff should seem a lot clearer (if only because there'll be
something
> >concrete and proven to which people (including me) can refer).
> >
> >But we should have no issue using the DTL stuff thus far without any
concern
> >of Ranges, so I'll try and do the bolt-in stuff and post it shortly.
>
> ok.
>
> >> Without seeing DTL it's kindof hard to imagine
> >> satisfying 1 and 2 with "pure" dynamic arrays but
> >> I really hope we don't just add a Vector class
> >> because Java/C++ have one in their collections API.
> >
> >Not in the least.
>
> yeah, I shouldn't have said "just because Java/C++ have one"... It's natural to want to add one, just as it is natural to want to add a String class of some sort. I really hope we can keep 90% of D code using dynamic arrays - no offense to Vector but multiple ways to do very similar things is a pain in the butt when writing APIs.

Very true. But a language that needlessly restricts the expressiveness of its users will have fewer sooner.

Walter wrote:

> "Ben Hinkle" <bhinkle4@juno.com> wrote in message
> news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
> 
>>yeah, I shouldn't have said "just because Java/C++ have
>>one"... It's natural to want to add one, just as it is
>>natural to want to add a String class of some sort. I really
>>hope we can keep 90% of D code using dynamic arrays - no
>>offense to Vector but multiple ways to do very similar
>>things is a pain in the butt when writing APIs.
> 
> 
> One point I tried to make in my sdwest talk was I just did not like having
> arrays, Vectors, and Strings as separate types. They really should be the
> same thing, and it was a significant design goal of D to make them the same
> (i.e., add sufficient power to arrays).
> 
> You're right, though, that people coming from Java/C++ will look for a
> String or Vector and initially wonder why it isn't there. I'd like the
> collection classes in DTL to be more advanced things than what really ought
> to be in the core language. I think we can show, using DTL, that D is more
> expressive with far less code than C++ STL.
> 
> Anyone want to throw out ideas on collection types that would be cool in
> DTL?

Deque.

Cheers,
Sigbjørn Lund Olsen

"Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:c3jqq0$ts7$1@digitaldaemon.com...
> Walter wrote:
>
> > "Ben Hinkle" <bhinkle4@juno.com> wrote in message news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
> >
> >>yeah, I shouldn't have said "just because Java/C++ have one"... It's natural to want to add one, just as it is natural to want to add a String class of some sort. I really hope we can keep 90% of D code using dynamic arrays - no offense to Vector but multiple ways to do very similar things is a pain in the butt when writing APIs.
> >
> >
> > One point I tried to make in my sdwest talk was I just did not like
having
> > arrays, Vectors, and Strings as separate types. They really should be
the
> > same thing, and it was a significant design goal of D to make them the
same
> > (i.e., add sufficient power to arrays).
> >
> > You're right, though, that people coming from Java/C++ will look for a String or Vector and initially wonder why it isn't there. I'd like the collection classes in DTL to be more advanced things than what really
ought
> > to be in the core language. I think we can show, using DTL, that D is
more
> > expressive with far less code than C++ STL.
> >
> > Anyone want to throw out ideas on collection types that would be cool in DTL?
>
> Deque.

Already covered in List, since it has push_front/back, front/back, pop_front/back

Matthew wrote:
> "Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message
> news:c3jqq0$ts7$1@digitaldaemon.com...
> 
>>Walter wrote:
>>
>>
>>>"Ben Hinkle" <bhinkle4@juno.com> wrote in message
>>>news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
>>>
>>>
>>>>yeah, I shouldn't have said "just because Java/C++ have
>>>>one"... It's natural to want to add one, just as it is
>>>>natural to want to add a String class of some sort. I really
>>>>hope we can keep 90% of D code using dynamic arrays - no
>>>>offense to Vector but multiple ways to do very similar
>>>>things is a pain in the butt when writing APIs.
>>>
>>>
>>>One point I tried to make in my sdwest talk was I just did not like
> 
> having
> 
>>>arrays, Vectors, and Strings as separate types. They really should be
> 
> the
> 
>>>same thing, and it was a significant design goal of D to make them the
> 
> same
> 
>>>(i.e., add sufficient power to arrays).
>>>
>>>You're right, though, that people coming from Java/C++ will look for a
>>>String or Vector and initially wonder why it isn't there. I'd like the
>>>collection classes in DTL to be more advanced things than what really
> 
> ought
> 
>>>to be in the core language. I think we can show, using DTL, that D is
> 
> more
> 
>>>expressive with far less code than C++ STL.
>>>
>>>Anyone want to throw out ideas on collection types that would be cool in
>>>DTL?
>>
>>Deque.
> 
> 
> Already covered in List, since it has push_front/back, front/back,
> pop_front/back

Wonderful :-)

(Now you go release this)

Cheers,
Sigbjørn Lund Olsen

"Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:c3jvmd$14je$1@digitaldaemon.com...
> Matthew wrote:
> > "Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message news:c3jqq0$ts7$1@digitaldaemon.com...
> >
> >>Walter wrote:
> >>
> >>
> >>>"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
> >>>
> >>>
> >>>>yeah, I shouldn't have said "just because Java/C++ have one"... It's natural to want to add one, just as it is natural to want to add a String class of some sort. I really hope we can keep 90% of D code using dynamic arrays - no offense to Vector but multiple ways to do very similar things is a pain in the butt when writing APIs.
> >>>
> >>>
> >>>One point I tried to make in my sdwest talk was I just did not like
> >
> > having
> >
> >>>arrays, Vectors, and Strings as separate types. They really should be
> >
> > the
> >
> >>>same thing, and it was a significant design goal of D to make them the
> >
> > same
> >
> >>>(i.e., add sufficient power to arrays).
> >>>
> >>>You're right, though, that people coming from Java/C++ will look for a String or Vector and initially wonder why it isn't there. I'd like the collection classes in DTL to be more advanced things than what really
> >
> > ought
> >
> >>>to be in the core language. I think we can show, using DTL, that D is
> >
> > more
> >
> >>>expressive with far less code than C++ STL.
> >>>
> >>>Anyone want to throw out ideas on collection types that would be cool
in
> >>>DTL?
> >>
> >>Deque.
> >
> >
> > Already covered in List, since it has push_front/back, front/back, pop_front/back
>
> Wonderful :-)
>
> (Now you go release this)

It is a matter of a couple of days or so. No more. Walter's got the latest batch, but he's also got several new libs from me that've been waiting to go in for ages to contend with first.  I didn't want to release it before I'd done all the Range stuff, but now I think it's better to just get it out there, so it will be done in the next few days, I promise.

FYI: I've to deliver the final modifications on "Imperfect C++" tomorrow (US time), and have been faffing around on the evil Chapter 13 for days. When I was a student, I'd do almost anything before doing an assignment, even ironing clothes, so now I call this process "doing the ironing". These days, when I'm doing the ironing, it's usually on one of my more enjoyable projects, such as working on a CUJ column, or STLSoft, or DTL, or learning Ruby, or whatever.

The last few days' ironing have been the DTL, but now I've got about 32 hrs to go, it's panic stations, and so I am doing nothing but Ch 13 from now until it's done. But fear not, once Monday's gone, I'll be back to spreading myself around several things, and DTL is high on the list.

Matthew

Walter wrote:

>"Ben Hinkle" <bhinkle4@juno.com> wrote in message
>news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
>  
>
>>yeah, I shouldn't have said "just because Java/C++ have
>>one"... It's natural to want to add one, just as it is
>>natural to want to add a String class of some sort. I really
>>hope we can keep 90% of D code using dynamic arrays - no
>>offense to Vector but multiple ways to do very similar
>>things is a pain in the butt when writing APIs.
>>    
>>
>
>One point I tried to make in my sdwest talk was I just did not like having
>arrays, Vectors, and Strings as separate types. They really should be the
>same thing, and it was a significant design goal of D to make them the same
>(i.e., add sufficient power to arrays).
>
>You're right, though, that people coming from Java/C++ will look for a
>String or Vector and initially wonder why it isn't there. I'd like the
>collection classes in DTL to be more advanced things than what really ought
>to be in the core language. I think we can show, using DTL, that D is more
>expressive with far less code than C++ STL.
>
>Anyone want to throw out ideas on collection types that would be cool in
>DTL?
>
>
>  
>
Although D has many of the basic types in STL I think that not all possible uses will be though of in the language.  I think each type of collection needs a group of supporting functions in the STL under some standardised namespaces (so they are easy to find).  That is probably obvious.

As far as collections go, what about different types of algorithms for different applications?  Surely the one-shoe-fits-all approach does not work for things like maps/associative arrays.  Users often wish to have a choice about what type of sort they use.  Of course you don't want to go overboard here either.  Parhaps a way of hinting what type of algorithm you want to use and if it is not there STL would use the next best thing.


-- 
-Anderson: http://badmama.com.au/~anderson/

>>Anyone want to throw out ideas on collection types that would be cool in DTL?
>
>Although D has many of the basic types in STL I think that not all possible uses will be though of in the language.  I think each type of collection needs a group of supporting functions in the STL under some standardised namespaces (so they are easy to find).  That is probably obvious.

I agree if you mean DTL should contain supporting functions for
dynamic arrays and associative arrays instead of writing Vector
and Map classes. Plus it should contain more "esoteric" containers
like deque and linked lists (double and possibly single linked)
and sets, multiset and multimaps.
Ranges would be nice to throw in because they help with array
manipulation.


>As far as collections go, what about different types of algorithms for different applications?  Surely the one-shoe-fits-all approach does not work for things like maps/associative arrays.  Users often wish to have a choice about what type of sort they use.  Of course you don't want to go overboard here either.  Parhaps a way of hinting what type of algorithm you want to use and if it is not there STL would use the next best thing.

seems reasonable. I remember custom sort algorithms for associative arrays coming up before.