Metaprogramming with Modern C++: The Haskell Metaphor

> Thats all! Simple, isn’t it? Here’s std::decay in the Turbo way:

  template< class T >
  struct decay {
      using U = tml::eval<std::remove_reference<T>>;
      
      using type = tml::eval<
		   tml::conditional<
				    std::is_array<U>,
				    tml::eval<std::remove_extent<U>>*,
				    tml::conditional<
						     std::is_function<U>,
						     std::add_pointer<U>,
						     std::remove_cv<U>
						    >
				   >
			    >;
  };

> I found it much more readable. What do you think?

I think:

1. Programming in XML notation is starting to look good, suddenly.

2.

  (def-compile-time-gizmo decay (x)
    (let ((u (remove-reference x)))
      (cond
        ((is-array u) (remove-extent u))
        ((is-function u) (add-pointer u))
        (t (remove-cv u)))))

3. Why isn't tml::conditional just called tml::if, if it (evidently) only takes three arguments: expr, then, else?

It's still the "obscure, magical, and freaking way to abuse the compiler it was at the beginning." It's just that the syntax for doing it has been improved. Just because term-rewriting systems are Turing complete doesn't mean one should program that way. Someday, someone may have to fix the code.

On the other hand, if you provide a full programming language, loops and all, at compile time, as LISP does, people go overboard with language extensions. LISP and PL/I were probably the last languages to go that far. There was a fad for "extensible languages" about 30 years ago, but it died out - programs were too hard to maintain.

I'm a full-time C++ programmer, and I keep up with the language pretty well, but I absolutely hate template meta-programming. We use it in parts of our codebase at work and I always dread when I have to interact with those parts of the code.

It's horribly ugly and verbose compared to other languages, like Lisp, that basically solve the same problem of computation at compile time. Even this library that supposedly cleans things up is pretty ugly as far as I'm concerned.

It's incredibly slow to compile. Somebody posted "Conway's Game of Life in TMP" the other day, and one of the template parameters was the number of frames to generate at compile time. I changed it from 3 to 10 and kicked off a compilation, and it ran for over 12 hours, used 10+ Gb of RAM, and still hadn't finished when I killed it the next day. I can do the same thing in Lisp, also at compile time, and it'll be a fraction of the code, easier to read, the same syntax as usual Lisp, and execute in negligible time for 10 frames.

And don't get me started on the error messages. Clang is pretty good, but it's still not good enough.

And the worst part of TMP is that due to the other problems with it, it's considered "black magic" by many people and so they don't bother learning it.

Until some of the problems are fixed, I don't think TMP will ever take off and become popular. It's just too hard to work with.

I guess I'm biased by writing a lot of Lisp in my free time lately. Lisp solved the same problem TMP is trying to solve, infinitely better, 50 years ago.

How much does a codebase have to be worth to justify programming like this?

It seems like if there's one or two guys, they'll just use haskell, or o'caml or f#, and skip this complexity.

I'm guessing a company must have 40-50 engineers, with one super critical execution path that must be separated out to support this style. Maybe 10% of the team has to interact with this style code? Maybe $5 mil in engineering labor - a $50 mil/year company?

Metaprogramming with Old C++: The Haskell Metaphor: https://github.com/mooseman/pdutils/blob/master/template_pse...