www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - C++0x Concepts - Dead?

reply Walter Bright <newshound1 digitalmars.com> writes:
There are unconfirmed reports that this morning, the C++0x standards 
group in Frankfurt voted to kill Concepts.
Jul 13 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 13, 2009 at 5:33 PM, Walter
Bright<newshound1 digitalmars.com> wrote:

 There are unconfirmed reports that this morning, the C++0x standards group
 in Frankfurt voted to kill Concepts.


Oh, wow.
Jul 13 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 13, 2009 at 5:46 PM, Jarrett
Billingsley<jarrett.billingsley gmail.com> wrote:

 On Mon, Jul 13, 2009 at 5:33 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:

 There are unconfirmed reports that this morning, the C++0x standards group
 in Frankfurt voted to kill Concepts.


 Oh, wow.


I mean, really, I'm kind of speechless.

I thought they were supposed to be one of the killer features.
Jul 13 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:

 On Mon, Jul 13, 2009 at 5:46 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:

 On Mon, Jul 13, 2009 at 5:33 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:

 There are unconfirmed reports that this morning, the C++0x standards group
 in Frankfurt voted to kill Concepts.


 Oh, wow.


 
 I mean, really, I'm kind of speechless.
 
 I thought they were supposed to be one of the killer features.


You were at the wrong tense: -ing, not -er. :o)

Andrei
Jul 13 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 13, 2009 at 5:59 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Jarrett Billingsley wrote:

 On Mon, Jul 13, 2009 at 5:46 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:

 On Mon, Jul 13, 2009 at 5:33 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:

 There are unconfirmed reports that this morning, the C++0x standards
 group
 in Frankfurt voted to kill Concepts.


 Oh, wow.


 I mean, really, I'm kind of speechless.

 I thought they were supposed to be one of the killer features.


 You were at the wrong tense: -ing, not -er. :o)


Ahaha, good one :)

Yeah, what's the solution to a complex, incomprehensible language?
More complexity!
Jul 13 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:

 On Mon, Jul 13, 2009 at 5:59 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Jarrett Billingsley wrote:

 On Mon, Jul 13, 2009 at 5:46 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:

 On Mon, Jul 13, 2009 at 5:33 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:

 There are unconfirmed reports that this morning, the C++0x standards
 group
 in Frankfurt voted to kill Concepts.


 Oh, wow.


 I mean, really, I'm kind of speechless.

 I thought they were supposed to be one of the killer features.


 You were at the wrong tense: -ing, not -er. :o)


 
 Ahaha, good one :)
 
 Yeah, what's the solution to a complex, incomprehensible language?
 More complexity!


Speaking of which, I think D has reached the perfect shade with 
restricted templates. That is, after Walter fixes the related bugs...

Andrei
Jul 13 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Jarrett Billingsley wrote:

 On Mon, Jul 13, 2009 at 5:59 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 Jarrett Billingsley wrote:

 On Mon, Jul 13, 2009 at 5:46 PM, Jarrett
 Billingsley<jarrett.billingsley gmail.com> wrote:

 On Mon, Jul 13, 2009 at 5:33 PM, Walter
 Bright<newshound1 digitalmars.com> wrote:

 There are unconfirmed reports that this morning, the C++0x standards
 group
 in Frankfurt voted to kill Concepts.


 Oh, wow.


 I mean, really, I'm kind of speechless.

 I thought they were supposed to be one of the killer features.


 You were at the wrong tense: -ing, not -er. :o)


 Ahaha, good one :)

 Yeah, what's the solution to a complex, incomprehensible language?
 More complexity!


 
 Speaking of which, I think D has reached the perfect shade with 
 restricted templates. That is, after Walter fixes the related bugs...
 
 Andrei


... And gets rid of SFNAE... Seriously, with restricted templates, 
template specializations, static if, etc., SFNAE is about as bug-prone a 
"feature" as we have in the language.
Jul 13 2009
parent Jason House <jason.james.house gmail.com> writes:
Robert Fraser Wrote:


 ... And gets rid of SFNAE... Seriously, with restricted templates, 
 template specializations, static if, etc., SFNAE is about as bug-prone a 
 "feature" as we have in the language.


When reviewing Walter's recent blog on understanding templates, he pointed out
that D does not have SFINAE. I haven't played around with templates enough to
know if it all works as I'd expect or not.
Jul 14 2009
prev sibling next sibling parent reply BLS <windevguy hotmail.de> writes:
Walter Bright wrote:

 There are unconfirmed reports that this morning, the C++0x standards 
 group in Frankfurt voted to kill Concepts.


