Proposal: Improving the IsString String instance

Thomas Schilling nominolo at googlemail.com
Tue Sep 10 00:24:26 CEST 2013 

I took a stab at implementing this.  Having a superclass would probably make the implementation simpler.

I can't figure out the proper way to add a "C [a] = <ty>" constraint to the simplifier.  The defaulting mechanism currently just looks tries combinations of "a := <ty>" for all the candidate types.  If "a" is not just a type variable this needs to be add another wanted constraint, but I couldn't find a function that satisfies that purpose.  (Even though I read the OutsideIn(X) journal paper a while ago, the type checker code does indeed seem nearly impenetrable -- there's still some boxy unification code in TcUnify, and it's not clear how that interacts with the new solver.)

Anyway, if someone can point out how I to turn "setWantedTyBind tv ty" into something like "setWantedEquality ty1 ty2" I can implement it.  Otherwise, I'd have to use use some rather gnarly hack that special-cases "C [a] = <ty>" to "a := Char" iff "<ty> == String"

 / Thomas

On 29 Aug 2013, at 08:03, Ganesh Sittampalam <ganesh at earth.li> wrote:

> 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
>> 
> 
> 
> _______________________________________________
> 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/20130910/c5f22021/attachment.pgp>

More information about the Libraries mailing list