Reading type families from interface files
Devs, Is there a plumbing for returning declarations (not instances) of type families from an interface file? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Current description of Core?
Another tactic, that might be more effective/simpler, is to work out what primops you want to use that aren't currently in core. It looks like all the kappa calclus operations are expressible in core, so perhaps what you really want are better markers that an expression in core might be kappa calculus like in some fashion? I'm happy to help you suss that out on IRC or the like! cheers -Carter On Wed, Oct 22, 2014 at 6:18 AM, Sophie Taylor sop...@traumapony.org wrote: Yeah, definitely. Part of the reason why arrow notation is so frustrating at the moment is because it forces everything into lambda calculus; that is, it requires every category to be Cartesian Closed. When your arrow category isn't Cartesian Closed, it raises two issues. 1) When it's not Cartesian, you have to lie and say it supports products instead of tensors (that is, you are able to get back the arguments of a product unchanged, i.e. simple tuples), but this isn't the relevant part for Core. 2) When it's not closed, you have to lie and say it supports higher order functions (i.e., lambda abstractions applied to lambda abstractions) and implement arr. Now, you can lie at the syntax level and typecheck it as kappa calculus (i.e. first order functions only unless you are explicitly a Closed category) but then say it is lambda calculus at the core level; this would work because lambda calculus subsumes kappa calculus. This would allow the optimiser/RULES etc to work unchanged. However, you would lose a lot of the internal consistency checking usefulness of Core, and could miss out on kappa-calculus-specific optimisations (although come to think of it, call arity analysis might solve a lot of this issue). On 22 October 2014 19:59, Simon Peyton Jones simo...@microsoft.com wrote: Interesting. There is a pretty high bar for changes to Core itself. Currently arrow notation desugars into Core with no changes. If you want to change Core, then arrow “notation” is actually much more than syntactic sugar. Go for it – but it would be a much more foundational change than previously, and hence would require more motivation. S *From:* Sophie Taylor [mailto:sop...@traumapony.org] *Sent:* 22 October 2014 10:53 *To:* Simon Peyton Jones *Cc:* ghc-devs@haskell.org *Subject:* Re: Current description of Core? Ah, thanks HEAPS. I've been banging my head against a wall for the last few days trying to see exactly what is going on :) I'm trying to find a way to minimise/eliminate the changes required to Core for the arrow notation rewrite - specifically, introducing kappa abstraction and application - semantically different to lambda abstraction/application but close enough that I can probably get away with either adding a simple flag to the Abstraction/Application constructors or doing it higher up in the HsExpr land, but the latter method leaves a sour taste in my mouth. On 22 October 2014 19:35, Simon Peyton Jones simo...@microsoft.com wrote: Is the current description of Core still System FC_2 (described in https://www.seas.upenn.edu/~sweirich/papers/popl163af-weirich.pdf)? We never implemented that particular version (too complicated!). This is the full current story (thanks to Richard for keeping it up to date), in the GHC source tree : https://ghc.haskell.org/trac/ghc/browser/ghc/docs/core-spec/core-spec.pdf Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Sophie Taylor *Sent:* 22 October 2014 10:26 *To:* ghc-devs@haskell.org *Subject:* Current description of Core? Hi, Is the current description of Core still System FC_2 (described in https://www.seas.upenn.edu/~sweirich/papers/popl163af-weirich.pdf)? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Reading type families from interface files
I don't know what you mean. Can you be more explicit. The mi_fam_insts field of a ModIface sounds like what you want | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan | Stolarek | Sent: 23 October 2014 08:50 | To: ghc-devs@haskell.org | Subject: Reading type families from interface files | | Devs, | | Is there a plumbing for returning declarations (not instances) of type | families from an interface file? | | Janek | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Reading type families from interface files
Say I have: module Foo where type family F a type instance F Int = Char mi_fam_insts stores type family instances, in that case F Int = Char. What I would like to load is type family declaration: F a. If that does not exist already I wonder whether information about type family declarations should be cached in ModDetails in the same way md_fam_insts caches information about instances? Rationale: I want to load information about tyfam declarations in FamInst.checkFamInstConsistency and pass these definitions of type families to FamInst.checkForConflicts. My plan is to verify whether an open type family is injective at the same time when looking for conflicts. Janek Dnia czwartek, 23 października 2014, napisałeś: I don't know what you mean. Can you be more explicit. The mi_fam_insts field of a ModIface sounds like what you want | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan | Stolarek | Sent: 23 October 2014 08:50 | To: ghc-devs@haskell.org | Subject: Reading type families from interface files | | Devs, | | Is there a plumbing for returning declarations (not instances) of type | families from an interface file? | | Janek | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Reading type families from interface files
It's in mi_decls, along with data type declarations, class declarations, and the like. If you are talking about a ModDetails, then look in the range of md_types; the TyThings there include all the data types, classes, and type families declared in this module S | -Original Message- | From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl] | Sent: 23 October 2014 11:31 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: Re: Reading type families from interface files | | Say I have: | | module Foo where | type family F a | type instance F Int = Char | | mi_fam_insts stores type family instances, in that case F Int = | Char. What I would like to load is type family declaration: F a. If | that does not exist already I wonder whether information about type | family declarations should be cached in ModDetails in the same way | md_fam_insts caches information about instances? | | Rationale: I want to load information about tyfam declarations in | FamInst.checkFamInstConsistency and pass these definitions of type | families to FamInst.checkForConflicts. My plan is to verify whether an | open type family is injective at the same time when looking for | conflicts. | | Janek | | Dnia czwartek, 23 października 2014, napisałeś: | I don't know what you mean. Can you be more explicit. The | mi_fam_insts field of a ModIface sounds like what you want | | | -Original Message- | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | | Jan Stolarek | | Sent: 23 October 2014 08:50 | | To: ghc-devs@haskell.org | | Subject: Reading type families from interface files | | | | Devs, | | | | Is there a plumbing for returning declarations (not instances) of | | type families from an interface file? | | | | Janek | | ___ | | ghc-devs mailing list | | ghc-devs@haskell.org | | http://www.haskell.org/mailman/listinfo/ghc-devs | ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Reading type families from interface files
If you are talking about a ModDetails, then look in the range of md_types; the TyThings there include all the data types, classes, and type families declared in this module Ah, typeEnvTyCons looks like the thing I was looking for. Thanks. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cabal sdist trouble with GHC from head
2014-10-22 15:16 GMT+02:00 Sven Panne svenpa...@gmail.com: Does anybody have a clue what's going wrong at the sdist step here? https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707011#L104 This only happens with a GHC from head, a build with GHC 7.8.3 is fine: https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707010 Any help highly appreciated... I would really need some help here, even adding a few more diagnostic things to the Travis CI configuration didn't give me a clue what's going wrong: https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38813449#L110 I totally fail to understand why Cabal's sdist step works with every released compiler, but not with a GHC from head. I don't even know if this is a Cabal issue or a GHC issue. The relevant part from the Travis CI log is: ... cabal-1.18 sdist --verbose=3 creating dist/src creating dist/src/sdist.-3586/OpenGLRaw-1.5.0.0 Using internal setup method with build-type Simple and args: [sdist,--verbose=3,--builddir=dist,--output-directory=dist/src/sdist.-3586/OpenGLRaw-1.5.0.0] cabal-1.18: dist/setup-config: invalid argument The command cabal-1.18 sdist --verbose=3 exited with 1. ... As can be seen from the log, dist/setup-config is there and can be accessed. Confused, S. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cabal sdist trouble with GHC from head
cabal has changed for HEAD, you need to install 1.21.1.0 On Thu, Oct 23, 2014 at 2:40 PM, Sven Panne svenpa...@gmail.com wrote: 2014-10-22 15:16 GMT+02:00 Sven Panne svenpa...@gmail.com: Does anybody have a clue what's going wrong at the sdist step here? https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707011#L104 This only happens with a GHC from head, a build with GHC 7.8.3 is fine: https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707010 Any help highly appreciated... I would really need some help here, even adding a few more diagnostic things to the Travis CI configuration didn't give me a clue what's going wrong: https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38813449#L110 I totally fail to understand why Cabal's sdist step works with every released compiler, but not with a GHC from head. I don't even know if this is a Cabal issue or a GHC issue. The relevant part from the Travis CI log is: ... cabal-1.18 sdist --verbose=3 creating dist/src creating dist/src/sdist.-3586/OpenGLRaw-1.5.0.0 Using internal setup method with build-type Simple and args: [sdist,--verbose=3,--builddir=dist,--output-directory=dist/src/sdist.-3586/OpenGLRaw-1.5.0.0] cabal-1.18: dist/setup-config: invalid argument The command cabal-1.18 sdist --verbose=3 exited with 1. ... As can be seen from the log, dist/setup-config is there and can be accessed. Confused, S. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cabal sdist trouble with GHC from head
2014-10-23 15:01 GMT+02:00 Alan Kim Zimmerman alan.z...@gmail.com: cabal has changed for HEAD, you need to install 1.21.1.0 Hmmm, so we *force* people to update? o_O Perhaps I've missed an announcement, and I really have a hard time deducing this from the output on Travis CI. Is 1.21.1.0 backwards-compatible to previous GHCs? Or do I have to set up something more or less complicated depending on the GHC version (which would be unfortunate)? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
Sorry I'm a bit late to the party, I'm a bit snowed under with some GHCJS refactoring work and the things I really need to do before the 7.10 merge window closes. I think that exposing GHC's front end functionality through the library would be a good idea. Unfortunately it adds the haskeline dependency, so adding it to the `ghc` package wouldn't be ideal. On the other hand, if we exposed the GHC/GHCi modules as a library in a `ghc-bin` package, then we'd avoid this, and also address ghc-mod's problem of the terminfo dependency. Unfortunately this part of GHC has never been written with use as a library in mind, so users would likely run into limitations at some point. For example, GHCJS has a complete copy - with some modifications - of the `ghc/Main.hs` module containing the command line parser and session setup code. Even if this module was exposed through the library, I wouldn't be able to use much of it, because of slight differences in command line options. My approach/plan so far has been to first copy code from GHC to the GHCJS tree to make it work, and then make changes in the next major GHC version that'd let me remove most of the lower level (and most likely to be version specific) code from my copy. It would probably take a few iterations to satisfy all the needs of ghc-mod/ghc-server/GHCJS and others, but the result, a library, would be more flexible than a JSON API for GHCi (which would still be useful by itself). If stability/segfaults are a major factor in choosing to communicate with the GHCi program, rather than using GHC as a library, then this really should be addressed directly. Has anyone done investigation of the situations that make ghc-mod/ghc-server, but not GHCi, crash? On Mon, Oct 20, 2014 at 3:07 PM, Simon Peyton Jones simo...@microsoft.com wrote: Christopher You are doing very cool things. Thank you. What I’m puzzled about is this: the GHC API **is** a programmatic interface to GHC. Why not just use it? I can think of some reasons: · It’s not very clear just what’s in the GHC API and what isn’t, since you have access to all of GHC’s internals if you use –package ghc. And the API isn’t very well designed. (Answer: could you help make it better?) · You want some functionality that is currently in GHCi, rather than in the ‘ghc’ package. (Answer: maybe we should move that functionality into the ‘ghc’ package and make it part of the GHC API?) · You have to be writing in Haskell to use the GHC API, whereas you want a separate process you connect to via a socket. (Answer: Excellent: write a server wrapper around the GHC API that offers a JSON interface, or whatever the right vocabulary is. Sounds as if you have more or less done this.) · Moreover, the API changes pretty regularly, and you want multi-compiler support. (No answer: I don’t know how to simultaneously give access to new stuff without risking breaking old stuff.) My meta-point is this: GHC is wide open to people like you building a consensus about how GHC’s basic functionality should be wrapped up and exposed to clients. (Luite is another person who has led in this space, via GHCJS.) So please do go ahead and lay out the way it **should** be done, think about migration paths, build a consensus etc. Much better that than do fragile screen-scraping on GHCi’s textual output. Thanks for what you are doing here. Simon *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Christopher Done *Sent:* 18 October 2014 16:49 *To:* ghc-devs@haskell.org *Subject:* Making GHCi awesomer? Good evening, So I’ve been working on Haskell user-facing tooling in general for some years. By that I mean the level of Emacs talking with Haskell tools. I wrote the interactive-haskell-mode (most functionality exists in this file https://github.com/haskell/haskell-mode/blob/master/haskell-process.el#L1 ). which launches a GHCi process in a pipe and tries very earnestly to handle input/output with the process reasonably. For Emacs fanciers: Written in Elisp, there’s a nice command queue that you put commands onto, they will all be run on a FIFO one-by-one order, and eventually you’ll get a result back. Initially it was just me using it, but with the help of Herbert Riedel it’s now a mode on equal footing with the venerable inferior-haskell-mode all ye Emacs users know and love. It’s part of haskell-mode and can be enabled by enabling the interactive-haskell-mode minor mode. For years I’ve been using GHCi as a base and it’s been very reliable for almost every project I’ve done (the only exceptions are things like SDL and OpenGL, which are well known to be difficult to load in GHCi, at least on Linux). I think we’ve built up a good set of functionality https://github.com/haskell/haskell-mode/wiki/Haskell-Interactive-Mode purely based on asking GHCi things and getting it to do things. I literally use GHCi