Who cares. Or, in other words ; do you consider D constraints as "can't 
life without" feature ?
(no offense.. just think it's not that remarkable)
Jul 13 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
BLS wrote:

 Walter Bright wrote:

 There are unconfirmed reports that this morning, the C++0x standards 
 group in Frankfurt voted to kill Concepts.


 
 Who cares. Or, in other words ; do you consider D constraints as "can't 
 life without" feature ?
 (no offense.. just think it's not that remarkable)


It's remarkable in that Concepts were considered the marquee feature of 
C++0x. I think that D constraints fill the same niche, but without any 
of the complexity of Concepts.
Jul 13 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 There are unconfirmed reports that this morning, the C++0x standards 
 group in Frankfurt voted to kill Concepts.


C++0x Concepts are too much complex for the advantages they offer.
Can't they replace Concepts with something similer like D constraints?

C++0x can also take a look at Haskell, where the idea of Concepts is done much
better :-)

Bye,
bearophile
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 C++0x Concepts are too much complex for the advantages they offer.
 Can't they replace Concepts with something similer like D constraints?


D (constraints) + (static if) + (pragma msg) can do everything that 
Concepts do but one thing - checking of the template body against the 
constraint. My opinion is the latter is of low importance.

Anyhow, Andrei suggested this a while back to them and was ignored.
Jul 14 2009
parent reply BLS <windevguy hotmail.de> writes:
Walter Bright wrote:

 D (constraints) + (static if) + (pragma msg) can do everything that 
 Concepts do but one thing - checking of the template body against the 
 constraint. My opinion is the latter is of low importance.


I have somehow the idea that D constraints and template specialization 
should merge.
Guess what I want to say is that instead of accepting the  compiler 
decision for template specialization  a constraints could be used for : 
"I am not the one who is able to fulfill your needs.. try this template 
instead."

template Foo(int N)
         if ( ( N & 1 _else_ FooOdd!(int N)... ) ) // or pattern matching
{
     ...
}
//not the world's best example, but guess it is showing the intention.
-- 
NO constraint, let Mr compiler decide which template fits. (old behavior)
Jul 15 2009
parent reply Christian Kamm <check ldc-commits.com> writes:
BLS Wrote:

 I have somehow the idea that D constraints and template specialization 
 should merge.


I also feel that specialization may just be a special case of constraints -
with the added benefit that implicit function template instantiation works.

Is there a difference between
template Foo(T : U) {} and 
template Foo(T) if(is(T : U)) {} ?
Jul 15 2009
next sibling parent BLS <windevguy hotmail.de> writes:
Christian Kamm wrote:

 BLS Wrote:

 I have somehow the idea that D constraints and template specialization 
 should merge.


 
 I also feel that specialization may just be a special case of constraints -
 with the added benefit that implicit function template instantiation works.
 


will see what Walter is thinking.
Maybe we can call that stuff later on ... meta generics ? Now serious , 
looking a bit ahead, complete templated decision trees are /at least/ 
imaginable.


 Is there a difference between
 template Foo(T : U) {} and 
 template Foo(T) if(is(T : U)) {} ?
 


erm, give me an hour or so.. :)
Jul 15 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Christian Kamm wrote:

 BLS Wrote:

 I have somehow the idea that D constraints and template specialization 
 should merge.


 
 I also feel that specialization may just be a special case of constraints -
 with the added benefit that implicit function template instantiation works.
 
 Is there a difference between
 template Foo(T : U) {} and 
 template Foo(T) if(is(T : U)) {} ?
 


Yes. Constraints determine the list of candidate template declarations, 
but do not participate in the partial ordering of candidates to 
determine the 'best' match.
Jul 15 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:h3lkec$2k1t$1 digitalmars.com...

 Christian Kamm wrote:

 BLS Wrote:

 I have somehow the idea that D constraints and template specialization 
 should merge.


 I also feel that specialization may just be a special case of 
 constraints -
 with the added benefit that implicit function template instantiation 
 works.

 Is there a difference between
 template Foo(T : U) {} and template Foo(T) if(is(T : U)) {} ?


 Yes. Constraints determine the list of candidate template declarations, 
 but do not participate in the partial ordering of candidates to determine 
 the 'best' match.


Pardon my ignorance, but...umm...what?
Jul 15 2009
parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message

 Yes. Constraints determine the list of candidate template declarations,
 but do not participate in the partial ordering of candidates to determine
 the 'best' match.




Nick Sabalausky wrote:

 Pardon my ignorance, but...umm...what?


Example:

class C {}

void foo(T)() if(is(T : Object)) {}
void foo(T)() if(is(T : C)) {}

void bar(T : Object)() {}
void bar(T : C)() {}

void main() {
  foo!(C)(); // error: ambiguous, (both are candidate, no ordering)
  bar!(C)(); // ok, (both are candidate, second bar more specialized)
}
Jul 15 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Christian Kamm" <kamm-incasoftware removethis.de> wrote in message 
news:h3mh71$185a$2 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> wrote in message

 Yes. Constraints determine the list of candidate template declarations,
 but do not participate in the partial ordering of candidates to 
 determine
 the 'best' match.




 Nick Sabalausky wrote:

 Pardon my ignorance, but...umm...what?


 Example:

 class C {}

 void foo(T)() if(is(T : Object)) {}
 void foo(T)() if(is(T : C)) {}

 void bar(T : Object)() {}
 void bar(T : C)() {}

 void main() {
  foo!(C)(); // error: ambiguous, (both are candidate, no ordering)
  bar!(C)(); // ok, (both are candidate, second bar more specialized)
 }


Well then it seems like the constraints version is both less useful and more 
verbose. Hmm, but I guess it does allow "match/not-match" to be determined 
by arbitrary compile-time expressions. Is there another benefit to the 
constraints that I'm missing?
Jul 16 2009
parent BCS <ao pathlink.com> writes:
Reply to Nick,


 Hmm, but I guess it does allow "match/not-match" to
 be determined by arbitrary compile-time expressions. Is there another
 benefit to the constraints that I'm missing?
 


Not that I know of (but that says very little :). It might be a good rule 
of thumb to never directly use the simple is(T:U) in a template constraint.
Jul 16 2009
prev sibling parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
 Christian Kamm wrote:

 Is there a difference between
 template Foo(T : U) {} and
 template Foo(T) if(is(T : U)) {} ?
 




