Templates in FPL?

[Fergus Henderson]

On 22-May-2001, Carl R. Witty <cwitty@newtonlabs.com> wrote:
> 
> I agree with Marcin about the bad points of templates.

Me too.  Marcin summed it up very well.
Of the five disadvantages that he mentioned,
I think at least three (lack of explicit interfaces,
incredibly complicated rules about name lookup,
and very poor error messages) are very serious problems.

For an example of the problems caused by the lack of explicit
interfaces, the C++ standards committee has still not
agreed on what the interface to vector is. The standard
is contradictory, because the vector<bool> specialization
doesn't obey the rules specified for vector<T>, and as yet
there's no concensus about which should be changed.

For an example of the problems caused by the complicated rules about
name lookup, just today someone posted a bug report for gcc 2.95.* to
gcc@gcc.gnu.org, reporting a problem where one of the standard library
templates didn't work when they had a typedef named `destroy' in their
code.  My guess is that it was probably because the standard library code
was using the function std::destroy(), but the standard library
implementor didn't realize that it had to be explicitly namespace
qualified; in other words, the rules were too complex and/or too
cumbersome for the standard library developer to understand and/or apply.

Marcin already posted a good example of a poor error message ;-)

> (I'd like to
> point out, though, that the idea that "adding new code can't change
> the meaning of a program" no longer holds in Haskell extended with
> overlapping type classes.)

Yes... hence overlapping type classes are EVIL! ;-) ;-) ;-)

;-)

> There are some very cool things about C++ templates; they are more
> powerful than you might suspect.
> 
> Basically, templates let you extend the compiler.  You get a primitive
> functional programming language, with which you can do basically
> arbitrary computations on types and on integers;
> In the functional programming language, you have conditionals, the
> usual arithmetic operations, pairing, recursion, etc.; basically, it's
> a real programming language (although a very annoying one -- the
> syntax is atrocious).

Right.  It wasn't designed for that purpose, it just turned out
that it could be used for it.  It's a bit like that simulation of
Conway's game of life in vi macros!  Makes for a very impressive
demo, but there are serious drawbacks to using such techniques in
day-to-day work.

I agree that it would be very nice if Haskell and other FPLs had some
equivalent feature, with a nicer syntax.  I think you might be able to
do a lot of it using ordinary Haskell syntax with just some additional
annotation that directs the compiler to evaluate part of the program at
compile time.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.