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

[Simon Marlow]

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 <chak at justtesting.org>
wrote:

> 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170427/201ca39b/attachment.html>