Walter Bright wrote:

 Yes. Constraints determine the list of candidate template declarations,
 but do not participate in the partial ordering of candidates to
 determine the 'best' match.


Thanks for the explanation!

I expect the reason is that for constrained templates it is impossible to 
determine whether all valid template arguments for one would lead to a valid 
instantiation of another?
Jul 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Christian Kamm wrote:

 Christian Kamm wrote:

 Is there a difference between
 template Foo(T : U) {} and
 template Foo(T) if(is(T : U)) {} ?




 
 Walter Bright wrote:

 Yes. Constraints determine the list of candidate template declarations,
 but do not participate in the partial ordering of candidates to
 determine the 'best' match.


 
 Thanks for the explanation!
 
 I expect the reason is that for constrained templates it is impossible to 
 determine whether all valid template arguments for one would lead to a valid 
 instantiation of another?
 
 


That's a good technical reason, but I also felt that the current way 
just made intuitive sense.
Jul 16 2009
parent reply BLS <windevguy hotmail.de> writes:
Walter Bright wrote:

 Christian Kamm wrote:

 Christian Kamm wrote:

 Is there a difference between
 template Foo(T : U) {} and
 template Foo(T) if(is(T : U)) {} ?




 Walter Bright wrote:

 Yes. Constraints determine the list of candidate template declarations,
 but do not participate in the partial ordering of candidates to
 determine the 'best' match.


 Thanks for the explanation!

 I expect the reason is that for constrained templates it is impossible 
 to determine whether all valid template arguments for one would lead 
 to a valid instantiation of another?


 
 That's a good technical reason, but I also felt that the current way 
 just made intuitive sense.


The current Template specialization implementation is doing a best fit 
search anyway, so why constraints are not able to use the same mechanism. ?

So, instead of IFTI we should have EFTI*, driven by constraints.
*The name is rather confusing so "fuzzy templates" are probably better.

bearophile brings in several times Scala/OCAML like pattern matching. 
Why not using that for constraints ?

IMO the current D constraints implementation is nice and easy, but I 
thing there is much more hidden power in that idea.

Thanks for ignoring my ignorance..
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BLS wrote:

 The current Template specialization implementation is doing a best fit 
 search anyway, so why constraints are not able to use the same mechanism. ?


The template specialization method is based on types - but there's no 
way to look inside those types and specialize based on properties of 
those types. That's where constraints come in.

Constraints use a completely different matching method than the type 
parameters do. It makes intuitive sense to logically separate them, 
rather than to mix them up.



 bearophile brings in several times Scala/OCAML like pattern matching. 
 Why not using that for constraints ?


I have no idea how that works, though Bartosz has been looking into it.
Jul 16 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Jul 16, 2009 at 4:03 PM, Walter
Bright<newshound1 digitalmars.com> wrote:

 BLS wrote:

 The current Template specialization implementation is doing a best fit
 search anyway, so why constraints are not able to use the same mechanism. ?


 The template specialization method is based on types - but there's no way to
 look inside those types and specialize based on properties of those types.
 That's where constraints come in.

 Constraints use a completely different matching method than the type
 parameters do. It makes intuitive sense to logically separate them, rather
 than to mix them up.


Please, the last thing we need is to have *two* systems of template
specialization, one with best matching and one without.

I was thinking it'd be more intuitive if constraints - which are more
general - would be used to implement specialization.  That is,

template X(T: A, U: B)

would basically be syntactic sugar for

template X(T) if(is(T: A) && is(U: B))

Then you have only a single system of specialization and constraining
to worry about.  How would "best matching" work?  The compiler could
definitely be smart enough to pick apart the logical expression in the
constraint, I suppose, or constraints could be written as "if(c1, c2,
c3)" or something of the like.

Let's try to *simplify* metaprogramming and make things *orthogonal*
instead of tacking on features with no regard to the existing ones.
Jul 16 2009
next sibling parent reply aarti_pl <aarti interia.pl> writes:
Jarrett Billingsley pisze:

 Please, the last thing we need is to have *two* systems of template
 specialization, one with best matching and one without.
 
 I was thinking it'd be more intuitive if constraints - which are more
 general - would be used to implement specialization.  That is,
 
 template X(T: A, U: B)
 
 would basically be syntactic sugar for
 
 template X(T) if(is(T: A) && is(U: B))
 
 Then you have only a single system of specialization and constraining
 to worry about.  How would "best matching" work?  The compiler could
 definitely be smart enough to pick apart the logical expression in the
 constraint, I suppose, or constraints could be written as "if(c1, c2,
 c3)" or something of the like.
 
 Let's try to *simplify* metaprogramming and make things *orthogonal*
 instead of tacking on features with no regard to the existing ones.


Well, that's exactly what I proposed about one year ago:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77654

My proposal would make meta programing in D much more intuitive (because 
of using rules - not bunch of corner cases as it is today). 
Unfortunately almost no one from NG commented on that...

BR
Marcin Kuszczak
(aarti_pl)
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
aarti_pl wrote:

 My proposal would make meta programing in D much more intuitive (because 
 of using rules - not bunch of corner cases as it is today). 
 Unfortunately almost no one from NG commented on that...


Thank you, but I don't see in your proposal a method that can:

1. instantiate templates only if a value argument is prime or odd.

2. instantiate templates only on a type which supports addition and has 
the method foo.

