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