Re: Closed Type Families: separate instance groups?
On Jun 3, 2015, at 7:09 PM, AntC anthony_clay...@clear.net.nz wrote: Is this separate instance group idea still a gleam in someone's eye? If not, is there some deep theoretical reason against? Not to my knowledge (to both questions). But I don't believe we've lost any expressiveness over the earlier version. You can always define a helper closed type family and have an open type family instance just call a closed type family. Of course, it would be nice to have *local* type families (as if, say, there were a `where` clause allowed), but this should work for you. Or does this not work in your use case? Having closed type families, as opposed to branched instances, just seemed like a cleaner way to package the new functionality. There really wasn't much to it other than aesthetics, if I recall the conversations correctly. Richard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Closed Type Families: separate instance groups?
Richard Eisenberg eir at cis.upenn.edu writes: You can always define a helper closed type family and have an open type family instance just call a closed type family. Thank you Richard, you mean like: type family OpenF a ... type instance OpenF (Foo b c) = FFoo (Foo b c) type family FFoo a where FFoo (Foo Int c) = ... ... OK. (Seems rather verbose.) Having closed type families, as opposed to branched instances, just seemed like a cleaner way to package the new functionality. There really wasn't much to it other than aesthetics, if I recall the conversations correctly. I recall the conversation quite well. (In fact I think it was me who suggested type family ... where ... ) I think it was less to do with aesthetics, and more to do with reducing verbosity in a common use case. It somehow doesn't seem as clean as old-fashioned overlapping instances. (I agree it does seem cleaner than overlaps with FunDeps.) It also BTW cuts us off from using Closed Families as Associated types separated into their Class instances. I think there's two use cases going on: - one where we want to see all the instances together that fits well to type family ... where ... - t'other where we want everything to do with a type constructor together that fits better with the separate instances AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Closed Type Families: separate instance groups?
Currently (GHC 7.8.3) the only form for Closed Type Families is: type family F a where ... -- list your instances here (This was considered a common use case -- for example in HList to put the type-matching instance with the non-matching, and that would be total coverage; rather than needing a type family decl and an instance decl with the instance head same as family. That was an optimisation over ...) Way back the design was more like this: type family F a type instance F (Foo b c) where F (Foo Int c) = ... F (Foo b Char) = ... type instance F (Bar e f g) where F (Bar Int f g) = ... The idea was that the separate instance groups must have non-overlapping heads. This is handy if Foo, Bar, etc are declared in separate places/modules. You can put the instances with the data decl. And quite possibly the family decl is in an imported/library module you don't want to touch. Is this separate instance group idea still a gleam in someone's eye? If not, is there some deep theoretical reason against? AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
GHC Weekly News - 2015/06/03
(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150603) Hi *, It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there. The main point of discussion was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts! == 7.10.2 status == 7.10.2 is swimming along very nicely - the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page] shows the current set of tickets we've fixed and plan on fixing. Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate. == List chatter == - Austin Seipp announced that GHC 7.10.2 will be release soon, and developers/users should get bugs they want fixed reported to us ASAP so we can do something. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html - Mark Lentczner announced a Haskell Platform alpha featuring GHC 7.10.2 https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Facundo Dominguez asks: sometimes we want to create a `static` pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html - David Macek has made great progress on getting native MSYS2 packages for windows working - which should be a great boon to all our Windows users! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html - Joachim Breitner announced the new GHC performance dashboard, which can be used to track all of GHC's performance-based tests over time. Whoohoo! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html - Joachim Breitner asked: is there a way to programmatically 'Raise a Concern' on a Phabricator commit? With the new https://perf.haskell.org/ghc/ work, it'd be nice if regressions could be automatically flagged. The current problem is there is no API endpoint, but one can be built. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html - Adam Gundry asked ghc-devs about some input on changes to the new typechecker plugins API. After some discussion and elbow grease, the new changes have already landed in HEAD and will be in 7.12.1. https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html == Noteworthy commits == - Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space leak in the mighty simplifier - Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic behavior in `tidyOccName` - Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow `:back` and `:forward` to take counts - Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up `nativeCodeGen/seqBlocks` - Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up `elimCommonBlocks` by grouping blocks also by outgoing labels - Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird behavior of `-ignore-dot-ghci` and `-ghci-script` - Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of overlapping instances in Safe Haskell - Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382 - Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for `:set -s` == Closed tickets == #10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474, -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: -prof, -threaded, and -N
From https://github.com/ghc/ghc/blob/master/rts/RtsFlags.c#L1238 it seems that
the behavior described in my email below is intended:
```
if (rts_argv[arg][2] == '\0') {
#if defined(PROFILING)
RtsFlags.ParFlags.nNodes = 1;
#else
RtsFlags.ParFlags.nNodes = getNumberOfProcessors();
#endif
```
So, my question is: what is the reason for this difference between the
profiling and the non-profiling case?
Lars
On Jun 2, 2015, at 10:20 PM, Lars Kuhtz hask...@kuhtz.eu wrote:
Hi,
The behavior of the -N flag (without argument) with the profiling runtime
seems inconsistent compared to the behavior without profiling. The following
program
```
module Main where
import GHC.Conc
main :: IO ()
main = print numCapabilities
```
when compiled with `ghc -threaded -fforce-recomp Prof.hs` and run as `./Prof
+RTS -N` prints `2` on my machine. When the same program is compiled with
`ghc -threaded -fforce-recomp -prof Prof.hs` and executed as `./Prof +RTS -N`
it prints `1`.
When an argument is provided to `-N` (e.g. `./Prof +RTS -N2`) the profiling
and non-profiling versions behave the same.
I tested this with GHC-7.10.1 but I think that I already observed the same
behavior with GHC-7.8.
Is this inconsistency intended?
Lars
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: ghc 7.10.1 hard lock on exit with shake, OS X 10.10
Perhaps #10317 is related? https://ghc.haskell.org/trac/ghc/ticket/10317 You might try building with the latest ghc-7.10 branch. On Wed, Jun 3, 2015 at 12:27 AM, Evan Laforge qdun...@gmail.com wrote: On Tue, Jun 2, 2015 at 7:20 PM, Carter Schonwald carter.schonw...@gmail.com wrote: could you share a minimal program that reproduces the problem? That's the thing, it's a thousand line shakefile that builds a 100k line program, and it's happening only rarely now. Since it happens so rarely it seems really difficult to prune away bits to see if it still happens. I suppose since the building is all just running commands, the source it's building doesn't matter, but since it's a build, it runs a different sequence of commands every time. I suppose I could stub out the program by replacing ghc with a shell script that sleeps and touches the output files, but it feels like I could spend days on it because there are tons of little details. I'm pretty sure it's related to the threaded runtime, because it doesn't happen without -threaded. I could try with -debug, but that probably turns off -threaded too, so no more problem. Shake is heavily threaded and nondeterministic. I haven't seen other shake users report it though. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: HEADS UP: Final call for 7.10.2 is soon
Please, consider my recent bug report overlapping instances in 7.10.1 (see my resent email to this list). -- Sergei On Tue, 2015-06-02 at 16:31 -0500, Austin Seipp wrote: Hi *, I've just finished merging all the latest patches for GHC 7.10.2 into the STABLE branch. All in all, we've fixed a lot of bugs (over 80 tickets closed)! So, we'll probably be doing a 7.10.2 release here in a few weeks. The tentative plan was around the 14th, although it's not set in stone. (At worst, it would be pushed from the 14th to the 21st). With that in mind, if I could quickly direct your attention to the GHC bug tracker and the status page[1] - it would be really helpful if you check if the things you want are fixed! Specifically, if you want something fixed for the 7.10.2 release: - Make sure there is a ticket. It really needs to exist or we'll just forget! - If your bug is critical, please explain why! We really want to kill showstoppers ASAP, because bugs are much cheaper to fix early. If that's the case we can bump the priority if it's necessary to make things clear. - Set the milestone to 7.10.2. It'll automatically appear on the status page. That should be it - we'll be monitoring the status page regularly to keep track of new things. The current bug list is pretty small - we may move some of them out, or fix several more. So just try to let us know. As a sidenote, I'm quite happy with this release - it's fixed dozens of tricky bugs, improved some nasty corner cases in compiler performance, and overall seems like it will be high quality. Thanks to everyone who submitted patches! I'll send out another email next week as another reminder. [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: HEADS UP: Final call for 7.10.2 is soon
There have been some requests for a Cabal library release for 7.10.2. I remember something about truncate directories/symbol names being an issue. I'm CC:ing the Cabal mailing list for comments. On Wed, Jun 3, 2015 at 3:40 PM, Sergei Meshveliani mech...@botik.ru wrote: Please, consider my recent bug report overlapping instances in 7.10.1 (see my resent email to this list). -- Sergei On Tue, 2015-06-02 at 16:31 -0500, Austin Seipp wrote: Hi *, I've just finished merging all the latest patches for GHC 7.10.2 into the STABLE branch. All in all, we've fixed a lot of bugs (over 80 tickets closed)! So, we'll probably be doing a 7.10.2 release here in a few weeks. The tentative plan was around the 14th, although it's not set in stone. (At worst, it would be pushed from the 14th to the 21st). With that in mind, if I could quickly direct your attention to the GHC bug tracker and the status page[1] - it would be really helpful if you check if the things you want are fixed! Specifically, if you want something fixed for the 7.10.2 release: - Make sure there is a ticket. It really needs to exist or we'll just forget! - If your bug is critical, please explain why! We really want to kill showstoppers ASAP, because bugs are much cheaper to fix early. If that's the case we can bump the priority if it's necessary to make things clear. - Set the milestone to 7.10.2. It'll automatically appear on the status page. That should be it - we'll be monitoring the status page regularly to keep track of new things. The current bug list is pretty small - we may move some of them out, or fix several more. So just try to let us know. As a sidenote, I'm quite happy with this release - it's fixed dozens of tricky bugs, improved some nasty corner cases in compiler performance, and overall seems like it will be high quality. Thanks to everyone who submitted patches! I'll send out another email next week as another reminder. [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
