Advice about TcDeriv
Joachim Breitner
mail at joachim-breitner.de
Tue Aug 20 09:58:11 CEST 2013
Hi,
Am Dienstag, den 20.08.2013, 07:43 +0000 schrieb Simon Peyton-Jones:
> | Questions:
> | * Will this annotation have other, possibly unwanted effects?
>
> The role annotation will have exactly the *right* effect;
great.
> | * Should we also simplify constraints like (NT Age a) to (NT Int a)
> | automatically and built-in, or do we still want the user to first tell
> | us that we should do so?
>
> I think we should automatically simplify it.
ok, so in summary the user will never see instance declarations
referring to NT in any way, but just one function
castNT :: NT a b => a -> b
which will just do the right thing (or nothing at all).
> | * What about the “only do it if constructors are in scope” idea – if
> | the typechecker creates these instances on the fly, it might do so for
> | modules where the constructors are not in scope (either because they are
> | private, or simply because they have not been imported).
>
> It'll simplify (NT Age a) to (NT Int a) when, and only when, MkAge is
> in scope. So visibility of the data constructor says just when you
> want that instance to work. I think that seems fine to me.
I’m a bit uneasy about this; it means that one cannot export the ability
to do these casts without exposing everything.
Also it leads to a surprising behavior with regard to import lists:
Consider a module M which wants to use "castNT :: T -> [Int]" where
newtype T = T [Age]" is defined elsewhere. For this to work, I not only
have to "import ... (T(T))", but also "import ... (Age(MkAge))", even
though I don’t see anything about Age in my code.
Also, the typechecker will have to register a use of all these
constructors during typechecking – is there precedence for that?
I guess we can start with this more restricted, but definitely safe
variant and see how much it hinders practical use.
Greetings,
Joachim
--
Joachim “nomeata” Breitner
mail at joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nomeata at joachim-breitner.de • GPG-Key: 0x4743206C
Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130820/a5ea0e30/attachment.pgp>
More information about the ghc-devs
mailing list