- ghc-devs - Haskell.org

RE: Exposing newtype coercions to Haskell
by Simon Peyton-Jones 31 Jul '13

31 Jul '13

(Narrowing to ghc-devs.) Re passing bottoms, read "Equality proofs and deferred type errors". http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ The NT type here is playing the role of (~) in that paper. Just as (~) wraps (~#), so NT will wrap (NT#), and it'll play out exactly in the paper. So I'm not bothered about bottoms. Suppose we have a data type data T a b = T1 (S a b) (R b) where we have in scope ntS :: NT p p' -> NT q q' -> NT (S p q) (S p' q') but R is completely abstract. Now, is it safe to say deriving ntT :: NT a a' -> NT (T a b) (T a' b) Well, our criterion is whether we can write by hand, a function foo :: NT a a' -> T a b -> T a' b Let's try: foo g (T1 s r) = T1 (cast s g1) (cast r g2) where g1 :: NT (S a b) (S a' b) g1 = ntS g refl g2 :: NT (R b) (R b) g2 = refl So the general plan is, for each constructor argument of type ty, see if you can build a suitable NT value (g1, g2 in the above example), using either built-in stuff like refl, or arguments like (g :: NT a a'), or in-scope NT values like ntS. If you CAN do that, then it's ok (internally) to use ordinary coercion lifting, roughly ntT g = T g refl The above per-constructor-arg testing is just to make sure that all the relevant witnesses are in scope, to preserve abstraction. It's not for soundness. (There is some "role" stuff to take account of there, which Richard is working on, but to a first approximation that's it I think.) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of Joachim Breitner | Sent: 04 July 2013 14:30 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: Exposing newtype coercions to Haskell | | Hi, | | small update: I generalized the code at | https://github.com/nomeata/nt-coerce/blob/9349dd3/GHC/NT/Plugin.hs | a bit, it is now able to handle to create NT-values for unwarpping | arbitrary newtypes and for lifting across type constructors. It does so | unconditionally, i.e. does _not_ yet check whether the constructors are | in scope and whether the user is allowed to cast the types occurring in | the data constructors. | | So what works is this: | | NT values for newtypes without or with type arguments, and possibly | recursive: | | newtype Age = Age Int deriving Show | ageNT :: NT Age Int | ageNT = deriveThisNT -- temporary syntax for deriving | listNT ... | | newtype MyList a = MyList [a] deriving Show | myListNT :: NT (MyList a) [a] | myListNT = deriveThisNT | | newtype R a = R [R a] deriving Show | rNT :: NT (R a) [R a] | rNT = deriveThisNT | | | NT values for type constructors, replacinge all or some of the type | parameters: | | listNT :: NT a b -> NT [a] [b] | listNT = deriveThisNT | | myListNT' :: NT a b -> NT (MyList a) (MyList b) | myListNT' = deriveThisNT | | data F a b c = F a b c deriving Show | fNT :: NT a a' -> NT (F a b c) (F a' b c) | fNT = deriveThisNT | | | What does not work is creating a NT value between a newtype and its | representation if type arguments change on the way, e.g. | | bar :: NT (MyList Age) [Int] | | but the user can construct that himself: | | bar = myListNT' ageNT `trans` myListNT | | | | The next step would be to add the safeguards about the visibility of | constructors and about the types of data constructor parameters. | Especially the latter is still not clear to me: For example with | | data Foo a = Foo (Bar a) | | is it really sufficient to check whether a "barNT:: NT a b -> NT (Bar a) | (Bar b)" exists? After all, I would not need barNT in the generated | implementation of fooNT, so the user could “provide” this value via | undefined and nobody would notice. | | I get the feeling that already the typing rule for TyConAppCo should | expect coercions between the actual types in the data constructors | rather than just between the type constructor parameters, so that the | implementation barNT would actually have to use fooNT. Maybe that would | simplify the two-equalities-approach. But that is just an uneducated gut | feeling. | | | BTW: Is this still on-topic on glasgow-haskell-users or should I move to | ghc-dev? | | | Greetings, | Joachim | -- | Joachim “nomeata” Breitner | mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C | Debian Developer: nomeata(a)debian.org

3 23

Proposal: Gitolite for repository management
by Austin Seipp 31 Jul '13

31 Jul '13

Hello all, Recently with the new haskell.org server move, a few of us have taken roles of administrating the new server infrastructure including ghc.haskell.org, containing the GHC repositories. (Previously, the GHC repos were on abbot.haskell.org, which was maintained by Galois. The new servers are community managed.) I'm one of these people, so first off if you have any problems, let me know! I should also say Herbert Valerio Riedel has also stepped up to help administrate the GHC Trac instance. He's quite experienced in these sorts of matters, and his help is greatly appreciated. If there's anything wrong in this area, he can also be of help. :) Anyway, the real topic: Recently, we have been discussing the way GHC's repositories are managed, and it's slightly suboptimal for several reasons. We would instead like to deploy Gitolite, a smart git-access wrapper. This will not only solve some annoying issues (like Simon's recent permissions error when pushing to testsuite,) but also make ghc.haskell.org more secure and easier to maintain. We have a proposal with preliminary details up here: http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan Please refer to it for the exact details. But the visible overview for all the active developers will be: * Shell accounts will go away. You'll only have access to the repositories. * Your SSH push URL will change very slightly. * sync-all will probably need to change a bit for the new remotes. This will all need to happen within a small window of downtime. As outlined above, we believe we can pull off a switch with minimal interruption. So on that end, we need to know a few things too. What we'd like to know is: * Does any developer who has shell access to ghc.haskell.org actually *need it*? Outside of administrative tasks, I'm not sure who should and should not have access. At the least, your privileges will be slightly reduced after we're done (since the darcs group won't be needed.) * Who is an active committer? I'm not really sure what to do here, but we can easily transplant all the current users in the 'darcs' group. Alternatively we can establish it for most of the core committers, and add people who commit less frequently on a rolling basis (they can just contact me.) * When should this be done? The downtime window will be small hopefully, and I don't think this would really inconvenience anyone too much if we did it soon, but I feel we should ask. -- Regards, Austin - PGP: 4096R/0x91384671

6 6

HEADS UP: New repository
by Ian Lynagh 31 Jul '13

31 Jul '13

Hi all, I've added a libffi-tarballs repo. This means that you'll need to do ./sync-all get after you next pull. Thanks Ian

2 2

Patch/feature proposal: "Source plugins"
by Edsko de Vries 30 Jul '13

30 Jul '13

Sorry for the earlier mishap, here's the full email. Hi all, The plugin mechanism gives access to the program in Core; this suffices for many but not quite all purposes. Tools that need access to the original AST can call typecheckModule directly, but of course this requires using the GHC API directly. Moreover, even when using the GHC API directly anyway (as in my case), it means that tools cannot take advantage of ghc's infrastructure for dependency tracking, recompiling only changed modules, etc. Hence it would be useful to have "source plugins", which can be used both externally and when using ghc API (in the latter case I guess "hooks" would be the more appropriate terminology). Currently "core plugins" are recorded as part of DynFlags as pluginModNames :: [ModuleName], pluginModNameOpts :: [(ModuleName,String)], This makes sense when thinking of plugins only as an external mechanism, but is less convenient when using them as internal hooks, too. In my draft patch I introduce a new type "HscPlugin" (described shortly) and added sourcePlugins :: [HscPlugin], to DynFlags. HscPlugin is a record of a pair of functions; having the actual record here rather than a module name means that these functions can have a non-empty closure, which is obviously convenient when using this as a hook rather than an external plugin. In my current version HscPlugin looks like data HscPlugin = HscPlugin { runHscPlugin :: forall m. MonadIO m => DynFlags -> TcGblEnv -> m TcGblEnv , runHscQQ :: forall m. MonadIO m => Env TcGblEnv TcLclEnv -> HsQuasiQuote Name -> m (HsQuasiQuote Name) } runHscPlugin is the main function; it gets passed the TcGblEnv (which contains the type checked AST as its tcd_binds field) and gets a change to return it modified (we don't currently take advantage of that; I did that only to be in line with "core plugins"). Unfortunately, the typechecked AST is only a subset of the renamed AST (see http://www.haskell.org/pipermail/ghc-devs/2013-February/000540.html) The TcGblEnv contains a tcg_rn_decls field, which is a reference to the full renamed (as opposed to typechecked) AST, but by default this is not initialized: the typechecker only optionally retains the renamed AST, and this is hardcoded to by False. In my current patch I have changed this so that it's hard coded to be True; ideally this should become an option in DynFlags (more ideal still would be if the type checked AST would not lose any information). Unfortunately, even the renamer loses information: quasi-quotes get expanded during renaming and all evidence of that there was ever a quasi-quote there has disappeared when the renamer returns. For this reason, the HscPlugin type that I'm using at the moment also has a hook for quasi-quotes. So what I have currently done is: 1. Introduced the above HscPlugin type and added a corresponding field to DynFlags 2. Call runHscQQ in the renamer whenever a quasi-quote gets expanded. 3. Make sure that the typechecker passes the result of the renamer through. 4. Call runHscPlugin on the result of the typechecker. In my client code I then combine the information obtained from these three sources (2, 3, 4). The path of least resistance for me currently to submit this as a patch for ghc therefore be to submit a patch that does precisely what I described above, mutatis mutandis based on your feedback, except that I would add an option to add to DynFlags that would tell the type checker whether or not to pass the result of the renamer through, rather than hardcoding it. It is a little bit messy mostly because parts of the AST get lost along the way: quasi-quotes in the renamer, data type declarations and other things during type checking. A more ideal way, but also more time consuming, would be to change this so that the renamer leaves evidence of the quasi-quotes in the tree, and the type checker returns the entire tree type checked, rather than just a subset. I think that ultimately this is the better approach, at least for our purposes -- I'm not sure about other tools, but since this would be a larger change that affects larger parts of the ghc pipeline I'm not sure that I'll be able to do it. Any and all feedback on the above would be appreciated! Edsko

6 16

Call for talks: Haskell Implementors Workshop 2013, Sept 22, Boston
by Ryan Newton 30 Jul '13

30 Jul '13

Please pass on this announcement! The deadline is in two weeks.* * * * * Call for Talks* ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2013 Boston, USA, September 22th, 2013 The workshop will be held in conjunction with ICFP 2013 http://www.icfpconference.org/icfp2013/ *Important dates* Proposal Deadline: *13th August 2013 (by midnight, any timezone)* Notification: 27th August 2013 Workshop: 22th September 2013 The Haskell Implementors' Workshop is to be held alongside ICFP 2013 this year in Boston. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This relatively new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2013. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for a relatively short talk. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 200 words. Submissions should be made via EasyChair. The website is: https://www.easychair.org/conferences/?conf=hiw2013 If you don't have an account you can create one here: https://www.easychair.org/account/signup.cgi Because the submission is an abstract only, please click the "abstract only" button when you make your submission. There is no need to attach a separate file. We will also have a lightning talks session which will be organised on the day. These talks will be 2-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Ryan Newton (Indiana University) * Neal Glew (Intel Labs) * Edward Yang (Stanford University) * Thomas Schilling (University of Kent) * Geoffrey Mainland (Drexel University)

1 0

GHC head and .haddocks
by Edsko de Vries 29 Jul '13

29 Jul '13

Hi, I'm trying to build and install ghc head, with the installation of the .haddocks. I'm running into all kinds of trouble though. I have docbook and docbook-xsl installed, am using the standard sample build.mk with the "quick" profile, modified to have HADDOCK_DOCS = YES BUILD_DOCBOOK_HTML = YES and configure confirms that it will build docs. A full 'make' however leaves the source tree without any .haddock files inside, and a subsequent 'make install' does not install any .haddock files either. Moreover, curiously, no 'haddock' script is installed (only haddock-ghc-7.7.20130721) -- but perhaps that is expected? I can easily build the .haddock files manually by running "make html stage=0 FAST=YES" as per the wiki (inside, say, ../base/ in the source tree), and that works as expected, but a subsequent 'make install' in the root still does not install any .haddocks. I tried copying over the .haddock files manually, but now running haddock (copied from haddock-ghc-7.7.20130721) exits with haddock: internal error: /Users/dev/local/lib/ghc-7.7.20130721/html: getDirectoryContents: does not exist (No such file or directory) That path "/Users/dev/local/lib/ghc-7.7.20130721" is specified as the "topdir" in the haddock script and passed to the actual executable with -B and -l , and indeed that's where the libraries are installed. However, I don't understand why it's looking in ~/local/lib/ghc-7.7.20130721/html, because the html documentation is not installed there (but in ~/local/share/doc/ghc/html/libraries/). I'm shooting in the dark here really, I'm not really sure what's going on or what I've done wrong. Any pointers would be appreciated! Thanks, Edsko

2 4

Something stronger than IncoherentInstances needed (Univalent Classes?)
by Joachim Breitner 27 Jul '13

27 Jul '13

Hi, in the context of the newtype wrapper I have an instance selection problem where even IncoherentInstances is not liberal enough. Consider this example: Prelude> :set -XFlexibleInstances -XIncoherentInstances -XMultiParamTypeClasses Prelude> class Class a b where { method :: (a,b); method = undefined } Prelude> instance Class a b => Class [a] [b] Prelude> instance Class a a Prelude> :t method :: ([a],[a]) <interactive>:1:1: Overlapping instances for Class [a1] [a1] arising from a use of `method' Matching instances: instance [incoherent] Class a b => Class [a] [b] -- Defined at <interactive>:4:10 instance [incoherent] Class a a -- Defined at <interactive>:5:10 In the expression: method :: ([a], [a]) As none of the two instances are more specific than the other, the typechecker stops despite the incoherent flag. My suggestion is to add another flag, this time to the class declaration, marking the class as univalent (different naming suggestions welcome, of course), indicating that it will generally not matter which instance is selected, and in the case of overlap the typechecker should just pick any matching instance. Would such a feature be welcome? I could imagine that it might be more useful in other settings as well, e.g. if type classes are pure predicates about types, without any methods. Greetings, Joachim PS: I will be on a summer school the next two week. I have written down the status of the newtype coercion implementation at http://ghc.haskell.org/trac/ghc/wiki/NewtypeWrappers#Status -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 2

Perf tests which are better than expected on perf builds
by Edward Z. Yang 27 Jul '13

27 Jul '13

These tests have been doing better than expected in the nightlies for some while. > Unexpected failures: > perf/compiler T3064 [stat too good] (normal) > perf/compiler T3294 [stat too good] (normal) > perf/compiler T5642 [stat too good] (normal) > perf/haddock haddock.Cabal [stat too good] (normal) > perf/haddock haddock.base [stat too good] (normal) Unfortunately, fixing them is not a simple matter of shifting the ranges up, since the tests only exceed expectations on a /perf/ build, so on a normal build such as 'quick', these tests all pass normally. I could bump up the upper bounds so that the builder stops bleating about them; perhaps we could do something more complicated where the expected performance depends on what level of optimization GHC was built with (but I don't know how to implement this.) Thoughts? Cheers, Edward

2 2

whitehole_spin: always 0?
by Patrick Palka 26 Jul '13

26 Jul '13

It seems that the value of the whitehole_spin counter (as viewable by +RTS -s) is always zero, which oddly suggests that there is never any contention on the particular atomic operation whitehole_spin is tracking (located in copyPart in Evac.c). This may be a symptom of a bug, or it may be the case that the atomic operation is not necessary. (Or perhaps contention is just very rare. But if contention is rare, why is this operation being counted in particular?) Either way, I think this is a bit strange and probably worth investigating. Patrick

2 3

T5321FD and T5321Fun performance improvements
by Jan Stolarek 26 Jul '13

26 Jul '13

T5321FD and T5321Fun are failing with HEAD - performance stat is too good. Looks like the allocation has decreased. Did anyone notice when this improvement happened? Janek

2 2