- ghc-devs - Haskell.org

RE: [Diffusion] [Commented On] rGHC1189196ce7f0: Re-do superclass solving (again); fixes #10423
by Simon Peyton Jones 02 Jun '15

02 Jun '15

That's quite a surprise. I didn't expect performance improvements. But hey, I'll take it! Thanks Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 02 June 2015 17:09 | To: Simon Peyton Jones | Subject: [Diffusion] [Commented On] rGHC1189196ce7f0: Re-do superclass | solving (again); fixes #10423 | | nomeata added a subscriber: nomeata. | nomeata added a comment. | | Yay! There is a 7.5% percent improvement in cryptarithm2’s allocation | count: | https://perf.haskell.org/ghc/#revision/1189196ce7f064af408c9d16874a4c0 | b78f3a006 | | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC1189196ce7f0 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Type checker/inferencer | Cc: nomeata

1 0

RE: [Diffusion] [Build Failed] rGHCd6c01faed26f: Remove redundant import
by Simon Peyton Jones 02 Jun '15

02 Jun '15

Well I validated all right, but now I'm getting this unexpected pass, both on my machine and Phabricator: Unexpected passes: driver T9938 (normal) The ticket seems to oscillate about whether it's supposed to pass or not, and I don't understand the comment stream, so I'm unsure what to do. Also on Phab, but NOT on my machine, I see Unexpected stat failures: perf/haddock haddock.compiler [stat not good enough] (normal) But I can't see the log so I have no idea what is going on. Sorry about this. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 02 June 2015 13:47 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCd6c01faed26f: Remove redundant | import | | Harbormaster failed to build B4222: rGHCd6c01faed26f: Remove redundant | import! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - GHCi (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCd6c01faed26f | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - GHCi

1 0

Travis builds failing
by Edward Z. Yang 01 Jun '15

01 Jun '15

To whoever manages our Travis setup https://travis-ci.org/ghc/ghc/builds We seem to be failing because our build takes longer than 50min. Edward

4 17

Fwd: Re: [commit: ghc] ghc-7.10: base: fix #10298 & #7695 (25b8478)
by Edward Z. Yang 29 May '15

29 May '15

