Proposal: Partial Type Signatures
ekmett at gmail.com
Thu Mar 13 21:34:08 UTC 2014
I'd just like to echo that I really like Austin's suggestion as well, as it
very nicely unifies the two usecases, while simultaneously *not *dramatically
On Thu, Mar 13, 2014 at 4:56 PM, Richard Eisenberg <eir at cis.upenn.edu>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.
> I would allow _ only as a constraint extension and _a in a constraint only
> when it also appears in the mono-type. 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.
> 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.
> Thanks so much for doing this!
> 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
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs