[ghc-steering-committee] TypeApplications for Overloaded Literals (#129), Recommendation: accept
Richard Eisenberg
rae at cs.brynmawr.edu
Sun May 6 19:26:53 UTC 2018
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>
More information about the ghc-steering-committee
mailing list