This commit broke the HM builds: https://phabricator.haskell.org/B4147 When I validate locally, though, it works fine. Edward Excerpts from git's message of 2015-05-28 18:11:07 -0700: > Repository : ssh://git@git.haskell.org/ghc > > On branch : ghc-7.10 > Link : http://ghc.haskell.org/trac/ghc/changeset/25b84781ed950d59c7bffb77a576d3c43… > > >--------------------------------------------------------------- > > commit 25b84781ed950d59c7bffb77a576d3c43a883ca9 > Author: Austin Seipp <austin(a)well-typed.com> > Date: Tue May 19 04:56:40 2015 -0500 > > base: fix #10298 & #7695 > > Summary: > This applies a patch from Reid Barton and Sylvain Henry, which fix a > disasterous infinite loop when iconv fails to load locale files, as > specified in #10298. > > The fix is a bit of a hack but should be fine - for the actual reasoning > behind it, see `Note [Disaster and iconv]` for more info. > > In addition to this fix, we also patch up the IO Encoding utilities to > recognize several variations of the 'ASCII' encoding (including its > aliases) directly so that GHC can do conversions without iconv. This > allows a static binary to sit in an initramfs. > > Authored-by: Reid Barton <rwbarton(a)gmail.com> > Authored-by: Sylvain Henry <hsyl20(a)gmail.com> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > Test Plan: Eyeballed it. > > Reviewers: rwbarton, hvr > > Subscribers: bgamari, thomie > > Differential Revision: https://phabricator.haskell.org/D898 > > GHC Trac Issues: #10298, #7695 > > (cherry picked from commit e28462de700240288519a016d0fe44d4360d9ffd) > > >--------------------------------------------------------------- > > 25b84781ed950d59c7bffb77a576d3c43a883ca9 > libraries/base/GHC/IO/Encoding.hs | 14 +++++++++++++- > libraries/base/GHC/TopHandler.hs | 29 ++++++++++++++++++++++++++++- > 2 files changed, 41 insertions(+), 2 deletions(-) > > diff --git a/libraries/base/GHC/IO/Encoding.hs b/libraries/base/GHC/IO/Encoding.hs > index 31683b4..014b61b 100644 > --- a/libraries/base/GHC/IO/Encoding.hs > +++ b/libraries/base/GHC/IO/Encoding.hs > @@ -235,7 +235,14 @@ mkTextEncoding e = case mb_coding_failure_mode of > _ -> Nothing > > mkTextEncoding' :: CodingFailureMode -> String -> IO TextEncoding > -mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of > +mkTextEncoding' cfm enc > + -- First, specifically match on ASCII encodings directly using > + -- several possible aliases (specified by RFC 1345 & co), which > + -- allows us to handle ASCII conversions without iconv at all (see > + -- trac #10298). > + | any (== enc) ansiEncNames = return (UTF8.mkUTF8 cfm) > + -- Otherwise, handle other encoding needs via iconv. > + | otherwise = case [toUpper c | c <- enc, c /= '-'] of > "UTF8" -> return $ UTF8.mkUTF8 cfm > "UTF16" -> return $ UTF16.mkUTF16 cfm > "UTF16LE" -> return $ UTF16.mkUTF16le cfm > @@ -249,6 +256,11 @@ mkTextEncoding' cfm enc = case [toUpper c | c <- enc, c /= '-'] of > #else > _ -> Iconv.mkIconvEncoding cfm enc > #endif > + where > + ansiEncNames = -- ASCII aliases > + [ "ANSI_X3.4-1968", "iso-ir-6", "ANSI_X3.4-1986", "ISO_646.irv:1991" > + , "US-ASCII", "us", "IBM367", "cp367", "csASCII", "ASCII", "ISO646-US" > + ] > > latin1_encode :: CharBuffer -> Buffer Word8 -> IO (CharBuffer, Buffer Word8) > latin1_encode input output = fmap (\(_why,input',output') -> (input',output')) $ Latin1.latin1_encode input output -- unchecked, used for char8 > diff --git a/libraries/base/GHC/TopHandler.hs b/libraries/base/GHC/TopHandler.hs > index d7c0038..e725196 100644 > --- a/libraries/base/GHC/TopHandler.hs > +++ b/libraries/base/GHC/TopHandler.hs > @@ -157,13 +157,40 @@ real_handler exit se = do > Just (ExitFailure n) -> exit n > > -- EPIPE errors received for stdout are ignored (#2699) > - _ -> case fromException se of > + _ -> catch (case fromException se of > Just IOError{ ioe_type = ResourceVanished, > ioe_errno = Just ioe, > ioe_handle = Just hdl } > | Errno ioe == ePIPE, hdl == stdout -> exit 0 > _ -> do reportError se > exit 1 > + ) (disasterHandler exit) -- See Note [Disaster with iconv] > + > +-- don't use errorBelch() directly, because we cannot call varargs functions > +-- using the FFI. > +foreign import ccall unsafe "HsBase.h errorBelch2" > + errorBelch :: CString -> CString -> IO () > + > +disasterHandler :: (Int -> IO a) -> IOError -> IO a > +disasterHandler exit _ = > + withCAString "%s" $ \fmt -> > + withCAString msgStr $ \msg -> > + errorBelch fmt msg >> exit 1 > + where msgStr = "encountered an exception while trying to report an exception" > + > +{- Note [Disaster with iconv] > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +When using iconv, it's possible for things like iconv_open to fail in > +restricted environments (like an initram or restricted container), but > +when this happens the error raised inevitably calls `peekCString`, > +which depends on the users locale, which depends on using > +`iconv_open`... which causes an infinite loop. > + > +This occurrence is also known as tickets #10298 and #7695. So to work > +around it we just set _another_ error handler and bail directly by > +calling the RTS, without iconv at all. > +-} > > > -- try to flush stdout/stderr, but don't worry if we fail > --- End forwarded message ---

3 2

RE: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD
by Simon Peyton Jones 29 May '15

29 May '15

