Proposal: Improving the IsString String instance
Ganesh Sittampalam
ganesh at earth.li
Thu Aug 29 08:03:52 CEST 2013
I'd be marginally in favour of the new class + simpler defaulting rule.
This is mostly on the philosophical ground that it's better to compose
existing features than to introduce new ones.
It also feels like it might be more future-proof/flexible, though I
can't think of a compelling example. A weak one is that someone might
want to work with Array Char or similar.
On 27/08/2013 08:29, Simon Peyton-Jones wrote:
> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
More information about the Libraries
mailing list