Existential types: want better syntactic support (autoboxing?)

[Johannes Waldmann]

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/ -------