www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What Does Haskell Have to Do with C++?

reply Jeremie Pelletier <jeremiep gmail.com> writes:
http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/

Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
its quite a read :)
Oct 22 2009
next sibling parent Justin Johansson <no spam.com> writes:
Jeremie Pelletier Wrote:

 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/
 
 Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
 its quite a read :)
Jeremie, you are a champion and a scholar. Thanks for changing the topic. Justin Johansson ;-) Whoops, typo, that semi was meant to be a full breve ;-) God damm it; just can't break the habit.
Oct 22 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jeremie Pelletier:

 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/
 Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
 its quite a read :)
I don't like the name "allSatisfy", I use the "All" named, that's similar to the templated function "all". And I don't remember if Phobos also defined an "Any" too (that uses || inside instead of &&). I use also a "Map" template, that's useful for example to cast all items of a tuple to a different type. I have defined "Filter" template too, but that's less useful. Regarding the variant shown in that blog post: template allSatisfy(alias F, T...) { static if (T.length == 1) { alias F!(T[0]) allSatisfy; } else { private enum bool tailResult = allSatisfy!(F, T[1..$]); enum bool allSatisfy = F!(T[0]) && tailResult; } } Why can't that be used in the same way as the template that inside defines the "allSatisfy" name only? Even if it contains another name, the "tailResult", the "allSatisfy" alias is there still... (In those situations as workaround I use a second allSatisfy_helper template, and the allSatisfy template just uses allSatisfy_helper.result. But it's not handy). Bye, bearophile
Oct 22 2009
prev sibling next sibling parent Max Samukha <spambox d-coding.com> writes:
On Thu, 22 Oct 2009 10:49:43 -0400, Jeremie Pelletier
<jeremiep gmail.com> wrote:

http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/

Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
its quite a read :)
template allSatisfy(alias Pred, T...) { foreach(t; T) if (!Pred!(t)) return false; return true; } Not that I disagree but something similar is doable now with CTFE + 'static' foreach hack. Of course you cannot return types, etc. template TypeTuple(A...) { alias A TypeTuple; } bool allSatisfy(alias pred, T...)() { foreach (i, _; T) { static if (!pred!(T[i])) return false; } return true; } template TypePred(T) { bool TypePred(U)() { return is(T == U); } } enum r = allSatisfy!(TypePred!bool, TypeTuple!(bool, bool, bool)); static assert(r); BTW, is Bartosz's code published anywhere and what is the license? It looks like I'm trying to do the same thing.
Oct 22 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Jeremie Pelletier wrote:
 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskel
-have-to-do-with-c/ 
 
 
 Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
 its quite a read :)
Yes, it is excellent. Two comments: (1) Bartosz's D examples make me seriously question 'static foreach' which is scheduled for implementation (bugzilla 3377). If implemented, it will be a source of frustration, since it will not be very usable inside templates. The ability to exit from a 'static foreach' is something which is possible with a 'return'-style syntax, but is not possible with the 'eponymous template hack'. (2) It seems pretty clear that we need to allow the eponymous trick to continue to work when more than one template member is present. I think everyone who's ever attempted template metaprogramming in D has proposed it!
Oct 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Jeremie Pelletier wrote:
 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskel
-have-to-do-with-c/ 


 Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
 its quite a read :)
Yes, it is excellent. Two comments: (1) Bartosz's D examples make me seriously question 'static foreach' which is scheduled for implementation (bugzilla 3377). If implemented, it will be a source of frustration, since it will not be very usable inside templates. The ability to exit from a 'static foreach' is something which is possible with a 'return'-style syntax, but is not possible with the 'eponymous template hack'.
I think breaking early out of a static foreach is not necessary (but indeed convenient) for writing good loops.
 (2) It seems pretty clear that we need to allow the eponymous trick to 
 continue to work when more than one template member is present. I think 
 everyone who's ever attempted template metaprogramming in D has proposed 
  it!
Yes, that was on the list for a long time. Bartosz even has participated to many related discussions. I'm surprised the article made it seem an unescapable matter of principles, when it clearly is a trivially fixable bug in the language definition. We discussed using "this" instead of the template's name, but that has a few ambiguity problems. Currently, we want to allow a template to define private symbols in addition to the eponymous trick (a term that Bartosz shouldn't have implied paternity of, sigh). Those private members would be accessible from inside the template's definition, but not from the outside. That would effectively remove the issue. Andrei
Oct 28 2009
parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Don wrote:
 Jeremie Pelletier wrote:
 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskel
-have-to-do-with-c/ 


 Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', 
 its quite a read :)
Yes, it is excellent. Two comments: (1) Bartosz's D examples make me seriously question 'static foreach' which is scheduled for implementation (bugzilla 3377). If implemented, it will be a source of frustration, since it will not be very usable inside templates. The ability to exit from a 'static foreach' is something which is possible with a 'return'-style syntax, but is not possible with the 'eponymous template hack'.
I think breaking early out of a static foreach is not necessary (but indeed convenient) for writing good loops.
 (2) It seems pretty clear that we need to allow the eponymous trick to 
 continue to work when more than one template member is present. I 
 think everyone who's ever attempted template metaprogramming in D has 
 proposed  it!
