On 10/06/2004, at 3:29 AM, Mike Aizatsky wrote:
thanks for your time to look into the HList paper.
It's quite good. It reminds me the quirks Alexandrescu does in his "Modern C++ Design" or here http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html . Since type system allows implementation of natural arithmetic, do you know, is it Turing-complete?
I don't know whether it's Turing complete, but if you're more interested in how to (ab?)use type classes to perform computations, see a paper named "Fun with Functional Dependencies": http://www.cs.chalmers.se/~hallgren/Papers/wm01.html That shows how you use multi-parameter type classes and functional dependencies to create full functions in the type system. Once you understand that, you might be able to wrap your head around this example: http://www.haskell.org/hawiki/SimulatingDependentTypes which shows how to create an AVL tree data type, with which it is impossible write a function that can unbalance the tree. There is also a very interesting paper posted to the main Haskell mailing list only a few days ago: http://www.eecs.harvard.edu/~ccshan/prepose/ which shows (amongst other things) how to reify _any_ value to a type, i.e. create a new type which represents that (and only that) particular value in the type system, and how to "round-trip" that unique type back to the value it originally came from. I'm not sure if you're interested in type wizardry, but it shows a very impressive amount of static computation that you can do with the type system at compile-time.
The only issue is to get rid of AnyMyInterface around the code. Can you explain me why
Hmm, what's the higher goal of what you're trying to achieve? I, like you, came from a background of object-oriented programming, and I've always managed to avoid making a list containing more than one type after re-thinking about the problem. You can do it, sure, but the typical reasons for doing so in Haskell are very different from doing this in, say, Java. -- % Andre Pang : trust.in.love.to.save