I am back from vacation! Well I am ON vacation, but the children are in bed... Two thoughts: · I like EvTerm as a distinct data type precisely because it enumerates all the forms of evidence we need. Once you allow arbitrary CoreExprs, we lose that explicit enumeration. Now, that might be OK. Evidence terms are proof terms: any well typed EvTerm is a proof of the predicate described by its type. So if a CoreExpr has the right type, then it *should* be the case that the evidence term is OK (provided it’s not bottom). So I can’t quite nail down why I like the explicit EvTerm; except the relatively minor reason that it puts off desugaring to the desugarer. · On a separate matter, can we eliminate the trap-door from TcPluginM to TcM? That is, can you enumerate all the things you need from TcPluginM? The reason I ask is that I’d like to stop building TcS on top of TcM, and instead make it a free-standing monad. Reason: we increasingly want to do constraint solving outside a full-blown typechecker. Eg. when doing pattern-match exhaustiveness checks. Faking up a TcM monad with lots of error thunks seems wrong. Lastly: would someone like to add Adam’s explanation to the Commentary somewhere? Simon From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com] Sent: 27 May 2015 17:26 To: Adam Gundry; Richard Eisenberg; Simon Peyton Jones Cc: Christiaan Baaij Subject: Re: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD Hi guys, I am back from vacation! (cc-ing Richard and Simon, as they might also be interested in some of these changes). I am very much on board with the changes suggested by Adam. A couple of thoughts: * GHC already has some support for evaluation of custom type-families, we added it for evaluating + and friends. It might be good to use the same system for custom evaluation in tc-plugins too, even if we have to modify it some. Currently, this is done by having another "flavor" of type constructor (see `FamTyConFlav` in module `TyCon`), namely one that has built-in evaluation rules. The actual details of how the evaluation happens are in module `CoAxiom`, see `BuiltInSynFamily`: the first field is for evaluating the constructor applied to some arguments (the other two are for emitting derived constraints, `sfInteractTop` is for improvements of a constraint on it's own, and `sfInteractIntert` is for interactions with another constraint that already existis). * If we are going to be modifying `TcEvidence`, I'd be really keen on integrating the evidence for coersions and other evidence a bit more: in particular, it really make sense to allow class predicates in the assumptions of equality constraints. This would allow us to generate evidence for improvements due to interactions of given classes with functional dependencies (e.g., we could express axioms like this: `forall a b c. (C a b, C a c) => (b ~ c)`) -Iavor On Tue, May 26, 2015 at 6:34 AM, Adam Gundry <adam(a)well-typed.com<mailto:adam@well-typed.com>> wrote: Thanks Christiaan, Nice work on ghc-tcplugins-extra. Providing a common package that abstracts away GHC API variations between versions (as far as possible) seems really useful. I notice you also include a workaround for GHC #10301, which is good. I'll try to switch over uom-plugin to use it. As far as I can see, there's no way to bind EvTerms outside TcS; indeed that's a major part of the point of TcS. I'm inclining towards making TcPluginM into a wrapper around TcS, then exposing a nice API to create givens etc. Perhaps we should put together a list of proposed changes to the plugins API, in the light of experience writing the things? There are a few other things I'd like: * the ability to embed arbitrary Core expressions in EvTerms; * a new field in TcPlugin to define type-family reductions directly, rather than having to look for equality constraints involving them; * serializable CoAxiomRules to allow proper evidence in place of UnivCo (doing this for families of rules is a bit tricky, but it should be easy enough to define single axioms). Anything you'd like to add? Iavor? Cheers, Adam On 21/05/15 18:46, Christiaan Baaij wrote: > Hi Adam, Iavor, > > 1. typechecker-plugins-extra package: > > I started on a typechecker-plugin-extra package > at: https://github.com/clash-lang/ghc-tcplugins-extra > Which currently > contains: https://github.com/clash-lang/ghc-tcplugins-extra/blob/master/src/GHC/TcPlu… > > It currently compiles with both GHC 7.10.1 and HEAD. > Althought the 'newSimpleGiven' function is basically broken in HEAD > because there is no way to bind the evidence anywhere. > > 2. wanted & error messages: > > Indeed, I fixed the error message location by using the correct 'CtLoc'. > I needed the chain of wanted 'EvVar' to get deferred-type-errors working > properly. > However, as you say, the proper way to solve this problem it to create > evidence for the 'parent' wanted in terms of the discharged wanteds. > Currently I've been using the same thing you can Iavor are using: > UnivCo, the unsafeCoerce of EvTerms. > I'll investigate if I can somehow manage to properly solve this problem. > At least the fallback mechanism I've implemented already is currently > working. > > 3. TcS vs TcM > If we keep TcPluginM as a wrapper around TcM, do you know "where" we > could bind EvTerms so that other parts of the constraint solving > pipeline can also access them? > Are these EvTerms bound in some IORef'd environment which we can access > in TcM? > > Cheers, > > Christiaan > > On 21 May 2015 at 18:51, Adam Gundry <adam(a)well-typed.com<mailto:adam@well-typed.com> > <mailto:adam@well-typed.com<mailto:adam@well-typed.com>>> wrote: > > Hi Christiaan, > > Thanks for your emails, and sorry I can't quite keep up with them! Let > me try to tackle the issues you raise, in no particular order: > > > 1. TcS vs. TcM > > There's no immediate problem with running plugins in TcS rather than > TcM. Indeed, this was my original proposal, but we decided otherwise > because TcS is really supposed to capture the internal state of GHC's > constraint solver, which shouldn't (in principle) be of interest to > plugins. That is, plugins are deliberately not given access to the inert > set (and hence its cache of solved constraints), because we want to > build an interface that is independent of GHC's particular constraint > solving algorithm. At least that's the goal... > > > 2. Disappearance of ctev_evtm > > I don't follow HEAD closely enough to have spotted this, so thanks for > pointing it out. It looks like the change is indeed a problem for > plugins, because the plugin interface indeed doesn't offer the > integration with TcS necessary to create evidence variables that are > already bound. I guess we should add a function to TcPluginM to bind an > evidence variable. In fact, probably we should offer functions in > TcPluginM that look something like > > newWanted :: CtLoc -> PredType -> TcPluginM CtEvidence > newDerived :: CtLoc -> PredType -> TcPluginM CtEvidence > newGiven :: CtLoc -> PredType -> EvTerm -> TcPluginM CtEvidence > > (or perhaps CtOrigin instead of CtLoc? I can never remember the > difference). > > > 3. On wanteds and error messages > > I've not come across the issues you mention with error message locations > and deferred type errors, but I guess that might be because my plugin > tends to spot insoluble constraints fairly early (rather than > simplifying constraints that subsequently turn out to be insoluble on a > later iteration). > > The way this ought to work is that a plugin should solve a wanted with > an evidence term that contains a reference to a new wanted, rather than > completely bogus evidence; this should ensure that deferred type errors > fire correctly. But in practice that might be difficult at the moment. > > In general, I like the idea of a typechecker-plugin-extra package to > bundle up useful common plugin functionality, some of which may later be > moved into GHC itself. (We could start with those functions above!) > Perhaps it could also provide some measure of stability across GHC > releases. I've not yet convinced myself that the trick you describe for > creating chains of wanteds is really necessary to get good error > locations, but if it is, making it part of such a package is a good > plan. > > Cheers, > > Adam > > > > On 21/05/15 09:39, Christiaan Baaij wrote: > > Hi Adam, Hi Iavor, > > > > While working on creating my type-checker plugins, I noticed that > there are some functions in operate in the ’TcS’ monad that I would > like to use. > > In an earlier email, for example, Iavor suggested that I use > ‘newWantedEvVar’ to create new wanted constraints, but this operates > in the ’TcS’ monad. > > Of course, there’s ‘runTcS’, but this creates a TcS monad with an > empty ‘Bag' of ‘EvBind’. > > What this means, is that (I think), ‘newWantedEvVar’ and > ‘newWantedEvVarNC’, basically behave the same when run inside > ‘runTcS’, because ‘newWantedEvVar’ is going to look for existing > evidence in an empty ‘Bag’… > > > > Also, I saw that plugins are run by the functions in the > ‘TcInteract’ module, which all run inside the ‘TcS’ monad. > > So my question is, would it make sense to make ‘TcPluginM’ a > wrapper around ‘TcS’ instead of ‘TcM’? > > I understand that it would mean > > > > tcPluginIO :: IO a -> TcPluginM a > > > > would have to be specified in terms of either > ‘TcSMonad.wrapErrTcS’ or ‘TsSMonad.wrapErrTcS’ and violate the > purpose of those functions. > > Anyhow, that’s my question/suggestion with regards to the TcS monad. > > On to the other part. > > > > > > I noticed that both your plugins store the Coercion/Evidence for a > new Given constraint in the ‘ctev_evtm’ field of the ‘CtGiven’ > constructor. > > However, in GHC HEAD, this field no longer exists… > > In GHC HEAD, there is only ‘ctev_evar’, of type ‘EvVar’, in the > ‘CtGiven’ constructor. > > I think Simon PJ refactored this because nowhere else in the GHC > compiler was ‘ctev_evtm’ used to store anything else than an identifier… > > The reason being that the evidence was stored ‘TcSEnv’ passed > around in the TcS monad. > > So in GHC HEAD, I think there’s no longer any way create new > Givens of which their evidence can be stored somewhere… > > Perhaps one of you two knows how to store evidence of a Given in > GHC HEAD? > > > > Best regards, > > > > Christiaan > > -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

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