- ghc-devs - Haskell.org

Typechecker plugins and BuiltInSynFamily
by Alexis King 23 Aug '19

23 Aug '19

Hello all, As I’ve been dabbling with typechecker plugins, I’ve found myself primarily using them to define new “magic” type families, and I don’t think I’m alone—Sandy Maguire recently released the magic-tyfams package for precisely that purpose. However, I can’t help but notice that GHC already has good internal support for such type families via BuiltInSynFamily and CoAxiomRule, which are mostly used to implement operations on Nats. As a plugin author, I would love to be able to use that functionality directly instead of being forced to reimplement it myself, for two big reasons: AxiomRuleCo provides significantly more safety from -dcore-lint than UnivCo, but UnivCo is currently the only way to provide evidence for plugin-solved families. The sfInteractTop and sfInteractInert fields of BuiltInSynFamily make it easy to support improvement for custom type families, which I believe would take a non-trivial amount of tricky code to get right using the current typechecker plugin API. Given the above, I started wondering if it is possible to define a BuiltInSynFamily from inside a plugin or, failing that, to modify GHC to expose that functionality to typechecker plugin authors. I am not familiar with GHC’s internals, but in my brief reading of the source code, the following two things seem like the trickiest obstacles: BuiltInSynFamily TyCons need to be injected into the initial name cache, since otherwise those names will get resolved to their ordinary, non-built-in counterparts (e.g. the ordinary open type families defined in GHC.TypeLits). Since CoAxiomRule values actually have functions inside them, they can’t be serialized into interface files. Therefore, it looks like GHC currently maintains a hardcoded list of all the known CoAxiomRules, and tcIfaceCoAxiomRule just searches for a value in that list using a well-known (i.e. not in any way namespaced!) string. I am not knowledgable enough about GHC to say how hard overcoming either of those issues would be. Point 1 seems possible to achieve by arranging for plugins to export the built-in names they want to define and propagating those to the initial name cache, but I don’t know enough about how plugins are loaded to know if that would create any possible circular dependencies (i.e. does the name cache need to already exist in order to load a plugin in the first place?). Point 2 seems harder. My gut instinct is that it could probably be overcome by somehow storing a reference to the plugin that defined the CoAxiomRule in the interface file (by, for example, storing its package-qualified module name), but I’m not immediately certain when that reference should be resolved to the actual CoAxiomRule value. It also presumably needs to complain if the necessary plugin is not actually loaded when the CoAxiomRule needs to be resolved! I’m willing to try my hand at experimenting with an implementation of this if someone can give me a couple pointers on where to start on the above two issues (assuming people don’t think it’s a bad idea to do it at all). Any advice would be appreciated! Thanks, Alexis

2 1

Linker error when adding a new source file
by Jan van Brügge 23 Aug '19

23 Aug '19

Hi, in order to clean up my code, I've moved a bunch of stuff to a new source file, `TcRowTys.hs` that works similar to `TcTypeNats.hs`. But when trying to compile a clean build of GHC, I get a linker error: ``` | Run Ghc LinkHs Stage0: _build/stage0/ghc/build/c/hschooks.o (and 1 more) => _build/stage0/bin/ghc _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(PrelInfo.o)(.text+0x2814): error: undefined reference to 'ghc_TcRowTys_rowTyCons_closure' _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(PrelInfo.o)(.data+0x578): error: undefined reference to 'ghc_TcRowTys_rowTyCons_closure' _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(TcHsType.o)(.data+0xdd8): error: undefined reference to 'ghc_TcRowTys_rnilTyCon_closure' collect2: Fehler: ld gab 1 als Ende-Status zurück `gcc' failed in phase `Linker'. (Exit code: 1) ``` I had a look at the Wiki including the FAQ, but did not fine anything about that topic. Does someone know what I have to do for this to work? Cheers, Jan

5 6

Re: `StablePtr` in `ST`
by Matthew Farkas-Dyck 23 Aug '19

23 Aug '19

