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@gmail.com
> <mailto:dag.odenhall@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@gmail.com <mailto:danburton.email@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@henning-thielemann.de
> <mailto:lemming@henning-thielemann.de>> wrote:> Libraries@haskell.org <mailto:Libraries@haskell.org>
>
>
> 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
> http://www.haskell.org/mailman/listinfo/libraries> Libraries@haskell.org <mailto:Libraries@haskell.org>
>
>
>
> _______________________________________________
> Libraries mailing list
> http://www.haskell.org/mailman/listinfo/libraries> Libraries@haskell.org <mailto:Libraries@haskell.org>
>
>
>
> _______________________________________________
> Libraries mailing list
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>