- ghc-devs - Haskell.org

Re: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by malcolm.wallace 29 May '15

29 May '15

Yes, this is what I am asking. Is the LGPL so dangerous to your business, that you have taken the steps necessary to build a special GHC using integer-simple instead of integer-gmp? Or are the lawyers happy simply for the option to be available, but unexercised? (If the latter, then I could suggest that ghc using cpphs by default, but allowing the option of a different preprocessor, might suffice?) Regards, Malcolm On 19 May, 2015,at 02:51 PM, Niklas Larsson <metaniklas(a)gmail.com> wrote: Hi! GMP is optional, anyone who cares about the license can build with integer-simple. Regards, Niklas Från: malcolm.wallace Skickat: ‎2015-‎05-‎19 13:11 Till: Lars Kuhtz Kopia: ghc-devs(a)haskell.org Ämne: Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal How does your company deal with the Integer type, whose standard implementation in ghc is via the LGPL'd Gnu multi-precision routines? Regards, Malcolm On 18 May, 2015,at 09:19 PM, Lars Kuhtz <haskell(a)kuhtz.eu> wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

12 26

Strange testsuite failure
by Simon Peyton Jones 29 May '15

29 May '15

Is this expected? Just started happening for me =====> T8333(normal) 140 of 185 [0, 0, 0] cd . && $MAKE -s --no-print-directory T8333 </dev/null > T8333.run.stdout 2> T8333.run.stderr Actual stdout output differs from expected: --- ./T8333.stdout 2015-01-27 13:00:30.000000000 +0000 +++ ./T8333.run.stdout 2015-05-13 11:54:03.199711197 +0100 @@ -0,0 +1,4 @@ +*** WARNING: . is writable by someone else, IGNORING! +Suggested fix: execute 'chmod 644 .' +*** WARNING: /home/simonpj is writable by someone else, IGNORING! +Suggested fix: execute 'chmod 644 /home/simonpj' *** unexpected failure for T8333(normal)

2 1

Re: [Haskell-cafe] Disambiguating a Num/RealFrac instance
by Adam Gundry 28 May '15

28 May '15

