- ghc-devs - Haskell.org

Consecutive FFI calls
by David Turner 03 Jun '15

03 Jun '15

Hi, If I make a sequence of FFI calls (on a single Haskell thread) but which end up being called from different OS threads, is there any kind of ordering guarantee given? More specifically, is there a full memory barrier at the point where a Haskell thread migrates to a new OS thread? Many thanks, David

3 5

RE: [Diffusion] [Build Failed] rGHC7ea156ae3e1c: Refactor RdrName.Provenance, to fix #7672
by Simon Peyton Jones 03 Jun '15

03 Jun '15

I'm still seeing Unexpected stat failures: perf/haddock haddock.compiler [stat not good enough] (normal) but only on Phab not on my own machine. I don't know how to fix this. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 03 June 2015 12:27 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC7ea156ae3e1c: Refactor | RdrName.Provenance, to fix #7672 | | Harbormaster failed to build B4245: rGHC7ea156ae3e1c: Refactor | RdrName.Provenance, to fix #7672! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | GHC - Core/System FC (Auditor) | GHC - Driver (Auditor) | GHC - Renamer (Auditor) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC7ea156ae3e1c | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite, GHC - Core/System FC, GHC - Driver, GHC | - Renamer, GHC - Type checker/inferencer

1 0

Re: [commit: ghc] master: build: make haddock a bit less chatty (e796026)
by Mateusz Kowalczyk 03 Jun '15

03 Jun '15

On 06/02/2015 03:31 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/e796026b45974d71233eef7ffb6feee48… > >> --------------------------------------------------------------- > > commit e796026b45974d71233eef7ffb6feee482c6dd7e > Author: Austin Seipp <austin(a)well-typed.com> > Date: Tue Jun 2 09:31:52 2015 -0500 > > build: make haddock a bit less chatty > > Summary: > Haddock outputs well over a thousand lines of file output just to give > its executive summary about coverage. Kill this by default, since we > really don't need it in any setting. > > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > Test Plan: Crossed my fingers. > > Reviewers: nomeata, thomie > > Reviewed By: thomie > > Subscribers: bgamari, thomie > > Differential Revision: https://phabricator.haskell.org/D933 > > >> --------------------------------------------------------------- > > e796026b45974d71233eef7ffb6feee482c6dd7e > ghc.mk | 2 +- > rules/haddock.mk | 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/ghc.mk b/ghc.mk > index 5a1845c..3b38372 100644 > --- a/ghc.mk > +++ b/ghc.mk > @@ -1375,7 +1375,7 @@ validate_build_xhtml: > cd libraries/xhtml && ./Setup configure --with-ghc="$(BINDIST_PREFIX)/bin/ghc" $(BINDIST_HADDOCK_FLAG) $(BINDIST_LIBRARY_FLAGS) --global --builddir=dist-bindist --prefix="$(BINDIST_PREFIX)" > cd libraries/xhtml && ./Setup build --builddir=dist-bindist > ifeq "$(HADDOCK_DOCS)" "YES" > - cd libraries/xhtml && ./Setup haddock --ghc-options=-optP-P --builddir=dist-bindist > + cd libraries/xhtml && ./Setup haddock -v0 --ghc-options=-optP-P --builddir=dist-bindist > endif > cd libraries/xhtml && ./Setup install --builddir=dist-bindist > cd libraries/xhtml && ./Setup clean --builddir=dist-bindist > diff --git a/rules/haddock.mk b/rules/haddock.mk > index a43df95..5604a50 100644 > --- a/rules/haddock.mk > +++ b/rules/haddock.mk > @@ -48,6 +48,7 @@ ifeq "$$(HSCOLOUR_SRCS)" "YES" > "$$(ghc-cabal_INPLACE)" hscolour $1 $2 > endif > "$$(TOP)/$$(INPLACE_BIN)/haddock" \ > + --verbosity=0 \ > --odir="$1/$2/doc/html/$$($1_PACKAGE)" \ > --no-tmp-comp-dir \ > --dump-interface=$$($$($1_PACKAGE)-$$($1_$2_VERSION)_HADDOCK_FILE) \ > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits > You could have just used --no-print-missing-docs to go to the old amount of output. Or start filling out the stuff Haddock is complaining about, I made it a default to nag people :) -- Mateusz K.

1 0

GHC Weekly News - 2015/06/03
by Austin Seipp 03 Jun '15

03 Jun '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150603) Hi *, It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there. The main point of discussion was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts! == 7.10.2 status == 7.10.2 is swimming along very nicely - the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page] shows the current set of tickets we've fixed and plan on fixing. Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate. == List chatter == - Austin Seipp announced that GHC 7.10.2 will be release soon, and developers/users should get bugs they want fixed reported to us ASAP so we can do something. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html - Mark Lentczner announced a Haskell Platform alpha featuring GHC 7.10.2 https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Facundo Dominguez asks: sometimes we want to create a `static` pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html - David Macek has made great progress on getting native MSYS2 packages for windows working - which should be a great boon to all our Windows users! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html - Joachim Breitner announced the new GHC performance dashboard, which can be used to track all of GHC's performance-based tests over time. Whoohoo! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html - Joachim Breitner asked: is there a way to programmatically 'Raise a Concern' on a Phabricator commit? With the new https://perf.haskell.org/ghc/ work, it'd be nice if regressions could be automatically flagged. The current problem is there is no API endpoint, but one can be built. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Adam Gundry asked ghc-devs about some input on changes to the new typechecker plugins API. After some discussion and elbow grease, the new changes have already landed in HEAD and will be in 7.12.1. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html == Noteworthy commits == - Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space leak in the mighty simplifier - Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic behavior in `tidyOccName` - Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow `:back` and `:forward` to take counts - Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up `nativeCodeGen/seqBlocks` - Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up `elimCommonBlocks` by grouping blocks also by outgoing labels - Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird behavior of `-ignore-dot-ghci` and `-ghci-script` - Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of overlapping instances in Safe Haskell - Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382 - Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for `:set -s` == Closed tickets == #10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474, -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

API to “raise concern” in Phabricator
by Joachim Breitner 03 Jun '15

03 Jun '15

Hi, with https://perf.haskell.org/ghc/ up and running I’m wondering about the best way to notify us about regressions. A mail to ghc-commits is one possibility, but maybe it’s neater to integrate that into Phabricator. How hard would it be comment and optionally “raise concern” with a commit automatically? Or, put differently, I want a script that takes a git commit, a comment, and a flag that indicated whether a concern should be raised, and then does that on Phabricator. It seems that https://phabricator.haskell.org/conduit/ is an entry point, but I only see methods for attaching comments to DRs. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

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