Proposal: Partial Type Signatures

[Carter Schonwald]

i'd like to echo the echo  of agreement :)


On Thu, Mar 13, 2014 at 5:34 PM, Edward Kmett <ekmett at 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 <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!
>>
>> Richard
>>
>> 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
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140313/ae3d097c/attachment-0001.html>