Proposal: Improving the IsString String instance
Thomas Schilling
nominolo at googlemail.com
Tue Aug 27 13:28:18 CEST 2013
We're having a hackathon here in Zurich next weekend. I'll be happy to give this a shot (or get someone attending to do it). Doesn't look too complicated. The bigger unknown are more potential build issues with GHC.
On 27 Aug 2013, at 09:27, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
> If I understand aright, the problem is that we end up with constraints like
> IsString alpha
> or
> IsString [beta]
> where alpha or beta are otherwise-unconstrained unification variables. Under those circumstances we'd like to default to IsString String.
>
> This is *exactly* what the current type-class-defaulting mechanism does. Eg with (show 3) you get (Show alpha, Num alpha) and want to choose alpha to be something sensible.
>
> We've already extended it for GHCi
> http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules
>
> I don't think this would be controversial. The path seems to be:
> propose a concrete extension to the rules,
> specify when it's enabled
> get everyone to agree
> provide a patch (relevant code is in TcSimplify.applyDefaultingRules)
>
> Simon
>
> | -----Original Message-----
> | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of
> | Ganesh Sittampalam
> | Sent: 26 August 2013 21:55
> | To: Edward Kmett
> | Cc: Haskell Libraries
> | Subject: Re: Proposal: Improving the IsString String instance
> |
> | Couldn't it work (with suitable extensions to the list of blessed
> | classes) with Henning's IsCharList suggestion? The unresolved constraint
> | would be IsCharList a.
> |
> | On 26/08/2013 21:47, Edward Kmett wrote:
> | > The problem is ExtendedDefaultRules only works when the whole type is
> | > unknown. If we know part of the type e.g. that it is [a] for some a as
> | > we figure out from length, or that it is (f a), then it doesn't kick
> | in.
> | >
> | > print works because "hello" :: (IsString a, Show a) => a
> | >
> | > knows nothing about the argument a
> | >
> | > and Show is included in the EDR list of blessed classes.
> | >
> | > If at the repl you turn on OverloadedStrings and EDR
> | >
> | > showList "hello" ""
> | >
> | > will still blow up, because it can know you have an argument [a] with
> | a
> | > Show a constraint on it, and IsString [a], so it fails to meet the
> | > fairly simplistic conditions required by EDR.
> | >
> | > -Edward
> | >
> | >
> | > On Mon, Aug 26, 2013 at 4:34 PM, Dag Odenhall <dag.odenhall at gmail.com
> | > <mailto:dag.odenhall at gmail.com>> wrote:
> | >
> | > |ExtendedDefaultRules| already provides this to some extent, for
> | > example it makes |print "hello"| work without type information.
> | >
> | >
> | >
> | > On Mon, Aug 26, 2013 at 10:09 PM, Dan Burton
> | > <danburton.email at gmail.com <mailto:danburton.email at gmail.com>>
> | wrote:
> | >
> | > Just to throw another curveball at this conversation, what
> | about
> | > a general, ad-hoc solution for 'typeclass defaults'? The logic
> | > goes like this: Is there an "ambiguous type variable" error
> | due
> | > to the use of the IsString typeclass? Try defaulting to the
> | > String instance. If that doesn't work, try defaulting to Text.
> | > Repeat for a finite, explicit list of instances. If none of
> | > these defaults are successful, type error.
> | >
> | > We have hard-coded this sort of behavior into the Num class.
> | Why
> | > not just provide this general capability for arbitrary
> | classes?
> | > Or at least hard-code it into IsString as well.
> | >
> | > In the absence of this sort of solution, +1 to Edward's
> | original
> | > proposal.
> | >
> | > The "o" proposal is not viable because the oft-needed parens
> | > make it confusing and irritating to the new Haskeller.
> | >
> | > -- Dan Burton
> | >
> | >
> | > On Mon, Aug 26, 2013 at 12:41 PM, Henning Thielemann
> | > <lemming at henning-thielemann.de
> | > <mailto:lemming at henning-thielemann.de>> wrote:
> | >
> | >
> | > On Mon, 26 Aug 2013, Gabriel Gonzalez wrote:
> | >
> | > I'm guessing this is sarcastic, but I just want to
> | > clarify what I understood Henning's proposal to be.
> | > He's not saying we should provide an `o` function in
> | > the standard library, but rather encourage users to
> | > define their own.
> | >
> | >
> | > Yes. I would be ok if packages provide this function, but
> | I
> | > would urge programmers to import that explicitly.
> | >
> | >
> | > This one liner would take the place of the current
> | line
> | > that they devote right now to `OverloadedStrings` .
> | >
> | >
> | > right
> | >
> | >
> | > However, the analogy is still apt since the exact same
> | > line of reasoning applies to overloaded numeric
> | > literals where we currently rely on defaulting to
> | solve
> | > this problem.
> | >
> | >
> | > I always use -Wall and thus I am warned about when
> | > defaulting takes place. Thus I am confident that I do not
> | > rely on defaulting in my code.
> | >
> | > _______________________________________________
> | > Libraries mailing list
> | > Libraries at haskell.org <mailto:Libraries at haskell.org>
> | > http://www.haskell.org/mailman/listinfo/libraries
> | >
> | >
> | >
> | > _______________________________________________
> | > Libraries mailing list
> | > Libraries at haskell.org <mailto:Libraries at haskell.org>
> | > http://www.haskell.org/mailman/listinfo/libraries
> | >
> | >
> | >
> | > _______________________________________________
> | > Libraries mailing list
> | > Libraries at haskell.org <mailto:Libraries at haskell.org>
> | > http://www.haskell.org/mailman/listinfo/libraries
> | >
> | >
> | >
> | >
> | > _______________________________________________
> | > Libraries mailing list
> | > Libraries at haskell.org
> | > http://www.haskell.org/mailman/listinfo/libraries
> | >
> |
> |
> | _______________________________________________
> | Libraries mailing list
> | Libraries at haskell.org
> | http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130827/433586d2/attachment.pgp>
More information about the Libraries
mailing list