September 2015 - ghc-devs

How to get types including constraints out of TypecheckedModule
by Daniel Gröber 25 Sep '15

25 Sep '15

Hi ghc-devs, I have a question and some code to ponder on for you all: In ghc-mod we have this very useful command to get the type of something in the middle of a module, i.e. not a toplevel binder. Essentially we just optain a TypecheckedModule and traverse the tm_typechecked_source and then extract the Types from that in various places. This all works nice and well but we have one problem, namely the contraints are missing from all types. Now I'm sure there's a good reason GHC doesn't keep those inline in the syntax tree but my question is how do I get them? I've created a testcase that demonstrates the problem: $ git clone https://gist.github.com/DanielG/1101b8273f945ba14184 $ cd 1101b8273f945ba14184 $ ghc -package ghc -package ghc-paths GhcTestcase.hs $ ./GhcTestcase Type: a Even though the type of the binder I'm looking at has the type `Num a => a`. --Daniel

2 2

RE: [GHC] #10487: DeriveGeneric breaks when the same data name is used in different modules
by Simon Peyton Jones 24 Sep '15

24 Sep '15

Can someone fill in the regression-test test-case on the ticket? I assume there is one?? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 24 September 2015 08:51 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10487: DeriveGeneric breaks when the same data name is | used in different modules | | #10487: DeriveGeneric breaks when the same data name is used in different | modules | -------------------------------------+------------------------------------ | - | Reporter: andreas.abel | Owner: osa1 | Type: bug | Status: closed | Priority: highest | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.1 | Resolution: fixed | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | Phab:D1081 | -------------------------------------+------------------------------------ | - | Changes (by ezyang): | | * status: new => closed | * resolution: => fixed | | | Comment: | | Pushed. I assume we aren't backporting to 7.10? | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haske | ll.org%2ftrac%2fghc%2fticket%2f10487%23comment%3a19&data=01%7c01%7csimonpj | %40064d.mgd.microsoft.com%7c82714a5e33ae4f38b09908d2c4b539d7%7c72f988bf86f | 141af91ab2d7cd011db47%7c1&sdata=CtjXUTaEpVHihCDcvgifJ%2fTSw30niJxDDFsFqE3m | ykY%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haske | ll.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82714a5e | 33ae4f38b09908d2c4b539d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=76x0 | GO1GY8YfHiI7vNNS7U%2b9XTkUVU72nnq76N4V87o%3d> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c82714a5e33ae4f38 | b09908d2c4b539d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Y08eOOpKx37o | TYsnGW2m1pvQGW31Ssq%2fwwBPAwt3nUo%3d

2 1

RE: [GHC] #10904: C finalizer may be called on re-used memory
by Simon Peyton Jones 24 Sep '15

24 Sep '15

Is there a test case for this? "Test Case" is not filled in Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 24 September 2015 10:00 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10904: C finalizer may be called on re-used memory | | #10904: C finalizer may be called on re-used memory | -------------------------------------+------------------------------------ | - | Reporter: bherzog | Owner: | Type: bug | Status: closed | Priority: normal | Milestone: 7.10.3 | Component: Runtime System | Version: 7.4.1 | Resolution: fixed | Keywords: | Operating System: Linux | Architecture: | | Unknown/Multiple | Type of failure: Runtime crash | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | Phab:D1275 | -------------------------------------+------------------------------------ | - | Changes (by bgamari): | | * status: merge => closed | * resolution: => fixed | | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haske | ll.org%2ftrac%2fghc%2fticket%2f10904%23comment%3a7&data=01%7c01%7csimonpj% | 40064d.mgd.microsoft.com%7c1ba2f315ae0543169de308d2c4bee103%7c72f988bf86f1 | 41af91ab2d7cd011db47%7c1&sdata=eeIRaPoS4sctt6SMhBYcVhaaYe9dMFeAjWNynBCIDDE | %3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haske | ll.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c1ba2f315 | ae0543169de308d2c4bee103%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3Pzl | NvTz8yyifPsu5iDD82D5mghc9BDBUB9%2b541CttM%3d> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c1ba2f315ae054316 | 9de308d2c4bee103%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7pPc9z4f3OrC | 3ZFCoItJBxNlDXH5w41tXqTTCGw06kQ%3d

1 0

Attempting to Create a semi-official Haskell layer for Open Embedded/Yocto
by drquigl 24 Sep '15

24 Sep '15

Hello Everyone, I had asked about cross compilers about 5 months back and other priorities have put that work on hold. However I am once again tasked with trying to get Haskell to build properly within an embedded environment we use. I found the additional pages on the Haskell build system and its architecture and everything it uses and read through all of them. I was wondering if anyone would be interested in helping me work through the problems I'm having with the build of Haskell in Open Embedded. I want to use the most up to date release of Haskell and if we need to push any changes to the build system to facilitate getting this working for everyone I'm happy to do so. I can set up a repository on github with all the appropriate sub modules to make it easy for someone to check out and start trying to build GHC. If anyone is interested in tackling this problem with me I'm happy to arrange a phone call or some other form of meeting to go over the specifics of OE and fill that person or persons in on what I hope to accomplish. If you are interested please let me know and we can try to work on getting better build support for Embedded toolchains. Dave

1 0

[RFC] Moving user's guide to ReStructuredText
by Ben Gamari 23 Sep '15

23 Sep '15

Hello all! Last year there was a brief thread [1] on this list discussing the choice of markup language used for GHC's users guide. At this point DocBook is showing signs of age, * The format's documentation is ancient and isn't terribly approachable. * Writing XML by hand is a terrible, terrible experience. For this reason a shocking fraction of the users' guide isn't even valid DocBook (although is still accepted by the tools) * The tooling surrounding the format is challenging to bring up on non-Linux platforms * Getting even a simple image displayed consistently in the PDF and HTML output is an exercise in futility [2] There are a few alternatives that we could switch to, * Markdown: While ubiquitous, its syntax isn't nearly expressive enough to accomodate the users guide. * asciidoc: This was the front-runner in [1]. Unfortunately, when I tried to use it in anger on the users guide things pretty quickly fell apart start to come apart. The syntax is sadly not very composable: tasks like nesting a code block inside a list becomes fragile and quite unreadable due to the need for continuation characters (as delimited blocks like code blocks must begin at column 0). Despite this I did manage to get much of the way through an asciidoc-ification of the users guide [2] but only through a great deal of manual fixing. While asciidoc does strive to map one-to-one onto DocBook, my experience is that the converse is not true; a conversion to asciidoc require that we drop some of the finer distinctions between code-like inline elements. For an example of the continuation character issue, see [3]. * ReStructuredText: this was a close second-place in the thread and has a fairly wide user base. The primary implementation, Sphinx, is used by Python, MathJAX, LLVM, Ubuntu, Ceph, Blender, and others. The syntax is fairly similar to Markdown and is at least as expressive as asciidoc. I have converted the entire users guide to ReStructuredText with a modified Pandoc. While some tweaking is still certainly necessary the output from the most-mechanical conversion looks quite good, * HTML (using a modified version of LLVM's theme), http://smart-cactus.org/~ben/ghc-user-manual/html/index.html * PDF produced by xetex (used to get convenient Unicode support), http://smart-cactus.org/~ben/ghc-user-manual/xetex/GHCUsersGuide.pdf * ePub (I know nothing about this format) http://smart-cactus.org/~ben/ghc-user-manual/epub/GHCUsersGuide.epub * Even Github's rendering of the source looks reasonable good, https://github.com/bgamari/ghc/blob/doc-rst/docs/users_guide/ghci.rst Of course, there are a few annoyances: the doctree construct doesn't quite work how one might expect, requiring one to split up files a bit more than one might like. Like asciidoc, there is no good way to express nested inlines, so we still lose some of the expressiveness of DocBook. Another nice advantage here is that Trac has native support [5] for rendering RST which could come in handy when pasting between documents. At this point we are leaning towards going with ReStructuredText: the tooling is much better the DocBook, the format reasonably easy to grok and expressive enough to accomodate the majority of the users guide unmodified. However, we would love to hear what others think. Are there any formats we have overlooked? Are there any objections to going ahead with this? If we want to move forward with ReStructuredText I think we will want to move quickly. While the conversion is mostly automated, there is some amount of manual fiddling necessary to get things formatted nicely. There are a few open Differentials that would need to be amended after the change but I would be happy to help authors through this if necessary. Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2014-October/006599.html [2] https://ghc.haskell.org/trac/ghc/ticket/10416 [3] https://github.com/bgamari/ghc/blob/asciidoc/docs/users_guide/ [4] https://github.com/bgamari/ghc/blame/asciidoc/docs/users_guide/ghci.asciido… [5] http://trac.edgewall.org/wiki/WikiRestructuredText

3 3

[RFC] Moving user's guide to ReStructuredText
by harold_carr＠hotmail.com 23 Sep '15

23 Sep '15

You might consider the Racket documentation ecosystem: http://pkg-build.racket-lang.org/doc/scribble/index.html or http://pkg-build.racket-lang.org/doc/pollen/

3 2

ANN: CfN for new Haskell Prime language committee
by Herbert Valerio Riedel 23 Sep '15

23 Sep '15

Dear Haskell Community, In short, it's time to assemble a new Haskell Prime language committee. Please refer to the CfN at https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html for more details. Cheers, hvr -- PGP fingerprint: 427C B69A AC9D 00F2 A43C AF1C BA3C BA3F FE22 B574

1 0

question about GHC API on GHC plugin
by Mike Izbicki 22 Sep '15

22 Sep '15

I'm trying to write a GHC plugin. The purpose of the plugin is to provide Haskell bindings to Herbie. Herbie (https://github.com/uwplse/herbie) is a program that takes a mathematical statement as input, and gives you a numerically stable formula to compute it as output. The plugin is supposed to automate this process for Haskell programs. I can convert the core expressions into a format for Herbie just fine. Where I'm having trouble is converting the output from Herbie back into core. Given a string that represents a numeric operator (e.g. "log" or "+"), I can get that converted into a Name that matches the Name of the version of that operator in scope at the location. But in order to create an Expr, I need to convert the Name into a Var. All the functions that I can find for this (e.g. mkGlobalVar) also require the type of the variable. But I can't find a way to figure out the Type given a Name. How can I do this?

4 20

Converting unboxed sum types in StgCmm
by Johan Tibell 22 Sep '15

22 Sep '15

Hi! The original idea for implementing the backend part of the unboxed sums proposal was to convert from the core representation to the actual data representation (i.e. a tag followed by some pointer and non-pointer fields) in the unarise stg-to-stg <https://github.com/ghc/ghc/blob/master/compiler/simplStg/UnariseStg.hs> pass. I have now realized that this won't work. The problem is that stg is too strongly typed. When we "desugar" sum types we need to convert functions receiving a value e.g. from f :: (# Bool | Char #) -> ... to f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ... Since stg is still typed with normal Haskell types (e.g. Bool, Char, etc), this is not possible, as we cannot represent an argument which has two different types. It seems to me that we will have to do the conversion in the stg-to-cmm <https://github.com/ghc/ghc/blob/master/compiler/codeGen/StgCmm.hs> pass, which is quite a bit more involved. For example, StgCmmEnv.idToReg function will have to change from idToReg :: DynFlags -> NonVoid Id -> LocalReg to idToReg :: DynFlags -> NonVoid Id -> [LocalReg] to accommodate the fact that we might need more than one register to store a binder. Any ideas for a better solution? -- Johan

5 12

Proposal: Associating pattern synonyms with types
by Matthew Pickering 19 Sep '15

19 Sep '15

Dear devs, There has been a bit of discussion on #10653 about extending exports to allow users to associate pattern synonyms with types (just like ordinary data constructors). There is a section on the wiki which describes the problem and the proposed behaviour. https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Associatingsynonymswi… Any comments would be appreciated before I start the implementation. Please read all the way to the bottom past the examples as their are a few sections of clarification which might answer your question. Matt

1 0