- ghc-devs - Haskell.org

RE: Hadrian
by Andrey Mokhov 20 Oct '17

20 Oct '17

Hi Moritz and Herbert, Thank you for detailed comments! We clearly need to carefully think through our options for merging Hadrian. Can I invite you both and everyone else to continue the discussion in https://github.com/snowleopard/hadrian/issues/440? Long email threads tend to become hard to read/follow and get lost. In my view, the two most important requirements in the long term are: 1) Preserving the commit/issue/pull-request history. A GHC developer fighting a strange build failure should be able to find a relevant discussion not only now but in 5 years from now. This may be solved via documentation, i.e. gradually moving all discussions from GitHub to docs/comments. That's a lot of hard work. 2) Making it convenient for GHC developers to work on Hadrian. To me, git submodules are not convenient at all, but maybe there is just no other option given the requirement (1). Is git subtree a solution? Cheers, Andrey

2 1

Re: Determine instance method from class method callsite
by Tillmann Vogt 20 Oct '17

20 Oct '17

I have the same problem with a compiler plugin that I am writing. In GHC Core I need to get from a dict-fun identifier (e.g. $fMyClassDouble to the type class instance bindr (starting with $c). lookupInstEnv from the InstEnv module seemed to do it, but it seems to look up the matching key from a set of instEnv keys and not anything that contains the instance bindr. Not sure. Where is the dictionary lookup that gives me the bindr? What I did so far: evalExpr :: DynFlags -> ModGuts -> CoreExpr -> Var -> CoreM NodeType evalExpr dflags guts (Var iD) v = do hsc_env <- getHscEnv eps <- liftIO (hscEPS hsc_env) let instEnvs = InstEnvs (eps_inst_env eps) (mg_inst_env guts) (mkModuleSet (dep_orphs (mg_deps guts))) let ty = tyConAppTyCon_maybe (idType iD) let cl = fromJust (tyConClass_maybe (fromJust ty)) let tys = snd (splitTyConApp (idType iD)) let (matches,_,_) | isDictId iD = lookupInstEnv False instEnvs cl tys | otherwise = ([],[],[]) let inst = map (nameStableString . varName . is_dfun . fst) matches liftIO $ B.appendFile ("debug.txt") (B.pack (show inst))

2 1

RE: Hadrian
by Andrey Mokhov 20 Oct '17

20 Oct '17

Hi Ben, > Well, the GitHub repo will still exist. Is that enough? Yes, but I think I'll need to do some clean up in the code so that it's obvious where to look for answers. For example, here is a random comment from a Hadrian source file: -- Objdump is only required on OpenBSD and AIX, as mentioned in #211. The reader might confuse this with GHC ticket #211, so I guess this should be replaced with a full link https://github.com/snowleopard/hadrian/issues/211. There may be other potential pitfalls, but hopefully nothing difficult to handle. I've created an issue to discuss and prepare for the merge: https://github.com/snowleopard/hadrian/issues/440. Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 19 October 2017 21:50 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Boespflug, Mathieu <m(a)tweag.io> Cc: Jonas Pfenniger Chevalier <jonas.chevalier(a)tweag.io>; Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io>; ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Thanks Ben, > > Just to clarify: By history I mean not just commits, but GitHub issues > and PRs as well -- together they contain a lot of valuable interlinked > information for GHC/Hadrian developers. > Well, the GitHub repo will still exist. Is that enough? Cheers, - Ben

3 3

RE: Hadrian
by Andrey Mokhov 19 Oct '17

19 Oct '17

Thanks Ben, Just to clarify: By history I mean not just commits, but GitHub issues and PRs as well -- together they contain a lot of valuable interlinked information for GHC/Hadrian developers. > That is pretty much precisely the use-case which > git subtree was designed to address. This will allow us to have Hadrian, > with history, in the GHC tree and you can continue to develop it on > GitHub until things have stabilized. Sounds great. I haven't used git subtrees before, so I'll need to do some reading, but if everyone is happy with merging Hadrian as is, I can prepare a patch over the weekend! Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 19 October 2017 20:50 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Boespflug, Mathieu <m(a)tweag.io> Cc: Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io>; Moritz Angermann <moritz.angermann(a)gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier(a)tweag.io>; ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Hi Mathieu, > > Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over. > > My only concern is that merging will make it more difficult for us to > quickly iterate on Hadrian: the GitHub workflow is more convenient (at > least for me) than the Phabricator one. Perhaps, we can keep Hadrian > on GitHub as a submodule? This also has the advantage that we can keep > all existing references to GitHub issues/PRs without migrating > everything to GHC Trac. It would be very unfortunate to lose all > history during the merge. > Okay, so if we want to preserve history then I would suggest that we go the subtree route. That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized. The only question is how to ensure that the subtree remains up-to-date. Cheers, - Ben

2 1

RE: Hadrian
by Ben Gamari 19 Oct '17

19 Oct '17

Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Hi Mathieu, > > Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over. > > My only concern is that merging will make it more difficult for us to > quickly iterate on Hadrian: the GitHub workflow is more convenient (at > least for me) than the Phabricator one. Perhaps, we can keep Hadrian > on GitHub as a submodule? This also has the advantage that we can keep > all existing references to GitHub issues/PRs without migrating > everything to GHC Trac. It would be very unfortunate to lose all > history during the merge. > Okay, so if we want to preserve history then I would suggest that we go the subtree route. That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized. The only question is how to ensure that the subtree remains up-to-date. Cheers, - Ben

1 0

Re: Hadrian
by Boespflug, Mathieu 19 Oct '17

19 Oct '17

Hi all, As a user who tried to be an early adopter of Hadrian, I can attest to Andrey's remarks about GHC progress sometimes (frequently?) breaking Hadrian. Ben, Andrey - how about this strawman proposal: we merge Hadrian into GHC *now*, not because ./validate with Hadrian works (it doesn't yet), but because the build of GHC succeeds with Hadrian. The resulting compiler might well be garbage. But that's fine - we can iterate in the official ghc repo, all the while knowing that CI has our back if ever some change makes Hadrian no longer even build a compiler. Once ./validate passes with Hadrian, the guarantee that CI gives will become stronger still: we'll know if any change would make the Hadrian-produced compiler garbage again. Maybe that does sound totally bonkers to you? :) Maybe it's radical, but sounds to me like the best way to get the benefit *now* of ensuring Make and Hadrian move forward in lock step thanks to CI. The above all assumes that we're committed to Hadrian being the future of GHC's build system. But I take it that's a given by now. Best, Mathieu On 19 October 2017 at 19:05, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> wrote: > Hi Ben, Manuel and all, > > Ben has already covered most questions in his answer, but let me add a couple of comments. > >> So, Mathieu had the clever idea that having the two build system in >> GHC side-by-side and then build in CI both ways might be a good way of >> making sure that keep constant tabs on Hadian and get a clear (and >> continuous picture) of where it is and what is missing. > > It would be great to build every GHC commit both by Make and Hadrian. Not only this would allow to monitor the readiness of Hadrian, it would also make it easier for us to catch up with changes in GHC and the Make build system. At the moment, Hadrian is frequently broken by changes in GHC/Make and we need to do detective work of figuring out which commit broke what and fix Hadrian accordingly. These fixes are trivial in many cases (e.g. adding a new flag to one of the builders) so GHC developers would probably be able to easily mirror these changes in Hadrian if only their commits were marked as Hadrian-breaking by the common CI. > >> In other words, why can’t we have Hadrian *today*? > > I'd say the biggest issue is #299 -- i.e. making sure that the GHC built by Hadrian passes validation. At the moment we still have 100-200 unexpected failures, most of which probably have to do with outdated command line flags (GHC's build system continuously evolves and it wasn't possible to keep track of all flag changes over time, so there are certainly some differences in Hadrian that lead to validation failures). This is where help is currently needed. > > Cheers, > Andrey > > -----Original Message----- > From: Ben Gamari [mailto:ben@well-typed.com] > Sent: 19 October 2017 15:08 > To: Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io> > Cc: Mathieu Boespflug <m(a)tweag.io>; Moritz Angermann <moritz.angermann(a)gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier(a)tweag.io>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> > Subject: Re: Hadrian > > CCing Andrey and Zhen, who are the principle authors of Hadrian. > > Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io> writes: > >> Hi Ben, >> >> I our exploration of cross-compilation for GHC and the CI integration, >> we talked with Moritz and got to the topic of Hadrian. It seems that >> there are few interdependent issues here, and I am really interested >> in getting your take on them. >> >> * Hadrian is slated for inclusion for 8.4, but I couldn’t find any >> tickets except #12599. Is this because Hadrian has its own issue >> tracker on GitHub? How can I get an overview over what’s missing in >> getting Hadrian into GHC? >> > Right, Hadrian tickets are currently tracked in its own issue tracker. > >> * For Moritz’ work on ARM and also for CI cross-compiling is >> important, but Moritz pointed out rightly that it seems wasteful put >> much time into improving this in the make-based build system if that >> is going to go soon anyway. However, because Hadrian is not in yet, >> doing the work on Hadrian now also doesn’t really make sense. >> > Indeed. Hadrian is one of the things I am currently working on for > precisely this reason. > >> * Obviously, one issue with Hadrian is stability and feature >> completeness. This has ramifications on our desire to really get 8.4 >> out of the door in February and not delay the release and also get the >> CI done, because good CI is the best way of making sure the Hadrian >> integration goes smoothly. (There is obviously a cyclic dependence >> between this point and the previous.) >> >> So, Mathieu had the clever idea that having the two build system in >> GHC side-by-side and then build in CI both ways might be a good way of >> making sure that keep constant tabs on Hadian and get a clear (and >> continuous picture) of where it is and what is missing. It would also >> allow Moritz to do cross-compilation work right there on Hadrian. >> >> In other words, why can’t we have Hadrian *today*? >> > At this point the plan is for Hadrian and the Make-based build system to > coexist in 8.4, with the make system serving as a backup. > > Well, we could (and potentially should) merge Hadrian > >> If the limiting factor is resources, maybe we can do something about >> that, but it would require a good solid plan that we can execute >> perfectly when given the opportunity. >> > The blocking issues in Hadrian are tagged with the "GHC Merge" project > in the issue tracker. The overall themes currently are, > > * Fixing validation support (finishing #187) > > * Support the remaining test targets (#360) > > * Documentation, so we don't overwhelm Andrey with questions when > things break. (#308) > > * Finish and test install rules (#318, #373, #379) > > * bindist install (the last part of #219). I started working on this, > although for the moment bugs and 8.2.2 have taken priority. > > Andrey, do correct me if I've missed something. > > Help is of course always welcome! > > Cheers, > > - Ben >

2 1

RE: Hadrian
by Andrey Mokhov 19 Oct '17

19 Oct '17

Hi Mathieu, Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over. My only concern is that merging will make it more difficult for us to quickly iterate on Hadrian: the GitHub workflow is more convenient (at least for me) than the Phabricator one. Perhaps, we can keep Hadrian on GitHub as a submodule? This also has the advantage that we can keep all existing references to GitHub issues/PRs without migrating everything to GHC Trac. It would be very unfortunate to lose all history during the merge. Cheers, Andrey -----Original Message----- From: Boespflug, Mathieu [mailto:m@tweag.io] Sent: 19 October 2017 19:21 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: Ben Gamari <ben(a)well-typed.com>; Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io>; Moritz Angermann <moritz.angermann(a)gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier(a)tweag.io>; ghc-devs <ghc-devs(a)haskell.org> Subject: Re: Hadrian Hi all, As a user who tried to be an early adopter of Hadrian, I can attest to Andrey's remarks about GHC progress sometimes (frequently?) breaking Hadrian. Ben, Andrey - how about this strawman proposal: we merge Hadrian into GHC *now*, not because ./validate with Hadrian works (it doesn't yet), but because the build of GHC succeeds with Hadrian. The resulting compiler might well be garbage. But that's fine - we can iterate in the official ghc repo, all the while knowing that CI has our back if ever some change makes Hadrian no longer even build a compiler. Once ./validate passes with Hadrian, the guarantee that CI gives will become stronger still: we'll know if any change would make the Hadrian-produced compiler garbage again. Maybe that does sound totally bonkers to you? :) Maybe it's radical, but sounds to me like the best way to get the benefit *now* of ensuring Make and Hadrian move forward in lock step thanks to CI. The above all assumes that we're committed to Hadrian being the future of GHC's build system. But I take it that's a given by now. Best, Mathieu On 19 October 2017 at 19:05, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> wrote: > Hi Ben, Manuel and all, > > Ben has already covered most questions in his answer, but let me add a couple of comments. > >> So, Mathieu had the clever idea that having the two build system in >> GHC side-by-side and then build in CI both ways might be a good way of >> making sure that keep constant tabs on Hadian and get a clear (and >> continuous picture) of where it is and what is missing. > > It would be great to build every GHC commit both by Make and Hadrian. Not only this would allow to monitor the readiness of Hadrian, it would also make it easier for us to catch up with changes in GHC and the Make build system. At the moment, Hadrian is frequently broken by changes in GHC/Make and we need to do detective work of figuring out which commit broke what and fix Hadrian accordingly. These fixes are trivial in many cases (e.g. adding a new flag to one of the builders) so GHC developers would probably be able to easily mirror these changes in Hadrian if only their commits were marked as Hadrian-breaking by the common CI. > >> In other words, why can’t we have Hadrian *today*? > > I'd say the biggest issue is #299 -- i.e. making sure that the GHC built by Hadrian passes validation. At the moment we still have 100-200 unexpected failures, most of which probably have to do with outdated command line flags (GHC's build system continuously evolves and it wasn't possible to keep track of all flag changes over time, so there are certainly some differences in Hadrian that lead to validation failures). This is where help is currently needed. > > Cheers, > Andrey > > -----Original Message----- > From: Ben Gamari [mailto:ben@well-typed.com] > Sent: 19 October 2017 15:08 > To: Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io> > Cc: Mathieu Boespflug <m(a)tweag.io>; Moritz Angermann <moritz.angermann(a)gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier(a)tweag.io>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> > Subject: Re: Hadrian > > CCing Andrey and Zhen, who are the principle authors of Hadrian. > > Manuel M T Chakravarty <manuel.chakravarty(a)tweag.io> writes: > >> Hi Ben, >> >> I our exploration of cross-compilation for GHC and the CI integration, >> we talked with Moritz and got to the topic of Hadrian. It seems that >> there are few interdependent issues here, and I am really interested >> in getting your take on them. >> >> * Hadrian is slated for inclusion for 8.4, but I couldn’t find any >> tickets except #12599. Is this because Hadrian has its own issue >> tracker on GitHub? How can I get an overview over what’s missing in >> getting Hadrian into GHC? >> > Right, Hadrian tickets are currently tracked in its own issue tracker. > >> * For Moritz’ work on ARM and also for CI cross-compiling is >> important, but Moritz pointed out rightly that it seems wasteful put >> much time into improving this in the make-based build system if that >> is going to go soon anyway. However, because Hadrian is not in yet, >> doing the work on Hadrian now also doesn’t really make sense. >> > Indeed. Hadrian is one of the things I am currently working on for > precisely this reason. > >> * Obviously, one issue with Hadrian is stability and feature >> completeness. This has ramifications on our desire to really get 8.4 >> out of the door in February and not delay the release and also get the >> CI done, because good CI is the best way of making sure the Hadrian >> integration goes smoothly. (There is obviously a cyclic dependence >> between this point and the previous.) >> >> So, Mathieu had the clever idea that having the two build system in >> GHC side-by-side and then build in CI both ways might be a good way of >> making sure that keep constant tabs on Hadian and get a clear (and >> continuous picture) of where it is and what is missing. It would also >> allow Moritz to do cross-compilation work right there on Hadrian. >> >> In other words, why can’t we have Hadrian *today*? >> > At this point the plan is for Hadrian and the Make-based build system to > coexist in 8.4, with the make system serving as a backup. > > Well, we could (and potentially should) merge Hadrian > >> If the limiting factor is resources, maybe we can do something about >> that, but it would require a good solid plan that we can execute >> perfectly when given the opportunity. >> > The blocking issues in Hadrian are tagged with the "GHC Merge" project > in the issue tracker. The overall themes currently are, > > * Fixing validation support (finishing #187) > > * Support the remaining test targets (#360) > > * Documentation, so we don't overwhelm Andrey with questions when > things break. (#308) > > * Finish and test install rules (#318, #373, #379) > > * bindist install (the last part of #219). I started working on this, > although for the moment bugs and 8.2.2 have taken priority. > > Andrey, do correct me if I've missed something. > > Help is of course always welcome! > > Cheers, > > - Ben >

1 0

[ANN] GHC DevOps Group
by Manuel M T Chakravarty 19 Oct '17

19 Oct '17

We announced the GHC DevOps Group at the Haskell Implementors’ Workshop in Oxford earlier this year in Simon PJ’s ”Progress on GHC” session. (The videos are unfortunately not yet online.) To finally announce it more broadly, I wrote a blog post: http://www.tweag.io/posts/2017-10-19-ghc-devops-group.html Cheers, Manuel

1 0

RE: GHC rewrite rule type-checking failure
by Simon Peyton Jones 17 Oct '17

17 Oct '17

The new bit here is that `$dC'` is not found via matching in the LHS, but rather by instance resolution from `k`, which does appear explicitly in the LHS Well this would be something qualitatively new. We don’t that ability in rules; and it’s far from clear to me what it would mean anyway. I suppose that if k was instantiated to a ground type then you might hope to solve it, but what if it was instantiated to some in-scope type variable t, and some variable of type (C t) was in scope. Should that work too? I’m highly dubious. Happily it sounds as if you are making progress with help from Joachim. Simon From: conal.elliott(a)gmail.com [mailto:conal.elliott@gmail.com] On Behalf Of Conal Elliott Sent: 03 October 2017 16:30 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: GHC rewrite rule type-checking failure The revised example I gave earlier in the thread: ``` haskell class C k where comp' :: k b c -> k a b -> k a c instance C (->) where comp' = (.) -- Late-inlining version to enable rewriting. comp :: C k => k b c -> k a b -> k a c comp = comp' {-# INLINE [0] comp #-} morph :: (a -> b) -> k a b morph = error "morph: undefined" {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-} -- • Could not deduce (C k) arising from a use of ‘comp’ -- from the context: C (->) -- bound by the RULE "morph/(.)" ``` A hypothetical generated Core rule (tweaked slightly from Joachim's note): ``` haskell forall (@ k) (@ b) (@ c) (@ a) ($dC :: C (->)) (f :: a -> b) (g :: b -> c). morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f) = comp @ k @ b @ c @ a $dC' (morph @ k @ b @ c g) (morph @ k @ a @ b f) where $dC' :: C k ``` The new bit here is that `$dC'` is not found via matching in the LHS, but rather by instance resolution from `k`, which does appear explicitly in the LHS. If `C k` cannot be solved, the rule fails. The "where" clause here lists the dictionary variables to be instantiated by instance resolution rather than matching. -- Conal On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: But synthesising from what? And currently no: there is no type-class dictionary synthesis after the type checker. Not impossible I suppose, but one more fragility: a rule does not fire because some synthesis thing didn’t happen. Maybe give an as-simple-as-poss example of what you have in mind, now you understand the situation better? With all the type and dictionary abstractions written explicitly… S From: conal.elliott(a)gmail.com<mailto:conal.elliott@gmail.com> [mailto:conal.elliott@gmail.com<mailto:conal.elliott@gmail.com>] On Behalf Of Conal Elliott Sent: 03 October 2017 15:56 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: GHC rewrite rule type-checking failure Thanks, Simon. Your explanation make sense to me. Do you think that the rewrite rule mechanism could be enhanced to try synthesizing the needed dictionaries after LHS matching and before RHS instantiation? I'm doing as much now in my compiling-to-categories plugin, but without the convenience of using concrete syntax for the rules. Regard, - Conal On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: * Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition? I don’t think so. Remember that a rewrite rule literally rewrites LHS to RHS. It does not conjure up any new dictionaries out of thin air. In your example, (D k b) is needed in the result of the rewrite. Where can it come from? Only from something matched on the left. So GHC treats any dictionaries matched on the left as “givens” and tries to solve the ones matched on the left. If it fails you get the sort of error you see. One way to see this is to write out the rewrite rule you want, complete with all its dictionary arguments. Can you do that? Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org<mailto:glasgow-haskell-users-bounces@haskell.org>] On Behalf Of Conal Elliott Sent: 03 October 2017 01:03 To: Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> Cc: glasgow-haskell-users(a)haskell.org<mailto:glasgow-haskell-users@haskell.org> Subject: Re: GHC rewrite rule type-checking failure Thanks very much for the reply, Joachim. Oops! I flubbed the example. I really `morph` to distribute over an application of `comp`. New code below (and attached). You're right that I wouldn't want to restrict the type of `morph`, since each `morph` *rule* imposes its own restrictions. My questions: * Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition? * Is there any way I can make the needed constraints explicit in my rewrite rules? * Are there any other work-arounds that would enable writing such RHS-constrained rules? Regards, -- Conal ``` haskell {-# OPTIONS_GHC -Wall #-} -- Demonstrate a type checking failure with rewrite rules module RuleFail where class C k where comp' :: k b c -> k a b -> k a c instance C (->) where comp' = (.) -- Late-inlining version to enable rewriting. comp :: C k => k b c -> k a b -> k a c comp = comp' {-# INLINE [0] comp #-} morph :: (a -> b) -> k a b morph = error "morph: undefined" {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-} -- • Could not deduce (C k) arising from a use of ‘comp’ -- from the context: C (->) -- bound by the RULE "morph/(.)" ``` On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de>> wrote: Hi Conal, The difference is that the LHS of the first rule is mentions the `C k` constraint (probably unintentionally): *RuleFail> :t morph comp morph comp :: C k => k1 (k b c) (k a b -> k a c) but the LHS of the second rule side does not: *RuleFail> :t morph addC morph addC :: Num b => k (b, b) b A work-around is to add the constraint to `morph`: morph :: D k b => (a -> b) -> k a b morph = error "morph: undefined" but I fear that this work-around is not acceptable to you. Joachim Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott: > -- Demonstrate a type checking failure with rewrite rules > > module RuleFail where > > class C k where comp' :: k b c -> k a b -> k a c > > instance C (->) where comp' = (.) > > -- Late-inlining version to enable rewriting. > comp :: C k => k b c -> k a b -> k a c > comp = comp' > {-# INLINE [0] comp #-} > > morph :: (a -> b) -> k a b > morph = error "morph: undefined" > > {-# RULES "morph/(.)" morph comp = comp #-} -- Fine > class D k a where addC' :: k (a,a) a > > instance Num a => D (->) a where addC' = uncurry (+) > > -- Late-inlining version to enable rewriting. > addC :: D k a => k (a,a) a > addC = addC' > {-# INLINE [0] addC #-} > > {-# RULES "morph/addC" morph addC = addC #-} -- Fail > > -- • Could not deduce (D k b) arising from a use of ‘addC’ > -- from the context: D (->) b > > -- Why does GHC infer the (C k) constraint for the first rule but not (D k b) > -- for the second rule? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…> -- Joachim Breitner mail(a)joachim-breitner.de<mailto:mail@joachim-breitner.de> http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim…>

2 4

Compiling natively GHC for ARMv7l softabi
by shiftag＠nanotek.info 16 Oct '17

16 Oct '17

Hi List, I would like to install GHC for my CPU which is an ARMv7L Soft-ABI NEON FPU. I read some stuff on ARM and GHC related. So it appears that an installation is possible but with a RPi. The problem is the stack binary which has been compiled for Hard-Float target. So it should not be difficult to make it work for my architecture. I checked for stack sources (stack-1.5.1.tar.gz) but I have any clue about how to compile it. Can you give me an hand ? Cheers, PS: For info, usually I compiled natively that way : "-march=armv7-a -mfpu=neon -mtune=cortex-a9"

2 1