Imperative templates

[Robert Clipsham]

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

> Now, just for your general growth as a programmer, I'd suggest that you learn
> a functional language like Haskell. It definitely takes some getting use to,
> but there are some types of problems that are solved much more easily in a
> functional style, and having that in your programming toolbox would be of
> definite value to you (completely aside from the template metaprogramming
> issue).

I tried learning haskell once, I gave up due to time constraints and the 
lack of any projects to play with (I lose interest quick if there isn't 
code for me to play with/tweak to do something I wanna do). Having used 
it I frequently get annoyed with languages that don't have map/reduce, I 
don't doubt there's other cool idioms in there that I'd also get annoyed 
that other languages don't have too.

> So, I think that your request makes good sense as long as it can be reasonably
> implemented, but it's likely to take a lot of work to do it, and there may be
> some underlying issue that I don't see which makes it completely infeasible.
> So, it may happen, but it's the sort of thing that's likely to be a D3 feature
> if it every happens.

I wasn't really expecting anything to be done about it, just wondering 
if anyone else would find such a feature useful. Not that I'd complain 
if something like it was implemented! (I might even have a go at 
implementing it myself if someone came up with a reasonable syntax for 
it, the one I proposed has multiple issues with it).

> - Jonathan M Davis

-- 
Robert
http://octarineparrot.com/