Re: Suggesting RankNTypes for ill-formed types

[Jan Stolarek]

It doesn't really matter whether we suggest ExplicitForAll, ScopedTypeVariables 
or RankNTypes. The 
code in question is plainly wrong and should be a parse error. I skimmed the 
parser code and I 
see no easy way of doing this without breaking the fix for #3155 at the same 
time.

What I would try, I think, is to find a different solution to #3155.

Janek


Dnia czwartek, 18 sierpnia 2016, Richard Eisenberg napisał:
> I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more
> helpful to users, even though `ExplicitForAll` is more principled.
>
> Richard
>
> > On Aug 11, 2016, at 2:45 PM, Oleg Grenrus  wrote:
> >
> > FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
> > yet my code doesn’t always has the scoped type variable used.
> > So even GHC could parse further and propose it to me, there isn’t
> > anything from to do it :(
> >
> > I don’t know if many use /just/ `ExplicitForAll`...
> >
> > - Oleg
> >
> >> On 11 Aug 2016, at 20:30, Karolina Drobnik  >> > wrote:
> >>
> >> Hello everyone,
> >>
> >> I am working on my first ticket (#11669, linked below)
> >> and I have some doubts after a little bit of hacking.
> >>
> >> There was a hint that an error message should be
> >> changed from the one suggesting RankNTypes to ExplicitForall.
> >> In my opinion it would be quite confusing for the user, especially where
> >> the type is ill-formed. A plain parse error should be shown here.
> >>
> >> It is clear that it should be done in such a way after turning on one
> >> of the extensions, but what about the situation where proposed
> >> fix (suggesting RankNTypes/ExplicitForall) won't work?
> >> We should be able to distinguish ill-formed type from the correct one,
> >> even before the extension activation. To be honest - I don't know how to
> >> do it.
> >>
> >> Additionally, I am not sure if we can assume that an user wants
> >> to use arbitrary rank (which implies ExplicitForall) or just a forall
> >> keyword. I am for the second one, but it is just my assumption.
> >>
> >> And the last minor thing - a type formed in this way also rises an error
> >> suggesting using RankNTypes (as we know that wouldn't solve the
> >> problem):
> >>
> >> f :: a. -> Int
> >> f = undefined
> >>
> >> Maybe we could treat it as a typo (simple parse error) and propose
> >> an extension activation only when forall was parsed earlier?
> >> That could be tricky.
> >>
> >> I'd appreciate some thoughts on this issue because I felt a bit lost
> >> after digging around the parser.
> >>
> >> Best regards,
> >>
> >> Karolina
> >> -
> >> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669
> >> 
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org 
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

 

--- 
Politechnika Łódzka 
Lodz University of Technology 

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. 
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę 
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. 

This email contains information intended solely for the use of the individual 
to whom it is addressed. 
If you are not the intended recipient or if you have received this message in 
error, 
please notify the sender and delete it from your system. 


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Suggesting RankNTypes for ill-formed types

[Richard Eisenberg]

I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more 
helpful to users, even though `ExplicitForAll` is more principled.

Richard

> On Aug 11, 2016, at 2:45 PM, Oleg Grenrus  wrote:
> 
> FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
> yet my code doesn’t always has the scoped type variable used.
> So even GHC could parse further and propose it to me, there isn’t anything 
> from to do it :(
> 
> I don’t know if many use /just/ `ExplicitForAll`...
> 
> - Oleg
> 
>> On 11 Aug 2016, at 20:30, Karolina Drobnik > > wrote:
>> 
>> Hello everyone,
>> 
>> I am working on my first ticket (#11669, linked below) 
>> and I have some doubts after a little bit of hacking.
>> 
>> There was a hint that an error message should be
>> changed from the one suggesting RankNTypes to ExplicitForall. 
>> In my opinion it would be quite confusing for the user, especially where
>> the type is ill-formed. A plain parse error should be shown here.
>> 
>> It is clear that it should be done in such a way after turning on one
>> of the extensions, but what about the situation where proposed
>> fix (suggesting RankNTypes/ExplicitForall) won't work?
>> We should be able to distinguish ill-formed type from the correct one,
>> even before the extension activation. To be honest - I don't know how to do 
>> it.
>> 
>> Additionally, I am not sure if we can assume that an user wants
>> to use arbitrary rank (which implies ExplicitForall) or just a forall 
>> keyword.
>> I am for the second one, but it is just my assumption.
>> 
>> And the last minor thing - a type formed in this way also rises an error
>> suggesting using RankNTypes (as we know that wouldn't solve the problem):
>> 
>> f :: a. -> Int
>> f = undefined
>> 
>> Maybe we could treat it as a typo (simple parse error) and propose
>> an extension activation only when forall was parsed earlier? 
>> That could be tricky.
>> 
>> I'd appreciate some thoughts on this issue because I felt a bit lost
>> after digging around the parser.
>> 
>> Best regards,
>> 
>> Karolina
>> -
>> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 
>> 
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org 
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Suggesting RankNTypes for ill-formed types

[Oleg Grenrus]

FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
yet my code doesn’t always has the scoped type variable used.
So even GHC could parse further and propose it to me, there isn’t anything from 
to do it :(

I don’t know if many use /just/ `ExplicitForAll`...

- Oleg

> On 11 Aug 2016, at 20:30, Karolina Drobnik  wrote:
> 
> Hello everyone,
> 
> I am working on my first ticket (#11669, linked below)
> and I have some doubts after a little bit of hacking.
> 
> There was a hint that an error message should be
> changed from the one suggesting RankNTypes to ExplicitForall.
> In my opinion it would be quite confusing for the user, especially where
> the type is ill-formed. A plain parse error should be shown here.
> 
> It is clear that it should be done in such a way after turning on one
> of the extensions, but what about the situation where proposed
> fix (suggesting RankNTypes/ExplicitForall) won't work?
> We should be able to distinguish ill-formed type from the correct one,
> even before the extension activation. To be honest - I don't know how to do 
> it.
> 
> Additionally, I am not sure if we can assume that an user wants
> to use arbitrary rank (which implies ExplicitForall) or just a forall keyword.
> I am for the second one, but it is just my assumption.
> 
> And the last minor thing - a type formed in this way also rises an error
> suggesting using RankNTypes (as we know that wouldn't solve the problem):
> 
> f :: a. -> Int
> f = undefined
> 
> Maybe we could treat it as a typo (simple parse error) and propose
> an extension activation only when forall was parsed earlier?
> That could be tricky.
> 
> I'd appreciate some thoughts on this issue because I felt a bit lost
> after digging around the parser.
> 
> Best regards,
> 
> Karolina
> -
> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Suggesting RankNTypes for ill-formed types

[Karolina Drobnik]

Hello everyone,

I am working on my first ticket (#11669, linked below)
and I have some doubts after a little bit of hacking.

There was a hint that an error message should be
changed from the one suggesting RankNTypes to ExplicitForall.
In my opinion it would be quite confusing for the user, especially where
the type is ill-formed. A plain parse error should be shown here.

It is clear that it should be done in such a way after turning on one
of the extensions, but what about the situation where proposed
fix (suggesting RankNTypes/ExplicitForall) won't work?
We should be able to distinguish ill-formed type from the correct one,
even before the extension activation. To be honest - I don't know how to do
it.

Additionally, I am not sure if we can assume that an user wants
to use arbitrary rank (which implies ExplicitForall) or just a forall
keyword.
I am for the second one, but it is just my assumption.

And the last minor thing - a type formed in this way also rises an error
suggesting using RankNTypes (as we know that wouldn't solve the problem):

f :: a. -> Int
f = undefined

Maybe we could treat it as a typo (simple parse error) and propose
an extension activation only when forall was parsed earlier?
That could be tricky.

I'd appreciate some thoughts on this issue because I felt a bit lost
after digging around the parser.

Best regards,

Karolina
-
#11669 - https://ghc.haskell.org/trac/ghc/ticket/11669
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs