On Mon, Jul 09, 2007 at 09:41:32PM +0100, Claus Reinke wrote:
hiding concrete types in existentials sometimes only defers problems
instead of solving them, but exposing class interfaces instead of types is a
useful way to mitigate that effect. it just so happens that this particular
reading existentials (or gadts, for that matter)
is an interesting problem. sometimes too interesting..
http://www.padsproj.org/
is a project that allows automated reading codde for even some
dependently-typed data. Perhaps it has something to offer for
automatic deriving of Read instances for
I'd like to be able to use MT to build a list like:
[MT (T1a,1), MT (T1b,3)]
And I'd like to read str with:
read $ show str
Substituting return (m) with return (MT m) leads to error messages
like: Ambiguous type variable `e' in the constraints
which is the important hint! the parser used for
which is the important hint! the parser used for 'read' depends on
the return type, but the existential type _hides_ the internal type
which would be needed to select a read parser.
forall e . (MyClass e, Show e, Read e) = MT (e,Int)
the 'Read' there ensures that we only inject types that