On 28/05/15 18:28, Brandon Allbery wrote: > On Tue, May 26, 2015 at 8:35 PM, <amindfv(a)gmail.com > <mailto:amindfv@gmail.com>> wrote: > > Is there any way (without IncoherentInstances or Rebindablesyntax) > that I can let the user write e.g. "giveGPA 4.0" (and "giveGPA 4") > and get back "F 4" without getting type errors that "4.0"'s type is > ambiguous? I can guarantee there won't be any additional instances > to "ToGPA" > > > A typeclass with only one instance is nonsensical, and often a symptom > of trying to use typeclasses as OO classes. All it's doing here is > hurting you. Like Brandon, I suspect this probably isn't what you should do. But if you *really* want to do it, this works: {-# LANGUAGE ExtendedDefaultRules, FlexibleInstances #-} default (Float) data GPA = F Float | Excuse String class ToGPA a where giveGPA :: a -> GPA instance ToGPA Float where giveGPA = F instance ToGPA String where giveGPA = Excuse x = giveGPA 4 y = giveGPA 4.0 z = giveGPA "Hello" For more information: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/interactive… Hope this helps, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: Proposed changes to typechecker plugins API
by Jan Bracker 28 May '15

28 May '15

Hi Adam, Hi Eric, At least for what I want to use them for [1] it would be nice if there was an easy way to say: If you are stuck on solving "Constraint a b TypeC", then you should pick, e.g.: - "a ~ TypeA" and "b ~ TypeB" (What I am actually trying to say is: use the instance "Constraint TypeA TypeB TypeC") - "a ~ b" Currently I am producing equality constraints, like this: mkDerivedTypeEqCt :: TcTyVar -> TcType -> TcPluginM Ct mkDerivedTypeEqCt tyVar ty = do (_, lclEnv) <- getEnvs return $ CTyEqCan { cc_ev = CtDerived -- :: CtEvidence { ctev_pred = ty -- :: TcPredType -- This matches type-wise, but I have no idea what actually belongs here. , ctev_loc = mkGivenLoc topTcLevel (UnifyForAllSkol [tyVar] ty) lclEnv -- :: CtLoc -- Again no idea what actually belongs here: -- topTcLevel :: TcLevel -- To what does this relate? I guess top level -- is ok for equality constraints -- (UnifyForAllSkol [tyVar] ty) :: SkolemInfo -- This one matches what we have at disposal (no idea if it is the right one). -- lclEnv :: TcLclEnv -- I just use the only one I know. } , cc_tyvar = tyVar -- :: TcTyVar , cc_rhs = ty -- :: TcType , cc_eq_rel = NomEq -- :: EqRel -- Alternative would be ReprEq. Whats the difference? } Which seems to be working, but still leaves a lot of open questions (see comments). Maybe my problems using the API are more related to missing documentation, then lack of API functionality. Jan [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-February/008414.html On Wed, 27 May 2015 07:13:37, Eric Seidel wrote: > Hi Adam, > > I like the addition of the new* functions for creating constraints, that > should make for a much nicer API than dealing directly with the > CtEvidence constructors! > > I'm not so convinced however about embedding arbitrary CoreExprs in > EvTerms. First of all, it feels a bit strange to generate CoreExprs > before the desugarer (and we would have to add a `MonadThings TcPluginM` > instance to generate Integer and String CoreExprs). > > But more importantly, based on your wiki page [1], it sounds like what > we really want is a nice API for creating dictionaries. > > Eric > > [1]: > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#EmbeddingCoreExpr… > > > > On Wed, May 27, 2015, at 01:33, Adam Gundry wrote: > > Hi devs, > > > > I thought I should flag up some proposed changes relating to typechecker > > plugins, which Christiaan, Iavor and I have been discussing. The quick > > summary: > > > > * make it possible for plugins to create constraints (Phab:D909); > > > > * make it easier for plugins to define special type families; > > > > * embed CoreExpr in EvTerm. > > > > For more details, see the wiki page: > > > https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Post-7.10changest… > > > > Questions/review/comments very welcome. > > > > Adam > > > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

2 1

Test posting -- debugging mailinglist issues.
by Gershom B 28 May '15

28 May '15

Disregard this, sorry for the noise :-) --Gershom

1 0

Proposed changes to typechecker plugins API
by Adam Gundry 27 May '15

27 May '15

Hi devs, I thought I should flag up some proposed changes relating to typechecker plugins, which Christiaan, Iavor and I have been discussing. The quick summary: * make it possible for plugins to create constraints (Phab:D909); * make it easier for plugins to define special type families; * embed CoreExpr in EvTerm. For more details, see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Post-7.10changest… Questions/review/comments very welcome. Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)
by Christiaan Baaij 27 May '15

27 May '15