Note that C++ Concepts could do (2) but could not do (1).
Jul 16 2009
parent reply aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:

 aarti_pl wrote:

 My proposal would make meta programing in D much more intuitive 
 (because of using rules - not bunch of corner cases as it is today). 
 Unfortunately almost no one from NG commented on that...


 
 Thank you, but I don't see in your proposal a method that can:
 
 1. instantiate templates only if a value argument is prime or odd.
 
 2. instantiate templates only on a type which supports addition and has 
 the method foo.
 
 Note that C++ Concepts could do (2) but could not do (1).


ad.1

template normalizedType((T U N : U[N=size_t]) && (N & 1))

As it is stated in proposal commas are only syntax sugar for more 
general form with '&&'.

ad.2.

This case is in fact the same as 1. Because of the fact that A, B, C <=> 
A && B && C, you can create expressions as you want just using second 
form with logical operators. In this case you should just use proper 
compile time reflection mechanism in D to get information about type 
properties.

BR
Marcin Kuszczak
(aarti_pl)
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
aarti_pl wrote:

 Walter Bright pisze:

 aarti_pl wrote:

 My proposal would make meta programing in D much more intuitive 
 (because of using rules - not bunch of corner cases as it is today). 
 Unfortunately almost no one from NG commented on that...


 Thank you, but I don't see in your proposal a method that can:

 1. instantiate templates only if a value argument is prime or odd.

 2. instantiate templates only on a type which supports addition and 
 has the method foo.

 Note that C++ Concepts could do (2) but could not do (1).


 
 ad.1
 
 template normalizedType((T U N : U[N=size_t]) && (N & 1))
 
 As it is stated in proposal commas are only syntax sugar for more 
 general form with '&&'.


How do you distinguish a type from an expression?



 ad.2.
 
 This case is in fact the same as 1. Because of the fact that A, B, C <=> 
 A && B && C, you can create expressions as you want just using second 
 form with logical operators. In this case you should just use proper 
 compile time reflection mechanism in D to get information about type 
 properties.


class C {
     int opAdd(C);
}

How would I write the parameter to accept any type that supports 
addition? I want to support int, float, C, etc., without having to 
exhaustively enumerate them.
Jul 16 2009
next sibling parent reply aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:

 aarti_pl wrote:

 Walter Bright pisze:

 aarti_pl wrote:

 My proposal would make meta programing in D much more intuitive 
 (because of using rules - not bunch of corner cases as it is today). 
 Unfortunately almost no one from NG commented on that...


 Thank you, but I don't see in your proposal a method that can:

 1. instantiate templates only if a value argument is prime or odd.

 2. instantiate templates only on a type which supports addition and 
 has the method foo.

 Note that C++ Concepts could do (2) but could not do (1).


 ad.1

 template normalizedType((T U N : U[N=size_t]) && (N & 1))

 As it is stated in proposal commas are only syntax sugar for more 
 general form with '&&'.


 
 How do you distinguish a type from an expression?


Type is in fact the same thing as reduced expression. Please look at 
grammar. Everything except first type is *OPTIONAL*. So in fact you need 
always look for ctexpr (compile time expression) until you find some 
logical or grouping operator.


 ad.2.

 This case is in fact the same as 1. Because of the fact that A, B, C 
 <=> A && B && C, you can create expressions as you want just using 
 second form with logical operators. In this case you should just use 
 proper compile time reflection mechanism in D to get information about 
 type properties.


 
 class C {
     int opAdd(C);
 }
 
 How would I write the parameter to accept any type that supports 
 addition? I want to support int, float, C, etc., without having to 
 exhaustively enumerate them.


I will give you another question instead :-)

How would you do currently in D?

(In fact I just forgot how to do it in D now :-) But give me current 
syntax and I will rewrite it in my syntax)

BR
Marcin Kuszczak
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
aarti_pl wrote:

 How would you do currently in D?


template (T) if (T.init + T.init)
{
}
Jul 16 2009
parent reply aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:

 aarti_pl wrote:

 How would you do currently in D?


 
 template (T) if (T.init + T.init)
 {
 }


in D1.0

template(T if typeof(T.init + T.init) == T)

or in D2.0

template(T if __traits(compiles, T.init + T.init))

I could mess something in above examples, but as you can see, getting it 
to work is not a problem of my syntax for templates. It is just a matter 
of using proper syntax for compile time reflection.

BR
Marcin Kuszczak
(aarti_pl)
Jul 16 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Aarti_pl,


 template(T if typeof(T.init + T.init) == T)


who ever said T + T == T? What if that is not needed?
Jul 16 2009
parent aarti_pl <aarti interia.pl> writes:
BCS pisze:

 Reply to Aarti_pl,
 

 template(T if typeof(T.init + T.init) == T)


 
 who ever said T + T == T? What if that is not needed?


That is the only way to do it in D1 AFAIK. In D2 you have 
__traits(compile, ).

But before you get into discussion, please read my point made to Walter: 
  possibility to get such a functionality is not and SHOULD NOT be 
connected with template instantiations, but rather with proper compile 
time reflection.

BR
Marcin Kuszczak
(aarti_pl)
Jul 16 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
aarti_pl wrote:

 Walter Bright pisze:

 aarti_pl wrote:

 How would you do currently in D?


 template (T) if (T.init + T.init)
 {
 }


 
 in D1.0
 
 template(T if typeof(T.init + T.init) == T)


D1 is closed to such enhancements, in any case, the ==T part is wrong. 
byte+byte==int, for example.



 or in D2.0
 
 template(T if __traits(compiles, T.init + T.init))
 
 I could mess something in above examples, but as you can see, getting it 
 to work is not a problem of my syntax for templates.


Ok, but it's hard to see why it is better.
Jul 16 2009
parent aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:

 aarti_pl wrote:

 Walter Bright pisze:

 aarti_pl wrote:

 How would you do currently in D?


 template (T) if (T.init + T.init)
 {
 }


 in D1.0

 template(T if typeof(T.init + T.init) == T)


 
 D1 is closed to such enhancements, in any case, the ==T part is wrong. 
 byte+byte==int, for example.


I don't want to dive into it. It has nothing to do with origins of this 
discussion. You asked - I answered :-)


 

 or in D2.0

 template(T if __traits(compiles, T.init + T.init))

 I could mess something in above examples, but as you can see, getting 
 it to work is not a problem of my syntax for templates.


 
 Ok, but it's hard to see why it is better.


So you suggest that advantage of "if constraint" is possibility to get 
compile time information about types?

In my opinion they are completely different concepts and they should be 
separated. In most cases messing two concepts together is wrong.

Advantages of my syntax are enumerated in my proposal. I will not repeat 
them here again.

BR
Marcin Kuszczak
(aarti_pl)
Jul 16 2009
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Walter Bright wrote:

 aarti_pl wrote:

 Walter Bright pisze:

 aarti_pl wrote:

 My proposal would make meta programing in D much more intuitive 
 (because of using rules - not bunch of corner cases as it is today). 
 Unfortunately almost no one from NG commented on that...


 Thank you, but I don't see in your proposal a method that can:

 1. instantiate templates only if a value argument is prime or odd.

 2. instantiate templates only on a type which supports addition and 
 has the method foo.

 Note that C++ Concepts could do (2) but could not do (1).


 ad.1

 template normalizedType((T U N : U[N=size_t]) && (N & 1))

 As it is stated in proposal commas are only syntax sugar for more 
 general form with '&&'.


 
 How do you distinguish a type from an expression?
 
 

 ad.2.

 This case is in fact the same as 1. Because of the fact that A, B, C 
 <=> A && B && C, you can create expressions as you want just using 
 second form with logical operators. In this case you should just use 
 proper compile time reflection mechanism in D to get information about 
 type properties.


 
 class C {
     int opAdd(C);
 }
 
 How would I write the parameter to accept any type that supports 
 addition? I want to support int, float, C, etc., without having to 
 exhaustively enumerate them.


That's actually pretty close to what I want, I want to support any type 
that has a field or readable property named key which field supports < 
and >=.  Since I want to include various integer types I can't require 
that it support opCmp.

