At 02:35 AM 5/24/2001 +1000, Fergus Henderson wrote:
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.
:) So true. In some ways, it sounds great: here we have a useful general-purpose feature that you can use for all kinds of things (a programming Swiss army knife, so to speak), and then build all kinds of _concrete_ useful things with it. Problem is that it doesn't allow you to redefine the syntax in any way. Thus, you can do compile-time assertions, computations, things like that, but the meaning of what you want to do often gets quite obfuscated by this syntax and by the contrived compiler error messages. I must say, though, that the beta compiler of MSVC 7 does a MUCH improved work on it.
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.
This is close to my personal vision. That is, a language that handles both run-time and compile-time computations seamlessly. Thus, the compiler would evaluate as much as it can, and then what's left is put in the executable. I assume that's something optimizing compilers for Haskell already do, at least in part. Problem is that, ideally, the language should allow the programmer to be explicit about things that should be done at compile-time and things that should be done at run-time, which Haskell doesn't quite have. Let's see how this could work: - IO actions must be executed at run-time, evidently. - We might be able to define another action monad (let's call it "CT", for compile-time) which defines just the opposite: an action that must be executed by the compiler. - We'd need a new primitive function: executeCompilerAction :: CT a -> a - And we'd need another: compilerEval :: a -> CT a So, let's say we want to force this program: main = print (fact 1000) to evaluate the factorial expression at compile-time. Then, we'd write something like: main = print (executeCompilerAction (compilerEval (fact 1000))) Of course, we'd eventually define any useful recurring patterns as new functions, as in here: eval a = executeCompilerAction (compilerEval a) Anyway, I don't know if I'm making much sense here. Just letting my brains fly on their own. Then, there's the explicit handling of types which templates allow and Haskell doesn't. I think that, the hardest part of Haskell that I'm having trouble with here is the way overloading is defined, using classes. I still have problems with that. Some times it is really obvious that it's best. Some other times, it really doesn't seem to fit (finding about the multi-parameter class extension was a very gratifying moment there). I can think of something that I don't know how to do in Haskell. Suppose that I have two classes, which I'll call Class1 and Class2: class Class1 a where func1 :: a -> Bool class Class2 a where ... (doesn't matter what goes here) And say that I want to express the fact that ALL types that are instances of Class2 will ALWAYS be instances of Class1, and will always return "False" from "func1". So, is there any way to express this kind of class-relationship in Haskell? It's not definitely inheritance, I think. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html