[ghc-steering-committee] Proposal #23: instance force

Simon Peyton Jones simonpj at microsoft.com
Thu Apr 27 22:56:46 UTC 2017


I'm afraid I don't like this either.

I think of it like this.  It's like functional dependencies.  With fundeps, if you have
	class C a b | a -> b
	instance C Int Bool

and you have a "wanted" constraint (C Int t), then you add a new "wanted" constraint (t ~ Bool).  With luck that forces t to be Bool (maybe it's a unification variable right now) and you can solve with the instance decl.

This proposal say if you have
	instance force C Int Bool

and you have a "wanted" constraint (C ty1 ty2), then add the wanted constraints (ty1 ~ Int) and (ty2 ~ Bool).  Very similar in flavour and mechanism. No need to do this ill-specified "change the type of imported functions" stuff.

It'd work fine for
	instance force C [a]
too, which the proposal doesn't allow.  That could mean (like fundeps) that if you have a "wanted" (C ty) then you get a new wanted (ty ~ [alpha]) where alpha is a fresh unification variable.  That is, you are constraining the shape of the argument to C.


But still I don't like it much.  I don't understand this business of "C is effectively not in scope".  I'm sure it won't be long before someone wants to export/import these 'instance force' decls.  And yes it does have a funny overlap with the existing 'default' mechanism.

Overall I think it's defensible, but doesn't pay its way in cost/benefit terms.

Simon

| -----Original Message-----
| From: ghc-steering-committee [mailto:ghc-steering-committee-
| bounces at haskell.org] On Behalf Of Manuel M T Chakravarty
| Sent: 26 April 2017 12:46
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] Proposal #23: instance force
| 
| We need to decide whether we like to accept the ”instance force"
| proposal:
| 
| 
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fghc-proposals%2Fghc-
| proposals%2Fpull%2F23&data=02%7C01%7Csimonpj%40microsoft.com%7Ce91dc04dd2
| df4d1730aa08d48c99ca38%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63628
| 8039526075481&sdata=MKBjrTGX4kdlvBJMQeVzUxg2d%2BXBBHAlUS4FfEIPc5I%3D&rese
| rved=0
| 
| While I understand and am in favour of the motivation behind the
| proposal, I like to propose to reject the proposal in its current form.
| 
| My reasons are the following:
| 
| * The proposal is an ad hoc approach to adding additional type
| constraints to qualified types involving a specific type class.
| 
| * I am against adding the proposed ”instance force” declaration form as
| its *main* motivation is to simplify error messages and type signatures
| printed by GHCi — i.e., it is of a diagnostic and informative nature.
| 
| * Something like that does IMHO not belong into the language, but needs
| to be part of the configuration of the compilation system. In other
| words, it ought to be a, e.g., compiler option or a language pragma, but
| not a declaration form.
| 
| In summary, I’d like to suggest to find an alternative means to get GHC
| to add the additional constraints to simplify diagnostics and type
| queries without encumbering the language itself.
| 
| Cheers,
| Manuel
| 
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
| https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


More information about the ghc-steering-committee mailing list