The way I'd been wishing was that the built-in types supported the 
pre-defined operators, such as opCmp.  (I haven't tried, but if they do 
it doesn't seem to be documented.  Eventually I'll probably get around 
to trying, but so far it's a comment in the class header.)
(If you haven't guessed, even the current template system intimidates 
me, so I generally look for other ways to do things.  I'm especially 
intimidated, among the parts that I've looked at, by the rules for 
instantiation of a template type.  It probably takes me half an hour 
each time I do it, and I'm never certain I've done it correctly until 
the program either works or doesn't work.)

I REALLY appreciate syntactic regularity.  I like being able to leave 
out empty parentheses. And I'd really like it if things like opCmp were 
available for the built-in types (although, I don't think opCmp should 
be defined for the complex numbers).

Actually, I'd like it if one could build classes that inherited from the 
built-in types, also.  That would frequently be the cleanest way to do 
something.  I understand that this would be essentially implementing 
inheritance for structs, and there may be good reasons to not do this. 
But it would regularize the syntax markedly.  It would make it so that 
the main difference between classes and structs is that classes were 
referenced by handles, and structs were value types.

I don't THINK I've drifted far from the original point.  If I have, my 
appologies.  But where possible I feel that syntax should be made more 
regular.  And this includes being able to test classes, structs, and 
built-in types in templates using the same constructions.  Like opAdd or 
opCmp.  One often doesn't care what kind of thing one is checking, but 
only what features it possesses.  So there should be easy ways to check 
for the possession of those features.

I note that I'm not making a clear distinction between types and 
instances of types, but in D every instance should be an instance of 
some particular type.  I didn't explicitly mention expressions, but the 
definitions of delegates and pointers to functions involve 
expressions...so I'm not exactly certain where the boundary lies.

More on expressions:  if one allows type variables, and testing of type 
variables for features, then it becomes reasonable to allow expressions 
that combine those type variables (and probably type literals).  OTOH, 
even if those type expressions exist, it seems unlikely that the normal 
operations would be the desired ones.  One would be more likely to want 
expressions of the form "if v implements method m and has feature f, 
then ...".  I think this can probably already be done with static if and 
  traits, though I'm not sure if traits are available at compile time.

But HOW COMPLICATED DO YOU WANT TEMPLATE SPECIFICATION TO BE???

OTOH, most of the changes that I want are along the lines of 
regularizing syntax.  And I realize that they may be either too 
difficult or too costly in ways that aren't readily apparent to me. 
Like allowing structures to support inheritance, and having the 
overloaded operator names be accessible for the built-in types.  (And I 
haven't checked that yet.)
Jul 18 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Jarrett,


 I was thinking it'd be more intuitive if constraints - which are more
 general - would be used to implement specialization.  That is,
 
 template X(T: A, U: B)
 
 would basically be syntactic sugar for
 
 template X(T) if(is(T: A) && is(U: B))
 
 Then you have only a single system of specialization and constraining
 to worry about.  How would "best matching" work?  The compiler could
 definitely be smart enough to pick apart the logical expression in the
 constraint,


My thought on this is discard non `is(T:U)` terms and expand the expressions 
into a set of simple AND expressions:

- discard any template options where the expression fails
- replace all sub trees other than AND, OR and `is(T:U)` nodes with their 
evaluated value.
- expand to disjunctive normal form
(http://en.wikipedia.org/wiki/Disjunctive_normal_form)
- discard false disjuncts
- discard negated terms
- treat each disjunct or each template options as it's own specialization 
option and apply the current partial ordering rules.
Jul 16 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 Let's try to *simplify* metaprogramming and make things *orthogonal*
 instead of tacking on features with no regard to the existing ones.


Type matching cannot do what expression matching can do. You'd need a 
totally new syntax anyway to bring expression matching into the template 
type parameter list.
Jul 16 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright escribió:

 Jarrett Billingsley wrote:

 Let's try to *simplify* metaprogramming and make things *orthogonal*
 instead of tacking on features with no regard to the existing ones.


 
 Type matching cannot do what expression matching can do. You'd need a 
 totally new syntax anyway to bring expression matching into the template 
 type parameter list.


But don't bring expression matching into the template type parameter 
list, bring template type parameter list into expression matching!

...

Done!

is(...)

"if" in the template is more powerful than template parameters 
restrictions. Why use those restrictions? Having two things for almost 
the same thing is confusing.

Suppose you implement partial ordering with template constraints and 
drop the others. What things you couldn't do? (I need an example because 
I can't see it).
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:

 Suppose you implement partial ordering with template constraints and 
 drop the others. What things you couldn't do? (I need an example because 
 I can't see it).


How could I do partial ordering if one constraint expression accepts 
only "odd" integers? Remember that partial ordering is not done with the 
specific argument values, but with the general parameter ones.
Jul 16 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 How could I do partial ordering if one constraint expression accepts
 only "odd" integers? 


you wouldn't, but rather ignore that clause and mine the constraints that 
you would use out of the expression (see my post for details)
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 Reply to Walter,
 

 How could I do partial ordering if one constraint expression accepts
 only "odd" integers? 


 
 you wouldn't, but rather ignore that clause and mine the constraints 
 that you would use out of the expression (see my post for details)


Then aren't things getting just as, or even more, complicated?

My big beef with Concepts is it was 40 pages of specification. D's 
constraints are a couple lines of specification. To replace them, it 
needs to be significantly simpler, not just different.
Jul 16 2009
parent BCS <ao pathlink.com> writes:
Reply to Walter,


 BCS wrote:
 

 Reply to Walter,
 

 How could I do partial ordering if one constraint expression accepts
 only "odd" integers?
 


 you wouldn't, but rather ignore that clause and mine the constraints
 that you would use out of the expression (see my post for details)
 


 Then aren't things getting just as, or even more, complicated?
 


99% of the time nobody needs to worry about how exactly partial ordering 
works. 90% of the time* people don't need to worry about putting constraints 
in the if clause or in the argument list.

I'd much rather have more complexity on the thing I need 1% of the time than 
the thing I need 10%. And the the rules I proposed are arguably simpler than 
the partial ordering bit that it inherits wholesale from the current solution 
so it might not even be the hard part.

On top of that, they may also alow for fewer cases wher the partial ordering 
even comes into play.

*87.6% of statistics are made up on the spot.
Jul 16 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Jul 16, 2009 at 5:03 PM, Walter
Bright<newshound1 digitalmars.com> wrote:

 Jarrett Billingsley wrote:

 Let's try to *simplify* metaprogramming and make things *orthogonal*
 instead of tacking on features with no regard to the existing ones.


 Type matching cannot do what expression matching can do. You'd need a
 totally new syntax anyway to bring expression matching into the template
 type parameter list.


Wow, can you say "taken out of context?"  I proposed the *exact*
opposite.  Note:

template X(T: A, U: B)
would basically be syntactic sugar for
template X(T) if(is(T: A) && is(U: B))
Jul 16 2009
prev sibling parent reply BLS <windevguy hotmail.de> writes:
Walter Bright wrote:

 BLS wrote:

 The current Template specialization implementation is doing a best fit 
 search anyway, so why constraints are not able to use the same 
 mechanism. ?


 
 The template specialization method is based on types - but there's no 
 way to look inside those types and specialize based on properties of 
 those types. That's where constraints come in.
 
 Constraints use a completely different matching method than the type 
 parameters do. It makes intuitive sense to logically separate them, 
 rather than to mix them up.
 



Thanks for taking the time to answer ; But the question remains the same 
: _Why_ ? Constraints /have/ to use a completely different approach ?

("more intuitive than" is not ..ahem.. is not a good enough reason)


 

 bearophile brings in several times Scala/OCAML like pattern matching. 
 Why not using that for constraints ?


 
 I have no idea how that works, though Bartosz has been looking into it.


O well, I am pretty sure that bearophile is willing to give you any 
information you need  :)
Jul 16 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
BLS wrote:

 Thanks for taking the time to answer ; But the question remains the same 
 : _Why_ ? Constraints /have/ to use a completely different approach ?
 
 ("more intuitive than" is not ..ahem.. is not a good enough reason)


I think it is a very good reason. Of course, we can argue about if it is 
actually intuitive or not.
Jul 16 2009
parent reply BLS <windevguy hotmail.de> writes:
Walter Bright wrote:

 BLS wrote:

 Thanks for taking the time to answer ; But the question remains the 
 same : _Why_ ? Constraints /have/ to use a completely different 
 approach ?

 ("more intuitive than" is not ..ahem.. is not a good enough reason)


 
 I think it is a very good reason. Of course, we can argue about if it is 
 actually intuitive or not.


ok. but that's only  eye candy, no ?

The more I think about what constraints could do, the more I think we 
should have a third and forth look on 'em.

I think with constraints we hold the key for meta/meta programming in 
our hands.... otherwise I would not insist like I do now.
Jul 16 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BLS wrote:

 Walter Bright wrote:

 BLS wrote:

 ("more intuitive than" is not ..ahem.. is not a good enough reason)


 I think it is a very good reason. Of course, we can argue about if it 
 is actually intuitive or not.


 
 ok. but that's only  eye candy, no ?


Intuitive has a lot of benefits:

1. easy to learn
2. easy to use correctly
3. easy to spot mistakes
4. makes code look more attractive
5. less intimidating


I once drove a tractor that you stepped on the gas to stop it, and 
released the pedal to get it to go. I nearly drove the thing through the 
owner's boat. Missed it by about an inch.
Jul 16 2009
next sibling parent BLS <windevguy hotmail.de> writes:
Walter Bright wrote:

 BLS wrote:

 Walter Bright wrote:

 BLS wrote:

 ("more intuitive than" is not ..ahem.. is not a good enough reason)


 I think it is a very good reason. Of course, we can argue about if it 
 is actually intuitive or not.


 ok. but that's only  eye candy, no ?


 



 
 I once drove a tractor that you stepped on the gas to stop it, and 
 released the pedal to get it to go. I nearly drove the thing through the 
 owner's boat. Missed it by about an inch.


OK!, this  argument is simply _too_ good.  have.....to........give..up
Jul 16 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 BLS wrote:

 Walter Bright wrote:

 BLS wrote:

 ("more intuitive than" is not ..ahem.. is not a good enough reason)


 I think it is a very good reason. Of course, we can argue about if it 
 is actually intuitive or not.


 ok. but that's only  eye candy, no ?


 
 Intuitive has a lot of benefits:
 
 1. easy to learn
 2. easy to use correctly
 3. easy to spot mistakes
 4. makes code look more attractive
 5. less intimidating
 
 
 I once drove a tractor that you stepped on the gas to stop it, and 
 released the pedal to get it to go. I nearly drove the thing through the 
 owner's boat. Missed it by about an inch.


On a visit to London, there was a guy in a very circulated pedestrian 
area downtown who challenged people to ride a bicycle that had reverted 
steering - you'd have to turn the steering to the left to veer right. 
He'd challenge people 5 pounds to only ride the bike straight for a few 
yards (no need to even pedal, just push it once). He'd demonstrate how 
to do it first.

He made $35 only as I ate a pizza watching.


Andrei
Jul 17 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
BLS:

 bearophile brings in several times Scala/OCAML like pattern matching. 
 Why not using that for constraints ?


 
 I have no idea how that works, though Bartosz has been looking into it.


 
 O well, I am pretty sure that bearophile is willing to give you any 
 information you need  :)


Pattern matching is handy and it can be powerful, for example I've seen OCaML
code that uses it to implement a AVL search tree in about 15 lines of code. But
probably it also adds lot of complexity to a language like D, so there are more
important things to add to D2 now (like good concurrency).

Bye,
bearophile
Jul 16 2009
parent reply BLS <windevguy hotmail.de> writes:
bearophile wrote:

 BLS:

 bearophile brings in several times Scala/OCAML like pattern matching. 
 Why not using that for constraints ?


 I have no idea how that works, though Bartosz has been looking into it.


 O well, I am pretty sure that bearophile is willing to give you any 
 information you need  :)


 
 Pattern matching is handy and it can be powerful, for example I've seen OCaML
code that uses it to implement a AVL search tree in about 15 lines of code. But
probably it also adds lot of complexity to a language like D, so there are more
important things to add to D2 now (like good concurrency).
 
 Bye,
 bearophile


I see your point... you are doing bio informatics..so speed matters.. 
for me the things are a bit different...

But I guess that you'll agree with me that Scala pattern matching has a 
reasonable syntax. (Not necessarily talking about "How difficult is it 
from a compiler author's view)

object MatchTest2 extends Application {
   def matchTest(x: Any): Any = x match {
     case 1 => "one"
     case "two" => 2
     case y: Int => "scala.Int"
   }
   println(matchTest("two"))
}
Jul 16 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
BLS:

 I see your point... you are doing bio informatics..so speed matters.. 
 for me the things are a bit different...


Bioinformatics doesn't matter much here. One of the PCs I use has a CPU with 4
cores plus about a ~$100 3D card (that can be programmed with CUDA to produce
spectacular programs, I have seen demos run on this PC that almost scare me,
like this one: http://www.youtube.com/watch?v=RqduA7myZok  and this is a
low-end 3D card: there are cards that probably have 3-6X more computing power),
when I write normal D1 code today I am probably using 10-30% of such computing
power. Compared to such "waste" even the performance gain of LDC over DMD is
small.

A sufficiently determined programmer can learn CUDA for the GPU and do all the
low level multithread programming you want on the CPU, to find ways to use most
of that computing power. But something similar can be said about programming in
assembly too. I'm willing to lose 20% of efficiency if the language (future D2)
will give me handy&safe ways to use the other cores of the CPU and maybe even
to use the GPU too at the same time (see OpenCL). Tapping some percentage of
that CPU+GPU power in a handy enough way is today quite important.



 But I guess that you'll agree with me that Scala pattern matching has a 
 reasonable syntax. (Not necessarily talking about "How difficult is it 
 from a compiler author's view)
 
 object MatchTest2 extends Application {
    def matchTest(x: Any): Any = x match {
      case 1 => "one"
      case "two" => 2
      case y: Int => "scala.Int"
    }
    println(matchTest("two"))
 }


Scala pattern matching, when used for simple/medium things, is simple to read
and understand (when you use it for complex things it quickly becomes hard to
understand).
But beside the extra syntax, if you want to add pattern matching to D2
(OCaML-style pattern matching may be more fit for D2, because it probably has a
higher performance at run-time and it's closer to the style of C++-like
languages where as much as possible is done at compile-time) you probably need
a more complex type system, and adding such improved type system to D2 looks
like a too much big work now (and it increases complexity of other things too,
I fear). That's why I have stopped for long time asking to add a built-in
pattern matching to D, even if I can't deny it's sometimes handy.

Bye,
bearophile
Jul 16 2009
prev sibling parent Witold Baryluk <baryluk smp.if.uj.edu.pl> writes:
Dnia 2009-07-17, pi=C4=85 o godzinie 02:32 +0200, BLS pisze:

 bearophile wrote:

 BLS:

 bearophile brings in several times Scala/OCAML like pattern matching=










.=20

 Why not using that for constraints ?


 I have no idea how that works, though Bartosz has been looking into i=








t.

 O well, I am pretty sure that bearophile is willing to give you any=20
 information you need  :)


=20
 Pattern matching is handy and it can be powerful, for example I've seen=




 OCaML code that uses it to implement a AVL search tree in about 15 lines o=
f code. But probably it also adds lot of complexity to a language like D, s=
o there are more important things to add to D2 now (like good concurrency).

=20
 Bye,
 bearophile


=20
 I see your point... you are doing bio informatics..so speed matters..=20
 for me the things are a bit different...
=20
 But I guess that you'll agree with me that Scala pattern matching has a=20
 reasonable syntax. (Not necessarily talking about "How difficult is it=20
 from a compiler author's view)
=20
 object MatchTest2 extends Application {
    def matchTest(x: Any): Any =3D x match {
      case 1 =3D> "one"
      case "two" =3D> 2
      case y: Int =3D> "scala.Int"
    }
    println(matchTest("two"))
 }
=20
=20


Hi,

I will point you into two projects:
Prop: http://www.cs.nyu.edu/leunga/prop.html (C++)
Tom: http://tom.loria.fr/wiki/index.php5/Main_Page (multi language)

Both are source-to-source translators.

First is imho nicer (considering syntax), but not maintained.

I'm thinking now about implementing similar thing for D (especially
that I'm also working with Erlang, and some symbolic data and
expressions in D). Or adding D support to Tom (but it is ugly)

Nemerle have also interesting pattern matching.

PS. There is also project called App for C++ pattern matching, but
cant find info now.
Jul 17 2009
prev sibling next sibling parent reply Christian Kamm <check ldc-commits.com> writes:
Walter Bright Wrote:

 There are unconfirmed reports that this morning, the C++0x standards 
 group in Frankfurt voted to kill Concepts.


This seems to be the relevant pre-Frankfurt text:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf

I doubt concepts are 'dead' - from the rumors you've heard it sounds likely 
the 'decoupled' or 'semi-decoupled' option was chosen.
Jul 14 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Christian Kamm:

 This seems to be the relevant pre-Frankfurt text:
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf



C++ as a language has competition -- from high-level runtimes such as
JavaScript, .NET etc; from hardware such as graphics accelerators; and from C
and Objective C.  Ideally, the pace of overall C++ feature development should
be such as to maintain C++’s competitive position against such alternatives.<


Despite the performance of the Chrome V8 JS JIT, JavaScript isn't much a
competitor to C++, they have different purposes and kind of programmers.

And graphics accelerators do little by themselves, they are there to be used
from C++ too, if for example C++ improves its support for OpenCL and similar
things.

"C++ feature development" sounds a little scary if you think about the too much
complex implementation of lambda functions in C++0x... (And such kind of
"developments" will not help C++0x face any competition from JavaScript, it's
like nailing a second bigger cannon on a large tank to help it fight better
against an infestation of mice).

Bye,
bearophile
Jul 14 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Christian Kamm:

 Is there a difference between
 template Foo(T : U) {} and 
 template Foo(T) if(is(T : U)) {} ?


I think if() offers better error messages here (I have not tried it in this
case, so I may be wrong).
Even if I am right, it's not inevitable, GCC shows to give better error
messages (better == the first line of error shows the line number where you
have tried to instantiate the template).

See also:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=92766

I have tried to ask this (simple?) but handy feature to LDC developers, but
they have answered me that it's something that has to be done by the front-end
(by Walter, mostly), so it's not something LDC devs want to to add just to LDC
for me :-)

Bye,
bearophile
Jul 15 2009
prev sibling parent Tim Matthews <tim.matthews7 gmail.com> writes:
On Mon, 13 Jul 2009 14:33:56 -0700
Walter Bright <newshound1 digitalmars.com> wrote:


 There are unconfirmed reports that this morning, the C++0x standards 
 group in Frankfurt voted to kill Concepts.


Something that viewers may alos like. Didn't see this posted anywhere
else here:
http://www.reddit.com/r/programming/comments/93j7u/bjarne_stroustrup_discusses_the_remove_concepts/
Jul 22 2009