Proposal: Partial Type Signatures

[Thomas Winant]

On 03/13/2014 09:56 PM, Richard Eisenberg wrote:

> First of all: Yay! I've been  wanting this for some time. I'm sorry I
 >  missed your presentation at PADL about this.
 >
 > I, personally, rather like the design. There may be fine points of
 > discussion as it all becomes reality, but I think this is a great
 > approach -- much like what I've envisioned whenever thinking about the
 > problem.
 >
 > Thanks so much for doing this!

You're welcome! Thank you too for the work you have done. I very much
liked your presentation at POPL on closed type families :)

> I would allow _ only as a  constraint extension and _a in a constraint
 > only when it also appears in the mono-type.

Right, we are now convinced (thanks to SPJ's comment on the wiki page)
that the small benefits constraint wildcards bring are not worth the
trouble and confusion. This makes things easier for us too :)

> I think, contrary to the wiki  page, that the scope of named wildcards
 > should mirror the behavior of normal type variables. Yes, it's weird
 > that scoped type variables don't work by default, but I think it's
 > weirder still if some scoped type-variable-like things work and others
 > don't. I don't imagine that this fine control is hard to implement.

If more people feel like this, we have no problem with mirroring the
scoped type variables behaviour. The change will be simple.

> I think Austin's suggestion  below is equally great. Just has 7.8 will
 > now report informative errors when _ is used in an expression
 > position, the implementation for partial type signatures can easily
 > spit out informative errors when _ is used in a type. This would not
 > be an extension, because it does not change the set of programs that
 > compile nor the behavior of compiled programs. However, if a user
 > specifies -XPartialTypeSignatures, then the errors are not reported --
 > the inferred type is simply used.

We also like Austin's idea :) I updated the wiki page with a section
about borrowing ideas from the Holes proposal:

https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures#holes

What we plan on doing next:
1. We will update the code to disallow constraint wildcards. Only named
    wildcards also occurring in the monotype and the extra-constraints
    wildcard will be allowed.
2. We will try to implement what we proposed in the Holes section on the
    wiki page.

Comments and feedback are still welcome. There are still some unanswered
design questions on the wiki page, e.g. what about generalisation and
the extra-constraints wildcard in local partial type signatures?


Cheers,
Thomas



> On Mar 13, 2014, at 4:22 PM,  Austin Seipp wrote:
 >
 >> On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant
 >> <thomas.winant at cs.kuleuven.be> wrote:
 >>> However, we have the impression that no Hole should remain unfilled,
 >>> whereas using a partial type signature doesn't necessarily mean the
 >>> program is incomplete. A partial type signature can still be a
 >>> (stylistic) choice.
 >>
 >> Yes, this is the main hold up I was thinking of. Thinking about it a
 >> little more, one way to resolve it perhaps would be to do something
 >> similar to we did to typed holes at the term level: make 'holes' at
 >> the type level an error by default, which when encountered spit out
 >> the error containing the type each hole was instantiated to, and what
 >> the partial type signatures would be inferred as. Then, if you enable
 >> -XPartialTypeSignatures, these would cease to be errors providing the
 >> compiler can infer the types sensibly (and it wouldn't alert you in
 >> that case).
 >>
 >> That might be a half baked idea (I just sat here for about 5 minutes),
 >> but either way I say again I do support -XPartialTypeSignatures
 >> anyway, and it sounds like a step in the right direction. :)
 >>
 >> --
 >> Regards,
 >>
 >> Austin Seipp, Haskell Consultant
 >> Well-Typed LLP, http://www.well-typed.com/
 >> _______________________________________________
 >> ghc-devs mailing list
 >> ghc-devs at haskell.org
 >> http://www.haskell.org/mailman/listinfo/ghc-devs
 >


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140314/5619023d/attachment-0001.html>