My colleague responded but said it was rejected from ghc-devs. Message follows: On 21/08/2019, Jon Purdy <evincarofautumn(a)gmail.com> wrote: > Our use case is unsafeCoercing a mutable reference to use as a key in an > IntMap. Our reasoning is that coercing an IORef/STRef is unsuitable because > the underlying MutVar# may move, invalidating the key (i.e., you cannot > safely coerce back if a GC has happened between insertion and reading). (If > that’s incorrect, do enlighten us!) This is a “very nice to have” for our > purposes—with the understanding that it’s wicked unsafe. ;) > > On Tue, Aug 20, 2019, 18:09 David Feuer <david.feuer(a)gmail.com> wrote: > >> You also need to avoid inspecting the StablePtr itself, which is just a >> number, to maintain purity. The whole thing is a bit weird. Why do you >> want >> this anyway? >> >> On Wed, Aug 21, 2019, 7:39 AM David Feuer <david.feuer(a)gmail.com> wrote: >> >>> So something like >>> >>> newtype StablePtr a = StablePtr (StablePtrST RealWorld a)? >>> >>> I suppose that could work with some discipline. You have to assume that >>> foreign code doesn't pick its address out of a hat and so something >>> silly, >>> but I guess you pretty much have to assume that anyway. >>> >>> On Wed, Aug 21, 2019, 5:00 AM Matthew Farkas-Dyck <strake888(a)gmail.com> >>> wrote: >>> >>>> I have been doing some work where i want `StablePtr`, but also to not >>>> be confined to `IO`. I saw the following comment in >>>> "compiler/prelude/PrimOp.hs": >>>> >>>> Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? >>>> [ADR] >>>> >>>> It has been there for 20 years. What is the answer? If it is safe i'll >>>> send the patch generalizing these operations. >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >

1 0

Stream Simon's report on HIW?
by Artem Pelenitsyn 22 Aug '19

22 Aug '19

Hello devs, Could someone at ICFP maybe stream Simon's report on the progress GHC made last year? I'm pretty sure many would like to check it out. Conference management streamed the main event but not the workshops. And workshops videos are such a pain: HIW 2018 is still not up on the ICFP youtube channel, although HIW 2017 and 2016 are: https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/playlists (And Haskell 2018 playlist there has only 8 videos…) -- Kind regards, Artem

2 1

Missing library in Mac OS X instructions?
by Alejandro Serrano Mena 21 Aug '19

21 Aug '19

Hi, I tried to get GHC working from the repo in Mac OS X following the instructions in https://gitlab.haskell.org/ghc/ghc/wikis/building/preparation/mac-osx. At first I got the "error __GNU_MP_VERSION not defined" problem, for which the guide recommends to prepend "CC=clang" to "./configure" , which I did. But even then, I also had to install "gmp" using "brew install gmp". 1. Is it right that I need to install gmp using brew or did I miss some previous step? 2. If (1) is affirmative, how can I help update the docs for building in Mac OS X? Regards, Alejandro

3 3

`StablePtr` in `ST`
by Matthew Farkas-Dyck 21 Aug '19

21 Aug '19

I have been doing some work where i want `StablePtr`, but also to not be confined to `IO`. I saw the following comment in "compiler/prelude/PrimOp.hs": Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? [ADR] It has been there for 20 years. What is the answer? If it is safe i'll send the patch generalizing these operations.

2 2

Contributing to GHC : Newbie
by Avneesh Chadha 20 Aug '19

20 Aug '19

Hi, I am trying to contribute to GHC and am a complete newbie at this. The new contribution guide pointed me to the issues page(I was able to build the GHC from the code), and I was able to find this <https://gitlab.haskell.org/ghc/ghc/issues/16766> feature request. However it does not have any information apart from the feature information. Could someone please add more information to the issue? Warm Regards, Avneesh Chadha Phone:+917838478116 GitHub <https://github.com/avneesh91>|LinkedIn <https://www.linkedin.com/in/avneesh-chadha-0bb6b7aa/>|Blog <https://technokeeda.com/> PS: I am sorry for spamming everyone in-case this is not the correct forum , I would appreciate if someone could point to the right one.

2 1

Haskell implementors workshop
by Simon Peyton Jones 19 Aug '19

19 Aug '19

Colleagues At the Haskell Implementors Workshop on Friday there is a 23-min slot for an update on GHC status. It's followed by panel discussion. In our annual status reports I have typically summarised what is going on with a few slides. But as GHC grows, and more people contribute, it gets harder to do a good job of making such a summary. So this year I plan to: 1. Summarise some highlights that I know about 2. Invite anyone in the room who would like to briefly describe what they are working on - or have proudly completed in the last year - to grab the microphone and tell everyone about it. 3. Ben will summarise progress on CI, Gitlab, and Hadrian 4. Joachim will say what's happened on the GHC-proposal front To make (2) work * Come to the front so that each handover takes only a few seconds. * Be enthusiastic but brief. Thirty seconds, not two minutes. We only have 25 mins for the whole thing. * If you aren't at ICFP, but would have liked to describe your project to the audience, do send me a couple of sentences that I can use on your behalf. * It's a GHC status session, so anything in the GHC ecosystem is fair game, including different back ends, IDE work, plugins, etc. Tell me in advance if you like, but it's also fine just to be ready on the day. Thanks! Simon

1 0

Properly writing typechecker plugins
by Alexis King 17 Aug '19

17 Aug '19