Hi, This patch causes a regression from GHC 7.10 with regards to constraint kinds. Where previously, constraint tuples could go up to 62, the same as normal tuples, they have now been reduced to 8. I filed a bug report at: https://ghc.haskell.org/trac/ghc/ticket/10451 <https://ghc.haskell.org/trac/ghc/ticket/10451> Regards, Christiaan > On 18 May 2015, at 14:45, git(a)git.haskell.org wrote: > > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/ffc21506894c7887d3620423aaf86bc61… > >> --------------------------------------------------------------- > > commit ffc21506894c7887d3620423aaf86bc6113a1071 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Mon May 11 23:19:14 2015 +0100 > > Refactor tuple constraints > > Make tuple constraints be handled by a perfectly ordinary > type class, with the component constraints being the > superclasses: > class (c1, c2) => (c2, c2) > > This change was provoked by > > #10359 inability to re-use a given tuple > constraint as a whole > > #9858 confusion between term tuples > and constraint tuples > > but it's generally a very nice simplification. We get rid of > - In Type, the TuplePred constructor of PredTree, > and all the code that dealt with TuplePreds > - In TcEvidence, the constructors EvTupleMk, EvTupleSel > > See Note [How tuples work] in TysWiredIn. > > Of course, nothing is ever entirely simple. This one > proved quite fiddly. > > - I did quite a bit of renaming, which makes this patch > touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. > > - I made constraint tuples known-key rather than wired-in. > This is different to boxed/unboxed tuples, but it proved > awkward to have all the superclass selectors wired-in. > Easier just to use the standard mechanims. > > - While I was fiddling with known-key names, I split the TH Name > definitions out of DsMeta into a new module THNames. That meant > that the known-key names can all be gathered in PrelInfo, without > causing module loops. > > - I found that the parser was parsing an import item like > T( .. ) > as a *data constructor* T, and then using setRdrNameSpace to > fix it. Stupid! So I changed the parser to parse a *type > constructor* T, which means less use of setRdrNameSpace. > > I also improved setRdrNameSpace to behave better on Exact Names. > Largely on priciple; I don't think it matters a lot. > > - When compiling a data type declaration for a wired-in thing like > tuples (,), or lists, we don't really need to look at the > declaration. We have the wired-in thing! And not doing so avoids > having to line up the uniques for data constructor workers etc. > See Note [Declarations for wired-in things] > > - I found that FunDeps.oclose wasn't taking superclasses into > account; easily fixed. > > - Some error message refactoring for invalid constraints in TcValidity > > - Haddock needs to absorb the change too; so there is a submodule update > > >> --------------------------------------------------------------- > > ffc21506894c7887d3620423aaf86bc6113a1071 > compiler/basicTypes/BasicTypes.hs | 21 +- > compiler/basicTypes/DataCon.hs | 1 - > compiler/basicTypes/RdrName.hs | 28 +- > compiler/basicTypes/Unique.hs | 28 +- > compiler/basicTypes/VarSet.hs | 23 +- > compiler/coreSyn/CoreLint.hs | 2 +- > compiler/coreSyn/MkCore.hs | 7 +- > compiler/coreSyn/PprCore.hs | 4 +- > compiler/deSugar/Check.hs | 2 +- > compiler/deSugar/DsArrows.hs | 2 +- > compiler/deSugar/DsBinds.hs | 25 +- > compiler/deSugar/DsCCall.hs | 6 +- > compiler/deSugar/DsExpr.hs | 5 +- > compiler/deSugar/DsMeta.hs | 840 +-------------------- > compiler/deSugar/Match.hs | 4 +- > compiler/ghc.cabal.in | 3 +- > compiler/ghci/RtClosureInspect.hs | 7 +- > compiler/hsSyn/Convert.hs | 4 +- > compiler/hsSyn/HsExpr.hs | 3 +- > compiler/hsSyn/HsPat.hs | 35 +- > compiler/hsSyn/HsTypes.hs | 2 +- > compiler/iface/BinIface.hs | 14 +- > compiler/iface/BuildTyCl.hs | 4 + > compiler/iface/IfaceSyn.hs | 9 +- > compiler/iface/IfaceType.hs | 154 ++-- > compiler/iface/TcIface.hs | 84 ++- > compiler/main/Constants.hs | 3 + > compiler/main/HscMain.hs | 11 +- > compiler/parser/Parser.y | 20 +- > compiler/parser/RdrHsSyn.hs | 164 +++- > compiler/prelude/PrelInfo.hs | 28 +- > compiler/prelude/PrelNames.hs | 17 - > compiler/prelude/PrelRules.hs | 6 +- > compiler/prelude/PrimOp.hs | 2 +- > compiler/prelude/THNames.hs | 836 ++++++++++++++++++++ > compiler/prelude/TysWiredIn.hs | 269 ++++--- > compiler/rename/RnEnv.hs | 1 + > compiler/rename/RnNames.hs | 42 +- > compiler/rename/RnSplice.hs | 6 +- > compiler/simplStg/UnariseStg.hs | 10 +- > compiler/specialise/Specialise.hs | 3 +- > compiler/stranal/WwLib.hs | 6 +- > compiler/typecheck/FunDeps.hs | 32 +- > compiler/typecheck/TcBinds.hs | 52 +- > compiler/typecheck/TcCanonical.hs | 32 - > compiler/typecheck/TcErrors.hs | 2 - > compiler/typecheck/TcEvidence.hs | 15 +- > compiler/typecheck/TcExpr.hs | 10 +- > compiler/typecheck/TcGenDeriv.hs | 15 +- > compiler/typecheck/TcHsSyn.hs | 5 +- > compiler/typecheck/TcHsType.hs | 15 +- > compiler/typecheck/TcInstDcls.hs | 4 +- > compiler/typecheck/TcInteract.hs | 11 +- > compiler/typecheck/TcMType.hs | 1 - > compiler/typecheck/TcPat.hs | 2 +- > compiler/typecheck/TcRnMonad.hs | 4 + > compiler/typecheck/TcSimplify.hs | 1 - > compiler/typecheck/TcSplice.hs | 2 +- > compiler/typecheck/TcTyClsDecls.hs | 20 +- > compiler/typecheck/TcType.hs | 3 - > compiler/typecheck/TcValidity.hs | 186 +++-- > compiler/types/TyCon.hs | 34 +- > compiler/types/Type.hs | 7 +- > compiler/types/TypeRep.hs | 11 +- > compiler/vectorise/Vectorise/Builtins/Base.hs | 2 +- > .../vectorise/Vectorise/Builtins/Initialise.hs | 2 +- > compiler/vectorise/Vectorise/Utils/Closure.hs | 4 +- > libraries/ghc-prim/GHC/Classes.hs | 44 +- > libraries/ghc-prim/GHC/Tuple.hs | 242 +++--- > libraries/ghc-prim/GHC/Types.hs | 2 +- > .../should_fail/NotRelaxedExamples.stderr | 17 +- > .../indexed-types/should_fail/TyFamUndec.stderr | 17 +- > testsuite/tests/module/all.T | 2 +- > testsuite/tests/module/mod89.hs | 2 + > testsuite/tests/module/mod89.stderr | 10 +- > .../tests/typecheck/should_fail/T9858a.stderr | 2 +- > .../tests/typecheck/should_fail/fd-loop.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail108.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail154.stderr | 6 +- > .../tests/typecheck/should_fail/tcfail157.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail213.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail214.stderr | 8 +- > .../tests/typecheck/should_fail/tcfail220.hsig | 1 - > .../tests/typecheck/should_fail/tcfail220.stderr | 8 - > utils/genprimopcode/Main.hs | 49 +- > utils/haddock | 2 +- > 86 files changed, 1985 insertions(+), 1672 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc ffc21506894c7887d3620423aaf86bc6113a1071 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

