Proposal: Improving the IsString String instance

[Simon Peyton-Jones]

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