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 increasing scope.
-Edward On Thu, Mar 13, 2014 at 4:56 PM, Richard Eisenberg <[email protected]>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! > > Richard > > On Mar 13, 2014, at 4:22 PM, Austin Seipp wrote: > > > On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant > > <[email protected]> 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 > > [email protected] > > http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