1 0

StaticPointers to local definitions
by Facundo Domínguez 25 May '15

25 May '15

Hello, It is happening in practice that one wants to create a static pointer in a function and use some local definitions. > f :: Static (Int -> Int) > f x = sf > where > body = (+1) > sf = Static body 'body' defines a closed expression, but this is currently rejected because desugaring the static form would produce a top-level binding of the form: > sf_top_level :: Int -> Int > sf_top_level = body where the local binding 'body' is not in scope. Barring inlining, which wouldn't work in more complex examples, one approach around this is to have the compiler move local definitions to the top level during desugaring when they are referenced by a static pointer. Two questions arise: 1) Would this interfere with other aspects of compilation? 2) Would anyone argue there is a better approach to accomplish this? Thanks, Facundo

1 0

RE: [GHC] #10370: Compile time regression in OpenGLRaw
by Simon Peyton Jones 22 May '15

22 May '15

Austin: I have validated, but I am now going on holiday for a week. Can you monitor and revert if there's a major problem? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of GHC | Sent: 22 May 2015 15:21 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10370: Compile time regression in OpenGLRaw | | #10370: Compile time regression in OpenGLRaw | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: michalt | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: | 7.10.1 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Compile-time | Unknown/Multiple | performance bug | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by simonpj): | | The commit messages tell the story. Reid's example in comment:3 | showed up TWO separate, substantial non-linear performance holes in | GHC, both of which I have now fixed. Reid, your example was | amazingly helpful. | | '''Austin''' I have not added a `perf/compiler` test case. Could you | do so please? I wasn't sure that a 20-second compile time was | acceptable. | I'm leaving the ticket open for that reason. | | Simon | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10370#comment:13> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

