[ghc-steering-committee] TypeApplications for Overloaded Literals (#129), Recommendation: accept

[Richard Eisenberg]

I'm also unconvinced about this proposal. It's hard to specify, requiring that Prelude.fromInteger be magical. Note that if someone defined a separate Num class (under -XNoImplicitPrelude -XRebindableSyntax) that's fully equivalent to Prelude.Num, it wouldn't work. Also, Joachim's point about `:t 5` is a poor motivation: `:t` does not give you helpful information w.r.t. type applications. You need `:t +v`. With -fprint-explicit-foralls,

λ> :t +v 5
5 :: forall {p}. Num p => p

The appearance of the braces in the output means that 5 is not available for visible type application (the variable p is *inferred*). So if there's any unexpected behavior in the current implementation, that's due to ill-informed expectations, not misbehavior.

In the end, I would prefer to reject this proposal in favor of Joachim's casual proposal here: https://mail.haskell.org/pipermail/ghc-steering-committee/2018-May/000541.html (and expanded upon by my subsequent post).

Richard

> On May 6, 2018, at 12:27 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> I am not convinced, if that's the sole motivation.  By that reasoning you might expect that `(-5) @Int` or `(5+1) @Int` would also work, but they wouldn't. 
> 
> 
> 
> On Sun, May 6, 2018 at 8:47 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Sonntag, den 06.05.2018, 15:42 +0000 schrieb Iavor Diatchki:
> > Is there a reason why we should write `5 @Int` as opposed to `5 :: Int`?
> 
> Because we can. Or rather, we should can, because 
> 
>    Prelude> :t 5
>    5 :: Num t => t
>    Prelude> :t 5 @Double
>    <interactive>:1:1: error:
>        • Cannot apply expression of type ‘t0’
>          to a visible type argument ‘Double’
>        • In the expression: 5 @Double
> 
> is confusing and inconsistent with the user’s expectation after
> learning about when they can use ExplicitTypeApplications (unless one
> knows about the syntactic sugar involved.)
> 
> > Also, there appears to be a typo in the spec, the part which specifies translations for integers (1 turned into 0?)
> 
> thanks, fixed.
> 
> 
> (BTW, all of you are owners of the repository and should have the
> necessary permissions to edit pull requests directly.)
> 
> Cheers,
> Joachim
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180506/0d91cc0d/attachment-0001.html>