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

[Joachim Breitner]

Hi,

it seems this proposal does not get much support. I kinda like the high-level goal, but not enough to defend it vehemently. I am changing my recommendation to reject, to facilitate consensus.

I should give those time to speak up who were in silent agreement with my initial recommendation, and if nothing happens, will reject this proposal in a week's time.


Cheers,
Joachim




Am 8. Mai 2018 06:40:30 GMT-04:00 schrieb Simon Peyton Jones <simonpj at microsoft.com>:
>I’m on the fence:
>
>  *   Benefit: slight
>  *   Cost: slight
>
>But the spec is distressingly ad-hoc.  Magical behaviour if
>
>  *   RebindableSyntax is no
>  *   The ‘fromInteger’ in scope is not ‘Prelude.fromInteger’
>
>So I lean to rejection.  Unless some stronger motivations emerge.
>
>Simon
>
>From: ghc-steering-committee
><ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard
>Eisenberg
>Sent: 06 May 2018 20:27
>To: Iavor Diatchki <iavor.diatchki at gmail.com>
>Cc: ghc-steering-committee at haskell.org; Joachim Breitner
><mail at joachim-breitner.de>
>Subject: Re: [ghc-steering-committee] TypeApplications for Overloaded
>Literals (#129), Recommendation: accept
>
>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<mailto: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/
>_______________________________________________
>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
>_______________________________________________
>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