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@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
>
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm for more information.