- ghc-devs - Haskell.org

Status of deprecation/warning features (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)
by Herbert Valerio Riedel 28 Sep '15

28 Sep '15

On 2015-09-28 at 04:56:13 +0200, David Feuer wrote: [...] > That's an excellent idea, and I think it makes sense to offer it at the > module level as well as the class level. Just change DEPRECATED to REMOVED > when it's actually removed. Speaking of such, has the deprecated export > proposal made any headway? As far as the in-flight library proposals are concerned, I plan to rather have hardwired specific warnings implemented in the style of the AMP warnings as it's crucial to have them available for the GHC 8.0 release to have the foundations for the migration plans in place. We can generalize those feature later-on (maybe even in time for GHC 8.0 if we're lucky). ---- As for the more general facilities the short answer is: They're stalled! Volunteers wanted! There's the specification over at - https://ghc.haskell.org/trac/ghc/wiki/Design/MethodDeprecations and there are 3 somewhat connected/related warning-feature tickets which ought to be co-designed to avoid obstructing each other (if there's any risk there). - https://ghc.haskell.org/trac/ghc/ticket/10071 - https://ghc.haskell.org/trac/ghc/ticket/2119 - https://ghc.haskell.org/trac/ghc/ticket/4879 For #10071 there's a very modest start at implementing this, which just modifies the parser but doesn't go much farther (see wip/T10071 branch) There's an old patch for #4879 which still works over at - https://phabricator.haskell.org/D638 Cheers, hvr

1 0

RE: How to get types including constraints out of TypecheckedModule
by Simon Peyton Jones 25 Sep '15

25 Sep '15

| What if I have a binder: | | (foo, bar) = (show, show) | | I can now get the polymorphic types of foo and bar respectively but | how do I'm not sure how I'm meant to zip up the monomorphic type of | `pat_rhs_ty`, i.e. the type of the whole rhs, with the polymorphic | types in `abs_exports`. | | I mean I could just match up the type variables and pull the | constraints in by hand but it just seems like there already ought to | be a way to do this somewhere? I'm sorry I don't understand the question. For the above pattern binding you'll get something like AbsBinds { abe_tvs = [a,b] abe_ev_vars = [ d1 :: Show a, d2 :: Show b ] abe_exports = [ ABE { abe_poly = foo :: forall a. Show a => a->String , abe_mono = foo_m :: a->String , abe_wrap = ... } ABE { abe_poly :: bar :: forall b. Show b => b->String abe_mono = bar_m :: b->String ... } ] abe_binds = { (foo_m, bar_m) = (show a d1, show b d2) } } Simon | | Alternatively my strategy to do this would be to build a map from | TyVar to the constraint and then going over the monomorphic types and | for each TyVar that's mentioned in the monomorphic type pull in the | relevant constraint and apply those to the monomorphic type. Does that | sound sensible at all? I have no idea how equality constraints and all | that fancy stuff are encoded so I hope that doesn't need any special | handling ;) | | > I hope this is of some help. If so, would you like to update the | > Commentary (on the GHC wiki) to add the information you wish had | been | > there in the first place? Thanks! | | Very much so, thanks :) | | I'd love to put this in the commentary somewhere but looking at | https://ghc.haskell.org/trac/ghc/wiki/Commentary I can't actually find | anywhere this would fit in and it just seems like an awefully specific | thing to put there. Maybe it would be better to improve the comments | instead for the next person that goes looking thoguth the source | trying to figure out where the types end up. | | For example the comment on AbsBinds could mention that this is where | the typechecker stores inferred constrainst or something like that. | | --Daniel

1 0

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