Yes, that was on the list for a long time. Bartosz even has participated to many related discussions. I'm surprised the article made it seem an unescapable matter of principles, when it clearly is a trivially fixable bug in the language definition.
Yes, looking at the compiler source, it doesn't look too difficult. The fact that something like this works: template foo(int X) { static if (bar!(X)) { const int foo = 57; } else { const char [] foo = "abc"; } } makes it pretty clear that the difficult part has already been done. I don't know what happens with template mixins, though. I hate template mixins (and I'm not convinced they're useful for anything, either).
 We discussed using "this" instead of the template's name, but that has a 
 few ambiguity problems. Currently, we want to allow a template to define 
 private symbols in addition to the eponymous trick (a term that Bartosz 
 shouldn't have implied paternity of, sigh). Those private members would 
 be accessible from inside the template's definition, but not from the 
 outside. That would effectively remove the issue.
 
 
 Andrei
Oct 29 2009
next sibling parent Kagamin <spam here.lot> writes:
Don Wrote:

 I don't know what happens with template mixins, though. I hate template 
 mixins (and I'm not convinced they're useful for anything, either).
Sometimes in C macros are used like template mixins in D.
Oct 29 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Oct 29, 2009 at 1:47 AM, Don <nospam nospam.com> wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Jeremie Pelletier wrote:
 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have=
-to-do-with-c/
 Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)',
 its quite a read :)
Yes, it is excellent. Two comments: (1) Bartosz's D examples make me seriously question 'static foreach' which is scheduled for implementation (bugzilla 3377). If implemented, it will be a source of frustration, since it will not b=
e
 very usable inside templates. The ability to exit from a 'static foreac=
h' is
 something which is possible with a 'return'-style syntax, but is not
 possible with the 'eponymous template hack'.
I think breaking early out of a static foreach is not necessary (but indeed convenient) for writing good loops.
 (2) It seems pretty clear that we need to allow the eponymous trick to
 continue to work when more than one template member is present. I think
 everyone who's ever attempted template metaprogramming in D has propose=
d
 =A0it!
Yes, that was on the list for a long time. Bartosz even has participated to many related discussions. I'm surprised the article made it seem an unescapable matter of principles, when it clearly is a trivially fixable=
bug
 in the language definition.
Yes, looking at the compiler source, it doesn't look too difficult. =A0Th=
e
 fact that something like this works:

 template foo(int X)
 {
 =A0 static if (bar!(X)) { const int foo =3D 57; }
 =A0 else { const char [] foo =3D "abc"; }
 }
 makes it pretty clear that the difficult part has already been done.

 I don't know what happens with template mixins, though. I hate template
 mixins (and I'm not convinced they're useful for anything, either).
I don't think there's a problem with template mixins. Templates for mixin purposes are not generally the eponymous variety. I don't think any of the eponymous magic comes into play when you mix-in a template. At least I don't see why it would. And I do think template mixins are useful. I've seen some pretty nifty things done where you pass in a template as an alias template parameter to a class, and then mix that in. That can be a pretty powerful way to create extensible classes (or structs even) without inheritance. --bb
Oct 29 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Jeremie Pelletier wrote:
 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskel
-have-to-do-with-c/ 


 Bartosz's second part of 'Template Metaprogramming Made Easy 
 (Huh?)', its quite a read :)
Yes, it is excellent. Two comments: (1) Bartosz's D examples make me seriously question 'static foreach' which is scheduled for implementation (bugzilla 3377). If implemented, it will be a source of frustration, since it will not be very usable inside templates. The ability to exit from a 'static foreach' is something which is possible with a 'return'-style syntax, but is not possible with the 'eponymous template hack'.
I think breaking early out of a static foreach is not necessary (but indeed convenient) for writing good loops.
 (2) It seems pretty clear that we need to allow the eponymous trick 
 to continue to work when more than one template member is present. I 
 think everyone who's ever attempted template metaprogramming in D has 
 proposed  it!
Yes, that was on the list for a long time. Bartosz even has participated to many related discussions. I'm surprised the article made it seem an unescapable matter of principles, when it clearly is a trivially fixable bug in the language definition.
Yes, looking at the compiler source, it doesn't look too difficult. The fact that something like this works: template foo(int X) { static if (bar!(X)) { const int foo = 57; } else { const char [] foo = "abc"; } } makes it pretty clear that the difficult part has already been done. I don't know what happens with template mixins, though. I hate template mixins (and I'm not convinced they're useful for anything, either).
My mock object library <http://dsource.org/projects/dmocks/> uses: mixin(method!("name", returnType, arguments...)); The implementation is a long and ugly string mixin. There's a bug that prevents you from implementing interface methods with aliases. If this were removed, I could replace the long and ugly string mixin with a very short string mixin and a short template mixin. Due to problems with .stringof, my current system usually fails for methods with templated arguments or return types (eg void filter(HashSet!(int) integers). Now that I think of it, I could probably make things better by using a forwarding function.
Oct 29 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Jeremie Pelletier wrote:
 http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskel
-have-to-do-with-c/ 


 Bartosz's second part of 'Template Metaprogramming Made Easy 
 (Huh?)', its quite a read :)
Yes, it is excellent. Two comments: (1) Bartosz's D examples make me seriously question 'static foreach' which is scheduled for implementation (bugzilla 3377). If implemented, it will be a source of frustration, since it will not be very usable inside templates. The ability to exit from a 'static foreach' is something which is possible with a 'return'-style syntax, but is not possible with the 'eponymous template hack'.
I think breaking early out of a static foreach is not necessary (but indeed convenient) for writing good loops.
 (2) It seems pretty clear that we need to allow the eponymous trick 
 to continue to work when more than one template member is present. I 
 think everyone who's ever attempted template metaprogramming in D has 
 proposed  it!
Yes, that was on the list for a long time. Bartosz even has participated to many related discussions. I'm surprised the article made it seem an unescapable matter of principles, when it clearly is a trivially fixable bug in the language definition.
Yes, looking at the compiler source, it doesn't look too difficult. The fact that something like this works: template foo(int X) { static if (bar!(X)) { const int foo = 57; } else { const char [] foo = "abc"; } } makes it pretty clear that the difficult part has already been done.
That sounds great. If you could operate the changes, that would be awesome. Walter and I had already agreed about the feature. Andrei
Oct 29 2009