Imperative templates

[Jonathan M Davis]

On Sunday 17 July 2011 12:23:55 Robert Clipsham wrote:
> On 16/07/2011 23:36, Jonathan M Davis wrote:
> > You can actually do that a lot more simply than that:
> > 
> > template AlternateEven(T...)
> > {
> > 
> >      static if(T.length  == 0)
> >      
> >          alias TypeTuple!() AlternateEven;
> >      
> >      else static if(T.length  == 1)
> >      
> >          alias TypeTuple!(T[0]) AlternateEven;
> >      
> >      else
> >      
> >          alias TypeTuple!(T[0], AlternateEven!(T[2 .. $]))
> >          AlternateEven;
> > 
> > }
> 
> I didn't doubt there'd be a simpler way to write it, it was just a quick
> hack that I could use as an example. Didn't really wanna paste my huge
> real-world examples which I cited.
> 
> > But it is true that template metaprogramming is functional in nature. In
> > fact, I'd recommend reading this:
> > 
> > http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-t
> > o-do- with-c/
> 
> I'm subscribed to Bartosz's blog, I tend to find his posts are too long
> and in depth for me to read in the time I have available to me, which is
> unfortunate, as I'm interested in a lot of the things he posts.
> 
> > It talks about how template metaprogramming in C++ is very much like
> > Haskell, and even suggests essentially writing such templates as
> > Haskell first (primarily because Haskell's syntax is so clean and C++'s
> > template syntax is so insanely ugly). The basic concepts carry over to
> > template metaprogramming in D, since it's essentially the same problem
> > - we just have better syntax for it (so, designing your templates in
> > Haskell first really shouldn't be necessary, but the concepts covered
> > in that article would be good for you to go over).
> > 
> > Now, as for implementing templates in an imperative style... I don't
> > know how feasible that is. You're essentially asking for a CTFE
> > function which processes types. Instead of the type system handling it
> > all, you're trying to run arbitrary code which does it. It's not an
> > altogether unreasonable request, but I'd expect it to be a hard problem
> > to solve. It's probably something that should be considered, since it
> > would make life much easier for those who aren't familiar with how to
> > program with functional languages, but it would probably take a lot of
> > work to do, so I wouldn't expect it anytime soon.
> 
> That's exactly what I'm asking for - how can we claim the language
> supports all of the aforementioned idioms when you're forced to use one
> of them for operating on types? (Unless you use Timon's funky hack of
> course)

We support all of the the mentioned paradigms. But that doesn't mean that they 
all apply to templates. For instance, would concurrent programming apply to 
templates? You can program using all of the list paradigms, but template 
metaprogramming is its own beast, and its essentially functional by nature. 
Just because you can use a particular paradigm in normal code doesn't mean 
that it needs to be useable in template metaprogramming or that we can't claim 
that we support it. I can see why you would want to be able to template 
metaprogramming imperatively, but just because you can't doesn't mean that D 
isn't properly supporting imperative programming. It just means that its 
template metaprogramming features can't be used in that way.

- Jonathan M Davis