S.J.Thompson wrote:
Johannes - thanks for the pointer to this posting; would you have a concrete proposal to make on the basis of this for Haskell'?
Sort of an idea, but not fully worked out. Referring to http://www.haskell.org//pipermail/haskell-cafe/2005-June/010516.html I think I want to use exactly this implementation (class Figure, data EFigure) but hide the existence of EFigure (on the type level and on the data level) completely, by some syntax. E. g. a list of Figures could be written as [ Figure ], using the class name as a type name (for the special case where the class is unary). (This is what the Java people do but I am not sure whether this is a good idea in the Haskell context. Mixing types and classes, hm.) Also, when constructing objects of type EFigure, as in box :: Size -> EFigure ; box s = EFigure $ Box { ... } I want to omit the constructor EFigure, and the function should just read box :: Size -> Figure ; box s = Box { ... } This is the auto-boxing I was referring to in the subject of this mail. (We don't need auto-unboxing as we can have instance Figure EFigure, see the reference). While this is auto-boxing of function results (i. e. on exports), a more difficult question is, how should we do auto-boxing for function arguments (i. e. on imports). Assume f :: Foo -> Box and g : Figure -> Bar, is g ( f Foo ) OK? Probably yes, by translating to g ( EFigure ( f Foo ) ). But then what about f2 :: Foo -> [ Box ] and g2 :: [ Figure ] -> Bar. We would need g2 . f2 translated to g2 . fmap EFigure . f2 but of course at runtime, there should be no extra cost. (I'll have one more comment which I send in a separate message so that it shows up under its own header in the archive.) Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------