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.


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 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.


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


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.


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


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 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
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
next sibling 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
next sibling 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)) {} ?
 

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 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 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 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
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?
 

that you would use out of the expression (see my post for details)


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 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 ?


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
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 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 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
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 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=





 Why not using that for constraints ?





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

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


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

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 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