2 1

Re: Interactions between type-checker plugins
by Christiaan Baaij 20 May '15

20 May '15

I have yet to test this properly, but I don't think your suggestions (which you happen to give with 1 minute of eachother...) play nicely with error reporting. Here is an output of my testsuite: ``` [1 of 2] Compiling ErrorTests ( tests/ErrorTests.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o ) [GHC.TypeLits.Normalise changed] tests/ErrorTests.hs:1:1: Warning: Couldn't match type ‘GCD 6 9’ with ‘GCD 6 8’ NB: ‘GCD’ is a type function, and may not be injective Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9) Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9) tests/ErrorTests.hs:14:13: Warning: Couldn't match type ‘GCD 6 8’ with ‘4’ Expected type: Proxy (GCD 6 8) -> Proxy 4 Actual type: Proxy 4 -> Proxy 4 In the expression: id In an equation for ‘testFail1’: testFail1 = id [2 of 2] Compiling Main ( tests/Main.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) [GHC.TypeLits.Normalise changed] Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ... Running 1 test suites... Test suite test-ghc-tynat-normalise: RUNNING... ghc-typelits-natnormalise Basic functionality GCD 6 8 ~ 2: OK GCD 6 8 + x ~ x + GCD 10 8: OK errors GCD 6 8 ~ 4: OK GCD 6 8 + x ~ x + GCD 9 6: FAIL No exception! 1 out of 4 tests failed (0.00s) ``` Note that 'ErrorTest.hs' is compiled with '-fdefer-type-errors'. There's a two things you may notice * The first error message's location is '1:1' * Evaluation the function with the type-error does not raise an exception. So by solving the constraint "GCD 6 8 + x ~ x + GCD 9 6" The boxed/run-time coercion no longer errors. Also, I'm using newSimpleWanted ( https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/Tc…) to create the new wanted constraint. But for some reason the errror message doesn't get the source-error location of the original constraint. Perhaps I shouldn't be using 'newSimpleWanted' to create new wanted constraints? The sources for the plugins are over here: https://github.com/christiaanb/ghc-typelits-natnormalise https://github.com/christiaanb/ghc-typelits-extra Cheers, Christiaan On 19 May 2015 at 18:01, Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > Hi Christiaan, > > > Plugins should return the solved constraints in the first field of > `TcPLuginOk`, and additional sub-goals in the second. > The constraints in the first list are marked as solved, and do not need to > be processed further, while the constraints > in the second list will be added to the work queue, for further > processing. Also, the solutions of wanted goals may be in terms of other > as yet unsolved things. > > I think that there are two situations when a plugin might return an empty > first list, but new work in the second list. > Both are about computing new facts, and thus "communicating" with other > plugins: > 1. Discover new given facts: the plugin was presented with some > givens, and it computed some additional givens that it thinks might be of > use to someone else (typically these are equality constraints) > 2. Discover new derived facts: the plugin was presented with a mixture > of wanted and givens, and it thinks that the new derived facts might be > useful by specializing the problem----derived facts help with type > inference by instantiating unification variables. > > Generally, I don't think a plugin should ever need to emit new wanted > constraints without solving anything. It'd be interesting if that could > happen though... > > Another thing that might be relevant: at present, GHC's constraint solver > does not do back tracking. So there is no way for a plugin (or other parts > of the constraint solver) to say: "I'll emit this new wanted constraint, > and depending on if it was proved or disproved do something". Another way > to think of his is that constraints are either solved or unsolved, but > being unsolved does not mean that they are disproved. Now, there is a > mechanism to mark a constraint as "never solvable", but currently this is > mostly used for error reporting. > > For your concrete example though, the plugin can actually commit to the > given path because the only way to solve "GCD 6 8 + x ~ x + GCD 9 6" is if > "GCD 6 8 ~ GCD 9 6". So I'd imagine you want these steps: > > Plugin A: Solve "GCD 6 8 + x ~ x + GCD 9 6", new wanted "GCD 6 8 ~ GCD 9 6" > Plugin B: "GCD 6 8 ~ GCD 9 6" --> impossible > Done. > > > -Iavor > > > > On Tue, May 19, 2015 at 3:35 AM, Christiaan Baaij < > christiaan.baaij(a)gmail.com> wrote: > >> I have a question about how type-checker plugins should interact. >> My situation is the following: >> I have two type-checker plugins, one that can solve equalities involving >> the standard type-level operations on kind Nat (+,*,-,^), and another >> type-checker plugin that can prove equalities involving a new type-level >> operation GCD. >> In the following, the type-checker plugin involving the stand type-level >> operations is called ‘A’, and the type checker involving the new GCD >> operations is called ‘B’. >> >> When type-checker plugin A encounters: >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> >> It knows that (+) is commutative, so it can prove the above equality >> _given_ that "GCD 6 8 ~ GCD 9 6” holds. >> So what type-checker plugin A does now is emits a new wanted constraints: >> [W] GCD 6 8 ~ GCD 9 6 >> And remembers that it emitted this wanted constraint. >> In type-checker plugin lingo, it returns: >> TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6”] >> >> > > Now whenever type-checker plugin encounters >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> again, it checks to see if the discharged constraint >> [W] GCD 6 8 ~ GCD 9 6 >> Is already solved, is disproven, or unsolved. >> If the discharged constraint is solved, it will return: >> TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6”] [] >> If the discharged constraint is dis proven, it returns: >> TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6”] >> And otherwise, it doesn’t do anything: >> TcPluginOk [] [] >> >> > > >> Now, type-checker plugin B, the one that knows about GCD, comes along. >> It sees: >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> [W] GCD 6 8 ~ GCD 9 6 >> I doesn’t know anything about (+); but it does know about GCD, and >> clearly sees that GCD 6 8 is not equal to GCD 9 6. >> So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. >> In type-checker plugin lingo it says: >> TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6”] >> >> According to >> https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/co… >> What happens next is that the insoluble constraint >> [W] GCD 6 8 ~ GCD 9 6 >> is taken of the work list for all plugins. >> However! the same thing happens when a plugin is able to prove a >> constraint. >> That is, if B would have (erroneously) returned: >> TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6”] [] >> >> Then there is _no_ way for type-checker plugin A to know what happened. >> Were its discharged constraints taken from the work-list because it was >> insoluble? or because it was solved? >> This is a problem because to me it seems that the work list is the only >> way that two type-checker plugins can communicate. >> >> I guess my question is: if not through the work list, how are >> type-checker plugins supposed to communicate? >> Am I going about it all wrong in terms how I should be writing >> type-checker plugins? >> Or, should the type of ‘TcPluginSolver’ ( >> https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/Tc…) >> be updated to?: >> >> ``` >> type TcPluginSolver = [Ct] -- ^ Given constraints >> -> [Ct] -- ^ Derived constraints >> -> [Ct] -- ^ Wanted constraints >> -> [Ct] -- ^ Insoluble constraints >> -> TcPluginM TcPluginResult >> ``` >> >> Best regards, >> >> Christiaan >> >> >> >> >> >

2 2