Yes, this will surely do the trick, thanks a lot! :-)
I got as far as defining a TypeEq class myself in one of my attempts, trying to trick the inference engine, but now seeing the full ingenuity of the TypeCast class I realize how far from the solution I really was. Again, thanks a million! /Niklas On 8/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> A value of any type should be embeddable inside a build expression > of any result type, i.e. a -> b or b -> a cannot hold on Embed in > general. It seems you might benefit from local functional dependencies, which are asserted per instance rather than for the whole class. They are explained in http://pobox.com/~oleg/ftp/Haskell/typecast.html Incidentally, that web page's source also gives an illustration of their use: http://pobox.com/~oleg/ftp/Haskell/typecast.hs The page itself is written in HSXML, which had to deal with a similar problem: in HSXML, 'p' is a polyvariadic function, which has to accept as many strings as the user cares to specify -- and in addition, arbitrary HSXML fragments like 'em', 'code', 'cite', etc. The latter are too built by polyvariadic functions. So, at some point I had to force the constraints and tell the functions that their arguments are over and they better give some data structure. Incidentally, that's where [] notation comes in quite handy. The brackets are not just the embellishment; by lucky accident, they actually force the constraints. BTW, the rendering of the above HSXML code checks local file links (and inserts the file sizes into the HTML code, while at it). There is a version of the HSXML rendering that, in addition to formatting Haskell code, passes it to a Haskell system to verify its typing -- and to optionally run it as well. The complete source code for the renderers is http://pobox.com/~oleg/ftp/Haskell/HSXML.tar.gz
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe