Proposal: Improving the IsString String instance
Simon Peyton-Jones
simonpj at microsoft.com
Tue Aug 27 09:29:15 CEST 2013
PS: I'm not convinced that it's worth the overhead of adding a new class. Modifying the defaulting rules would probably be enough, although it does involve one new feature, namely that it must default IsString [beta] as well as IsString alpha.
Simon
| -----Original Message-----
| From: Simon Peyton-Jones
| Sent: 27 August 2013 08:27
| To: 'Ganesh Sittampalam'; Edward Kmett
| Cc: Haskell Libraries
| Subject: RE: Proposal: Improving the IsString String instance
|
| 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
More information about the Libraries
mailing list