== Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
> Sean Kelly wrote:
> > == Quote from bearophile (bearophileHUGS@lycos.com)'s article
> >> Walter Bright:
> >>> http://www.digitalmars.com/d/2.0/concepts.html
> >> They look nice (but I may use a bigger list of examples to understand how
they can be used). What
> > can they do that can't be done with the things already present?
> >
> > Nothing.  But it's a very convenient syntactic sugar on top of existing techniques, such as:
> >
> >
http://www.digitalmars.com/d/archives/digitalmars/D/Stroustrup_s_talk_on_C_0x_57104.html#N5737
> > 9
> >
> > Walter had even asked me to write an article about this, but I never followed through :p
> >
> > I will say that the __traits(compiles, blah) trick is totally awesome.  I was trying to do this in D 1.0 the other day and couldn't find a way to make it work.  Figures it would require D 2.0.  *sigh*
> DeeGirl's trick works in D 1.x doesn't it?
> I.e. a template function + is(typeof(thatTemplateFunction!(T)))

Not as far as I know.  This is the first thing I tried, and it gave me a compile error when the function couldn't be instantiated.


Sean

Lutger wrote:
> Whether this is compelling *for D* I don't know.

My general approach is unless compelling use cases can be found for D, it isn't worth implementing (because there are already many ideas with compelling use cases).

I think the jury will be out for 3 or 4 years for C++ concept maps as to whether the identified use cases are compelling or not.

Bill Baxter wrote:
> Still, anything containing __traits looks like an afterthought.

A bit.

> Also, I'm not sure how it's going to work in C++, but isn't the compiler going to have a hard time reporting errors in that kind of thing? Failure to instantiate could be because of a very minor typo in the big list of constraints.

True, you won't have an indication which failed. But you won't in C++, either, because the overload just won't be matched.

> I'm not sure how C++ will deal with that, but I think it's another place where concept maps help.  They introduce a little redundancy.  They give you a place to say "I think type X satisfies concept Y, and here's how".  That gives the compiler a place to say, "No you're wrong, type X does not satisfy concept Y because Foo isn't actually a method of X".  It seems like it should be possible to generate very readable error messages from that.

Because you can overload based on concepts, I don't see how the compiler can give an error message saying it failed to match part of a concept.

Sean Kelly wrote:
> == Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
>> Sean Kelly wrote:
>>> == Quote from bearophile (bearophileHUGS@lycos.com)'s article
>>>> Walter Bright:
>>>>> http://www.digitalmars.com/d/2.0/concepts.html
>>>> They look nice (but I may use a bigger list of examples to understand how
> they can be used). What
>>> can they do that can't be done with the things already present?
>>>
>>> Nothing.  But it's a very convenient syntactic sugar on top of existing
>>> techniques, such as:
>>>
>>>
> http://www.digitalmars.com/d/archives/digitalmars/D/Stroustrup_s_talk_on_C_0x_57104.html#N5737
>>> 9
>>>
>>> Walter had even asked me to write an article about this, but I never
>>> followed through :p
>>>
>>> I will say that the __traits(compiles, blah) trick is totally awesome.  I
>>> was trying to do this in D 1.0 the other day and couldn't find a way to
>>> make it work.  Figures it would require D 2.0.  *sigh*
>> DeeGirl's trick works in D 1.x doesn't it?
>> I.e. a template function + is(typeof(thatTemplateFunction!(T)))
> 
> Not as far as I know.  This is the first thing I tried, and it gave me a compile
> error when the function couldn't be instantiated.

Ok, so I guess the contents of thatTemplateFunction!(T) have to go in-line.  Which makes it a bit more of a pain.  But I think you can still achieve the same effect.

--bb

Dee Girl wrote:
> I hope this is not offensive. I said one that you focus on comparing
> D with C++ to much. And again you do the same with concepts.
> Comparison by any body else that you is ok. But if you do comparison
> is terrible. Makes you look second in run trying to reach first. You
> are not loser and do not want to look like loser. I study kyokushin
> karate 9 year. I was not good ^_^ but it was good for me. Sensei said
> many times best karate ka not compete with others. He compete with
> himself. Best fighter wants to do his best not only better than
> others. I understood him after years. I hope I express myself ok.

I understand your point, but I've often run into the sentiment "D looks great, but with C++0x coming I don't need D." So, some sort of comparison with C++0x is warranted.

I do hear you, though, which is why the article doesn't focus on C++, and the comparison is off on a separate page.


> One thing is also you implemented functionality in C++ concepts.
> Implementation is clever. But you do not bring original thing. You do
> what the C++ documentation does. Nothing else. It is not creative and
> not original. D is not C++ monkey. Stop looking at C++, do what you
> know is good; and you will be happy. Sorry, Dee Girl

You cannot do the isPrime() thing with Concepts.

