Proposal #23: instance force
We need to decide whether we like to accept the ”instance force" proposal: https://github.com/ghc-proposals/ghc-proposals/pull/23 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
Hi, Am Mittwoch, den 26.04.2017, 21:45 +1000 schrieb Manuel M T Chakravarty:
* 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.
Hmm, maybe the proposal is unclear on that, but that is not the only motivation. The other main motivation is to make type inference easier and more predictable by avoiding ambiguous types, so that things like {-# LANGUAGE OverloadedStrings #-} print "Test" would work without problems. I believe than Ryan Trinkle expressed interest in a feature like this; he uses a type class to be able to swap out a real implementation of an interface with a testing stub, but in application code he _always_ wants the real implementation – although, to be honest, I think he is more interested in having a guarantee that the compiler optimizes the dictionary away completely, and maybe less in type inference. But I agree that a nicer means to this ends would be, well, nice. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
I agree with rejecting this proposal. I understand the motivation, but It
doesn't feel right to me.
I often want something like 'instance force IsString Text', but in many
cases the module will also contain a few places where want to use String,
so I wouldn't be able to use 'instance force IsString Text' for the whole
module and I'd have to fall back to 'default Text' (which I do). So
there's an odd overlap between 'instance force' and 'default', it would
feel strange to have both of these features. I'm not sure we've fully
explored the design space here.
"The type of functions with occurrences of Cls that cannot be instantiated"
- can this be rigorously defined?
In general the approach seems quite ad-hoc. e.g. if I import a function f
:: Cls t => t -> Int into a module with `instance force Cls Bool` then it
gets instantiated, but instead if I wrapped it in a newtype
newtype T = T (forall t . Cls t => t -> Int)
f :: T
then importing f would not instantiate Cls, presumably? Defaulting works
in both of these cases though.
Cheers
Simon
On 26 April 2017 at 12:45, Manuel M T Chakravarty
We need to decide whether we like to accept the ”instance force" proposal:
https://github.com/ghc-proposals/ghc-proposals/pull/23
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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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@haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 26 April 2017 12:46 | To: ghc-steering-committee@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@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi, I’ll try to refrain from pouncing on every point raised, and I am not trying to sway anyone’s mind (I don’t feel very strongly about the proposal and will not shed a tear if it does not go through), but allow me to comment on Am Donnerstag, den 27.04.2017, 22:56 +0000 schrieb Simon Peyton Jones:
No need to do this ill-specified "change the type of imported functions" stuff.
that I deliberately avoided talking about “Wanted” constraints and other Outside-In terminology, which I consider implementation details and which a language feature specification should, if at all possible, avoid. I might not have succeeded in giving a good specification, but there is a rather clear picture in my head, so I can clarify if there are open questions.
It'd work fine for instance force C [a] too, which the proposal doesn't allow.
Not quite true. If there is a instance C [a] in scope around, then instance force C [a] would work fine. But you are right that the current wording (“from an empty context”) would prohibit it if the instance instance D a => C [a] where in scope. Should the tides turn (which seems unlikely) I can improve this part. Greetings, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
| that I deliberately avoided talking about “Wanted” constraints and | other Outside-In terminology, which I consider implementation details | and which a language feature specification should, if at all possible, | avoid. I might not have succeeded in giving a good specification, but I agree with that, and it's a valid criticism of my language. However, if you want to reason about what type should be inferred for f x = x==x && x>x (which is a user-facing thing, totally part of the language spec), then it's probably easier to say "From the use of (==) you get a wanted (Eq a) constraint, where x::a. From the use of (>) you get a wanted (Ord a). Both can be derived from a Given (Ord a)." or language like that. Understanding typing rules is, I think, harder. Moreover, it's quite hard to explain fundeps using typing rules. (Try it!) I was trying to draw the analogy, since we already have fundeps. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 28 April 2017 01:20 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #23: instance force | | Hi, | | I’ll try to refrain from pouncing on every point raised, and I am not | trying to sway anyone’s mind (I don’t feel very strongly about the | proposal and will not shed a tear if it does not go through), but | allow me to comment on | | Am Donnerstag, den 27.04.2017, 22:56 +0000 schrieb Simon Peyton Jones: | > No need to do this ill-specified "change the type of imported | > functions" stuff. | | that I deliberately avoided talking about “Wanted” constraints and | other Outside-In terminology, which I consider implementation details | and which a language feature specification should, if at all possible, | avoid. I might not have succeeded in giving a good specification, but | there is a rather clear picture in my head, so I can clarify if there | are open questions. | | > It'd work fine for | > instance force C [a] | > too, which the proposal doesn't allow. | | Not quite true. If there is a | | instance C [a] | | in scope around, then | | instance force C [a] | | would work fine. | | | But you are right that the current wording (“from an empty context”) | would prohibit it if the instance | | instance D a => C [a] | | where in scope. | | Should the tides turn (which seems unlikely) I can improve this part. | | Greetings, | Joachim | | | | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C4dbafc73718744 | 86953b08d48dcc51fe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289 | 356110063073&sdata=Zs%2BSqmtdFn7a%2Fvy7h2KC1m%2Fu%2Bj3DiOLHzSoIJ7y8BgM | %3D&reserved=0
participants (4)
-
Joachim Breitner -
Manuel M T Chakravarty -
Simon Marlow -
Simon Peyton Jones