Proposal: Improving the IsString String instance

[Ganesh Sittampalam]

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
>