ghc-steering-committee

Download

ghc-steering-committee@haskell.org

May 2018

8 participants
22 discussions

Please Review: Array resizing primitives (#121), Shepherd: Simon Marlow
by Joachim Breitner 01 May '18

01 May '18

Dear Committee, this is your secretary speaking: Array resizing primitives have been proposed by David Feuer: https://github.com/ghc-proposals/ghc-proposals/pull/121 I propose Simon Marlow as the shepherd. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}
by Manuel M T Chakravarty 01 May '18

01 May '18

I assume, you meant to send this to ghc-steering-committee(a)haskell.org (in CC now) and not to the dev list. Manuel > 01.05.2018 02:12 Iavor Diatchki <iavor.diatchki(a)gmail.com>: > > 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/propo… <https://github.com/goldfirere/ghc-proposals/blob/explicit-specificity/propo…> > > 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 > > > > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0