Templates in FPL?

[Juan Carlos Arevalo Baeza]

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