- Glasgow-haskell-users

Closed Type Families: separate instance groups?
by AntC 04 Jun '15

04 Jun '15

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

3 4

HEADS UP: Final call for 7.10.2 is soon
by Austin Seipp 03 Jun '15

03 Jun '15

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 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 4

GHC Weekly News - 2015/06/03
by Austin Seipp 03 Jun '15

03 Jun '15

(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/

1 0

Ambiguity check and type families
by Wolfgang Jeltsch 02 Jun '15

02 Jun '15

Hi, the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1: > {-# LANGUAGE TypeFamilies #-} > > type family F a :: * > > type family G b :: * > > x :: G (F a) ~ a => F a > x = undefined GHC 7.10.1 reports: > Could not deduce (F a0 ~ F a) > from the context (G (F a) ~ a) > bound by the type signature for x :: (G (F a) ~ a) => F a > at Test.hs:7:6-23 > NB: ‘F’ is a type function, and may not be injective > The type variable ‘a0’ is ambiguous > In the ambiguity check for the type signature for ‘x’: > x :: forall a. (G (F a) ~ a) => F a > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > In the type signature for ‘x’: x :: G (F a) ~ a => F a At a first look, this complaint seems reasonable, and I have already wondered why GHC 7.8.3 actually accepts the above code. >From an intuitive standpoint, however, the code seems actually acceptable to me. While it is true that type families are generally not injective, it is possible to derive the type a from F a by applying G. It would great if this code would be accepted by GHC again and if there was a workaround to make it work with GHC 7.10.1. At the moment, this change in the type checker from 7.8.3 to 7.10.1 breaks the incremental-computing package in a rather fundamental way. All the best, Wolfgang

3 3

Arithmetic overflow in rem and mod
by Nikita Karetnikov 02 Jun '15

02 Jun '15

According to the documentation, rem and mod must satisfy the following laws: -- > (x `quot` y)*y + (x `rem` y) == x rem -- > (x `div` y)*y + (x `mod` y) == x mod https://hackage.haskell.org/package/base-4.8.0.0/docs/src/GHC-Real.html Note, however, that there is a case when quot and div result in an arithmetic overflow: Prelude> (minBound :: Int) `quot` (-1) *** Exception: arithmetic overflow Prelude> (minBound :: Int) `div` (-1) *** Exception: arithmetic overflow while rem and mod don't: Prelude> (minBound :: Int) `rem` (-1) 0 Prelude> (minBound :: Int) `mod` (-1) 0 Is this a mistake? For the record, I'm aware of the safeint package, which raises the error for rem and mod, and this ticket: https://ghc.haskell.org/trac/ghc/ticket/8695

4 3

ANN: Bayhac 2015 June 12, 13, 14 in Mountain View, CAANN:
by Byron Hale 02 Jun '15

02 Jun '15

Bayhac 2015 will be held June 12, 13, 14 at Hackers Dojo in Mountain View, CA. See http://bayhac.org/ to register. Light rail service is available from Caltrain to near Hackers Dojo. In addition, there can be shuttle service from Caltrain first thing in the morning and in the evening. Some known speakers are: Conal Elliott, Phil Freeman, Greg Weber, and Dan Burton You! If you would like to give a talk, send an email to bayhac2015-admin(a)googlegroups.com with the title and a brief explanation of what the talk will be on. It can be on anything Haskell related! We are also looking out for people who might be interested in conducting a more hands-on workshop. Twitter: https://twitter.com/bayhac2015 Byron Hale byron.hale(a)einfo.com @Hale_ByronL

1 0

Consecutive FFI calls
by David Turner 29 May '15

29 May '15

(cross-posted from ghc-dev and the cafe, with apologies to cross-subscribers) Hi, If I make a sequence of FFI calls (on a single Haskell thread) but which end up being called from different OS threads, is there any kind of ordering guarantee given? More specifically, is there a full memory barrier at the point where a Haskell thread migrates to a new OS thread? Many thanks, David

1 0

SRC_HC_OPTS in perf build
by Jeremy 27 May '15

27 May '15

build.mk.sample contains the lines: # perf matches the default settings, repeated here for comparison: SRC_HC_OPTS = -O -H64m However, in config.mk.in this is: SRC_HC_OPTS += -H32m -O What actually is the default for SRC_HC_OPTS? Why does config.mk.in seem to set it to -H32m, then every profile in build.mk.sample sets -H64m? -- View this message in context: http://haskell.1045720.n5.nabble.com/SRC-HC-OPTS-in-perf-build-tp5809863.ht… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 2

error in 7.10.1 ?
by Sergei Meshveliani 23 May '15

23 May '15

Dear GHC developers, The confirmation token letter from the bug tracker travels too long, I do not know, why. Meanwhile I cannot report there. So, I report it in the below way: http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may22-2… Make it, please, with ghc-7.10.1 as it is written there in install.txt, including making demotest/Main. Then ./Main breaks in the middle reporting a DoCon application error ---------------------------------------------------------------------------- Factorization in K1[x], K1 a generic finite extension of a prime field K = Z/(p) .. factor f, f = (x^10 + x^7 + x^5 + x^3 + x^2 + (2)*x+ (2)) <- K[x] = ((Z/<5>)["t"]/<(t^3 + 4*t + 3)>)["x"] Domain term of K must contain a Finite field description. --------------------------------------------------------------------------- I obtain this for ghc-7.10.1 made from source by ghc-7.8.2 on Debian Linux, x-86, 64 bit. The story is as follows. docon-2.12 http://www.botik.ru/pub/local/Mechveliani/docon/2.12/ has been tested under ghc-7.8.2, and it works. Now I am trying to port it to ghc-7.10.1. This needs inserting certain pragmas for OVERLAPPING/OVERLAPPABLE into some instance declarations. So I call this port docon-2.12.1. 7.10.1-errReport-may22-2015.zip is the error report of docon-2.12.1 to ghc-7.10.1. This application has the OVERLAPPABLE pragma set to one instance and the OVERLAPPING pragma set to many instances. GHC itself warns of overlaps. Then I 1) set the pragma to the reported instance (pair), 2) recompile the corresponding module 3) rerun make configure; make build. This process has finished in `making' the application. Then, > cd demotest > ghc $doconCpOpt -O --make -rtsopts Main > ./Main produces the above error instead of the test success report. I suspect that the reason is in treating the instance overlaps (but there may be another source). Comparing docon-2.12 + ghc-7.8.2 to 7.10.1-errReport-may22-201 + ghc-7.10.1, can you, please, find: how to fix the latter version? Is this a bug in ghc-7.10.1 ? Regards, -------- Sergei

1 1

-Wall and the fail method
by Nikita Karetnikov 23 May '15

23 May '15

Can -Wall be extended to report pattern match failures in do expressions, like it does for case expressions? Prelude> :set -Wall Prelude> let f = do Just x <- return Nothing; return x Prelude> let g = case Nothing of Just x -> x <interactive>:9:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: Nothing One can argue that it's similar to undefined, error, and various unsafeSomething functions, which I think should be reported as well, if possible. But these things can be found already with a simple grep while a pattern match cannot. I bet it has been discussed already, but "fail" is a terrible search term, so I cannot find anything relevant in the archives nor in the bug tracker.

2 1