Walter Bright wrote:
> Bill Baxter wrote:
>> Still, anything containing __traits looks like an afterthought.
> 
> A bit.
> 
>> Also, I'm not sure how it's going to work in C++, but isn't the compiler going to have a hard time reporting errors in that kind of thing? Failure to instantiate could be because of a very minor typo in the big list of constraints.
> 
> True, you won't have an indication which failed. But you won't in C++, either, because the overload just won't be matched.

Only true for C++ 'auto' concepts.
"""
The auto specifier means that any type which has a suitable operator<
will be considered LessThanComparable; if omitted, the user will have to explicitly state that her types meet the requirements of the concept using a concept map
"""

As I said after that, I'm thinking more about the non-auto case, where you specify a concept_map.

> 
>> I'm not sure how C++ will deal with that, but I think it's another place where concept maps help.  They introduce a little redundancy.  They give you a place to say "I think type X satisfies concept Y, and here's how".  That gives the compiler a place to say, "No you're wrong, type X does not satisfy concept Y because Foo isn't actually a method of X".  It seems like it should be possible to generate very readable error messages from that.
> 
> Because you can overload based on concepts, I don't see how the compiler can give an error message saying it failed to match part of a concept.

No, I mean when you have a concept_map the error can be generated at the point the concept_map is declared.  Telling the user the concept he thought he was implementing isn't being implemented.  I think in D you could do some variation of

   static assert(is(typeof(conceptStack!(Foo))),
                 "Foo doesn't implement Stack concept");

(using DeeGirl's template:
  void stackConcept(T)()
  {
      T t;
      T.value_type v = top(t);
      push(t, v);
      pop(t);
      if (empty(t)){}
  }
)

BUT the static assert will just tell you Foo does not qualify as a Stack, it won't tell you why.  Whereas the C++0x compiler with a concept map could tell you specifically what part of the concept is lacking.

But of course the main benefit of concept maps is that when I want to plug Vinces's Vector class into Larry's LinearSolver class all I have to do is specify how Vince's Vector satisfies Larry's VectorConcept.  And it doesn't matter if Vince overloaded opMul to mean dot product, but Larry expects a member named "dot".

Maybe if you haven't yet you could talk it over with Andrei.  My experience is that discussing things with you here on the NG is not all that productive because you only ever respond with one or two sentences, so that's all I'm going to say about this.

--bb

Bill Baxter wrote:
> But of course the main benefit of concept maps is that when I want to plug Vinces's Vector class into Larry's LinearSolver class all I have to do is specify how Vince's Vector satisfies Larry's VectorConcept.  And it doesn't matter if Vince overloaded opMul to mean dot product, but Larry expects a member named "dot".

You can do that with a proxy object.

> Maybe if you haven't yet you could talk it over with Andrei.  My experience is that discussing things with you here on the NG is not all that productive because you only ever respond with one or two sentences, so that's all I'm going to say about this.

I find it difficult to have productive discussions via email (even with Andrei). The upcoming D conference, however, will give everyone a chance for face-to-face.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g3mkb9$sel$2@digitalmars.com...

> I find it difficult to have productive discussions via email (even with Andrei). The upcoming D conference, however, will give everyone a chance for face-to-face.

Then use a newsgroup client ;)

Walter Bright wrote:
> Bill Baxter wrote:
>> But of course the main benefit of concept maps is that when I want to plug Vinces's Vector class into Larry's LinearSolver class all I have to do is specify how Vince's Vector satisfies Larry's VectorConcept.  And it doesn't matter if Vince overloaded opMul to mean dot product, but Larry expects a member named "dot".
> 
> You can do that with a proxy object.

A) How exactly?  If you're going to claim it's equivalent, I think the burden is on you to show an example of it.

B) Whatever you have in mind, my hunch is that it is going to be significantly more cumbersome.  For example in my code I like using Vince's Vector.  I like his API.  But if I go with proxy objects then I think that means either I have to use the proxy object (with Larry's API) instead of Vince's Vector directly, or else every time I call Larry's code I have to wrap my Vince Vector in a Larry VectorConcept proxy wrapper.  Either way it's not ideal, and more cumbersome than just writing down the mapping once in one central place.


>> Maybe if you haven't yet you could talk it over with Andrei.  My experience is that discussing things with you here on the NG is not all that productive because you only ever respond with one or two sentences, so that's all I'm going to say about this.
> 
> I find it difficult to have productive discussions via email (even with Andrei). The upcoming D conference, however, will give everyone a chance for face-to-face.

Everyone who can be there at least.  Anyway, I think you need to find someone who understands the ins and outs of C++0x concepts and discuss with them face-to-face whether your plan for D covers all the bases sufficiently or not.

--bb

Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g3mkb9$sel$2@digitalmars.com...
> 
>> I find it difficult to have productive discussions via email (even with Andrei). The upcoming D conference, however, will give everyone a chance for face-to-face.
> 
> Then use a newsgroup client ;) 

That isn't the answer. What's lacking is the face-to-face. There's just nothing like sitting around a table, with coffee and a notebook, and sketching things out.