i'd like to echo the echo of agreement :)
On Thu, Mar 13, 2014 at 5:34 PM, Edward Kmett <ekm...@gmail.com> wrote: > 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 <e...@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! >> >> Richard >> >> On Mar 13, 2014, at 4:22 PM, Austin Seipp wrote: >> >> > On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant >> > <thomas.win...@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@haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