Hi all, I have recently decided to try writing a GHC typechecker plugin so I can get my hands on some extra operations on type-level strings. My plugin works, but only sort of—I know some things about it are plain wrong, and I have a sneaking suspicion that plenty of other things are not handled properly. First, some context about what I do and don’t already know: I have a high-level understanding of the basic concepts behind GHC’s solver. I understand what evidence is and what purpose it serves, I mostly understand the different flavors of constraints, and I think I have a decent grasp on some of the operational details of how individual passes work. I’ve spent a little time reading through comments in the GHC source code, along with pieces of the source code itself, but I’m sure my understanding is pretty patchy. With that out of the way, here are my questions: First, I’m trying to understand: why are wanted constraints passed to typechecker plugins unflattened? This is my single biggest point of confusion. It certainly seems like the opposite of what I want. Consider that I have a type family type family ToUpper (s :: Symbol) :: Symbol where {} that I wish to solve in my plugin. At first, I just naïvely looked through the bag of wanted constraints and looked for constraints of the shape t ~ ToUpper s but this isn’t good enough, since my plugin regularly receives constraints that look more like t ~ SomeOtherTypeFamily (ToUpper s) so I have to recursively grovel through every type equality constraint looking for an application of a family I care about. Furthermore, once I’ve found one, I’m not sure how to actually let GHC know that I’ve solved it—do I really have to just generate a new given constraint and let GHC’s solver connect the dots? I have seen the note on the typechecker plugins wiki page <https://gitlab.haskell.org/ghc/ghc/wikis/plugins/type-checker#under-discuss…> about possibly baking support for type families into the plugin interface, which would indeed be nicer than the status quo, but it seems odd to me that they aren’t just passed to plugins flattened, which seems like it would spare a lot of effort. Isn’t the flattened representation really what typechecker plugins would like to see, anyway? But let’s put families aside for a moment. I’m not just solving type families in my plugin, I’m also solving classes. These classes have no methods, but they do have functional dependencies. For example, I have a class class Append (a :: Symbol) (b :: Symbol) (c :: Symbol) | a b -> c, a c -> b, b c -> a which is like GHC.TypeLits.AppendSymbol, but the fundeps make GHC a bit happier when running it “backwards” (since GHC doesn’t really know about AppendSymbol’s magical injectivity, so it sometimes complains). In any case, I was hoping that GHC’s solver would handle the improvement afforded by the fundeps for me once I provided evidence for Append constraints, but that doesn’t seem to be the case. Currently, I am therefore manually generating derived constraints based on the functional dependency information, plumbing FunDepOrigin2 through and all. Is there some way to cooperate better with GHC’s solver so I don’t have to duplicate all that logic in my plugin? I guess one thing I didn’t try is returning given constraints from my solver instead of just solving them and providing evidence. That is, if my plugin received a [W] d1 :: Append "foo" "bar" c constraint, then instead of solving the constraint directly, I could leave it alone and instead return a new constraint [G] d2 :: Append "foo" "bar" "baz" and presumably GHC’s solver would use that constraint to improve and solve d1. But similar to my confusion about type families above, I’m uncertain if that’s the intended method or not, since it seems like it’s sort of circumventing the plugin API. Finally, on a related note, building evidence for these solver-generated typeclass instances is a bit of a pain. They have no methods, but they do sometimes have superclasses. Currently, I’ve been generating CoreExprs as carefully as I’m able to after reading through the desugaring code: I call dataConWrapId on the result of classDataCon, then use mkTyConApp and mkCoreApps on that directly. It seems to work okay now, but it didn’t always: -dcore-lint thankfully caught my mistakes, but I’ve been wondering if there’s a safer way to build the dictionary that I’ve been missing. That’s it for now—I’ve just been muddling through until things work. Once I get something that feels closer to right, maybe I’ll put the code somewhere and ask for more low-level comments if anyone would like to take the time to offer them, but for now, I’m still working on the high-level ideas. The wiki pages I’ve found have been very helpful; my appreciation to all who have contributed to them! Many thanks, Alexis

2 4

ANN: IOHK is looking for Functional Compiler Engineers
by Manuel M T Chakravarty 13 Aug '19

13 Aug '19

The IOHK Plutus Team, which works on a Haskell-based platform for contracts on the Cardano blockchain, is looking for new team members: https://iohk.io/careers/#op-341518-functional-compiler-engineer See also Phil Wadler’s blog post: http://wadler.blogspot.com/2019/08/iohk-is-hiring.html A core component of the Plutus Platform is a GHC plugin that translates GHC Core to the on-chain Plutus Core language. A central part of the underlying transformation scheme is described in https://iohk.io/research/library/#unraveling-recursion-compiling-an-ir-with… Manuel

1 0