Discussion on proposal #99: forall {k}

Iavor Diatchki iavor.diatchki at gmail.com
Mon Apr 30 16:12:27 UTC 2018


Hello,

As a shepherd for proposal #99, I'd like to kick off the discussion.  The
full proposal is available here:
https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/proposals/0000-explicit-specificity.rst

Summary: allows programmers to write `forall {x}` instead of `forall x` in
type signatures.  The meaning of the braces is that this parameter cannot
be instantiated with an explicit type application and will always be
inferred.  The motivation is to shorten explicit type applications by
skipping parameters that are known to be inferable, the common example
being omitting the kinds in signatures with poly kinds.

As I understand it, the main motivation for this proposals is to give
programmers more flexibility when instantiating type variables, with a less
noisy syntax.   While the proposed solution might work in some situations,
I am unconvinced that it is the best way to address the issue in general,
for the following reasons:

  1. It requires that programmers commit at declaration time about which
arguments will be inferred, and which may be inferred or specified.   While
in some cases this may be an easy decision to make, in many cases this
really is a decision which should be made at the use site of a function
(e.g., I'd like to provide argument X, but would like GHC to infer argument
Y).

  2. It still requires that programmers instantiate arguments in a fixed
order,  which is sometimes dictated by the structure of the type itslef.
Here is, for example, what the proposal suggests to do if you want to
provide type before a kind:

    typeRep4 :: forall {k} (a :: k) k'. (k ~ k', Typeable a) => TypeRep a

    While technically this is not wrong, it is not exactly elegant.

I think that we should reject this proposal, and try to come up with a more
comprehensive solution to the problem.

One alternative design is to allow programmers to instantiate type
variables by name.  This is much more flexible as it allows programmers to
instantiate whichever variables they want, and in whatever order.  We've
been doing this in Cryptol for a long time, and it seems to work really
well.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180430/3e41b4e8/attachment.html>


More information about the ghc-devs mailing list