(redirecting to ghc-devs)
Thomas
Let's be clear what is happening here. After all the dust has settled we call TcSimplify.applyDefaultingRules to look at a bunch of unsolved constraints and generate new, extra constraints that might help solve them.
Thus if we see (Eq a, Num a)
we might generate the extra constraint (a ~ Integer)
to try to help solve them.
Now, what you want to do is to spot a constraint like (IsString [a]),
and generate (a ~ Char).
Now it's true that the current machinery in findDefaultableGroups is set up to look for constraints of form (C a), because that's what the rules say. If you change the rules you'll need to change the code.
But I'm not even sure what the new rule *are*. The current GHCi defaulting rules are documented here:
http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluati...
The first thing to do is to write down the exact new rules that you are trying to implement.
Simon
| -----Original Message-----
| From: Thomas Schilling [mailto:nominolo@googlemail.com]
| Sent: 09 September 2013 23:24
| To: Ganesh Sittampalam
| Cc: Simon Peyton-Jones; Edward Kmett; Haskell Libraries
| Subject: Re: Proposal: Improving the IsString String instance
|
| 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 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@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
| >> | > | | > 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
| >> | | > 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
| >> | | > > | | > mailto:lemming@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@haskell.org
| mailto:Libraries@haskell.org
| >> | | > http://www.haskell.org/mailman/listinfo/libraries
| >> | | >
| >> | | >
| >> | | >
| >> | | > _______________________________________________
| >> | | > Libraries mailing list
| >> | | > Libraries@haskell.org mailto:Libraries@haskell.org
| >> | | > http://www.haskell.org/mailman/listinfo/libraries
| >> | | >
| >> | | >
| >> | | >
| >> | | > _______________________________________________
| >> | | > Libraries mailing list
| >> | | > Libraries@haskell.org mailto:Libraries@haskell.org
| >> | | > http://www.haskell.org/mailman/listinfo/libraries
| >> | | >
| >> | | >
| >> | | >
| >> | | >
| >> | | > _______________________________________________
| >> | | > Libraries mailing list
| >> | | > Libraries@haskell.org
| >> | | > http://www.haskell.org/mailman/listinfo/libraries
| >> | | >
| >> | |
| >> | |
| >> | | _______________________________________________
| >> | | Libraries mailing list
| >> | | Libraries@haskell.org
| >> | | http://www.haskell.org/mailman/listinfo/libraries
| >>
| >> _______________________________________________
| >> Libraries mailing list
| >> Libraries@haskell.org
| >> http://www.haskell.org/mailman/listinfo/libraries
| >>
| >
| >
| > _______________________________________________
| > Libraries mailing list
| > Libraries@haskell.org
| > http://www.haskell.org/mailman/listinfo/libraries
