September 2014 - ghc-devs

Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe
by Moritz Angermann 15 Sep '14

15 Sep '14

Hi, when trying to compile a ghc HEAD on LLVM ARM, I end up getting an exception: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for arm-apple-ios): globalRegMaybe After some digging I found that a new call to globalRegMaybe was introduced here: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 on 2014-04-29 in commit: http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf33534… In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was changed: http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a… introducing a set of new ifdef/elif/endif pairs. Especially for MACHREGS_NO_REGS, namely: -#endif globalRegMaybe _ = Nothing +#elif MACHREGS_NO_REGS +globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic "globalRegMaybe not defined for this platform" +#endif ARM.hs (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d506857674169e…) however, has: #define MACHREGS_NO_REGS 0 #define MACHREGS_arm 1 where MACHREGS_arm 1 has no effect on the subsequently imported CodeGen.Platform.hs. Therefore I propose that a change to ARM.hs is made to set MACHREGS_NO_REGS to 1. Cheers, Moritz

3 6

Preliminary proposal: Monoidal categories in base and proc notation support
by Sophie Taylor 15 Sep '14

15 Sep '14

>Hi Sophie, >In your proposal draft, I am missing the rationale part. Yeah, I'm still writing it - I definitely need to expand that a bit mor. >Do we need *all* of these classes in base in order to desugar proc? Can you demonstrate why they are needed? Or will something simpler suffice? I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward.

3 4

Re: Preliminary proposal: Monoidal categories in base and proc notation support
by Edward Kmett 15 Sep '14

15 Sep '14

The current categories package tries to let you reuse bifunctors of the form c * d -> e across base categories, so that e.g. Kleisli m can use (,) for its product, etc. (in general it isn't a real product for Kleisli m, but let's pretend) this means we have to adopt a 3 for 2 policy wrt the categories involved. c e -> d, c d -> e, d e -> c, but when inferring from first or second you usually only know one, but also only need one other, but can't know the third from context, since no arrow is supplied. It is underdetermined. Hask avoids this by presupposing a single set of categories for every Bifunctor, but it is a conceit of the package that this is enough in practice, not something I know, and we pay a measurable price for this. A lot of stuff is more complex there! The current hask design, as opposed to the one I gave a talk on and the design of categories loses a lot of what powers lens and the like in exchange for this simpler story. I don't make that change lightly and I'd hesitate to make that change across the entire ecosystem. It hasn't proved it is worth the burden yet. In exchange for this complexity it is able to find simplicity elsewhere, e.g. Bifunctor in hask is a derived concept from a Functor to a Functor category, which models the curried nature of the arguments to a Bifunctor. My main point is there are a lot of points in the design space, and I don't think we're equipped to find a clear winner right now. Sent from my iPad > On Sep 15, 2014, at 3:53 PM, Sophie Taylor <sophie(a)traumapony.org> wrote: > > Oh darn, really? That is so disappointing. Why can't it maintain inference? :\ > >> On 15 September 2014 23:44, Edward Kmett <ekmett(a)gmail.com> wrote: >> I find PFunctor/QFunctor finer grained than is tasteful. Alas, they are necessary for inference for first/second in practice unless you require the Bifunctor to determine the category of both of its arguments. The hask package is exploring other ways to maintain inference. >> >> If you try to actually use the current categories package without them, well, nothing infers. >> >> Sent from my iPad >> >>> On Sep 15, 2014, at 11:32 AM, Sophie Taylor <sophie(a)traumapony.org> wrote: >>> >>> >Hi Sophie, >>> >>> >In your proposal draft, I am missing the rationale part. >>> Yeah, I'm still writing it - I definitely need to expand that a bit mor. >>> >Do we need *all* of these classes in base in order to desugar proc? Can >>> you demonstrate why they are needed? Or will something simpler suffice? >>> >>> I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. >>> With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0

GHC Weekly News (was: Status updates)
by Austin Seipp 15 Sep '14

15 Sep '14

Hi *, Note the title change. After some discussion with Simon last week, we decided to change up the name a bit, since we want the discussion on - As Gabor mentioned on the list earlier, I accidentally broke the Windows build. I'm sorry. :( We really need to get Phab building Windows too ASAP... I'm working on a fix this morning. (There are still a lot of upstream changes waiting to go into the Phabricator code base.) - I sent out the HCAR draft this morning. Please edit it! I think we have a few weeks of lead time however, so we're not in a rush like last time. But I will remind you. :) - The server migration for ghc.haskell.org seems to have gone pretty smoothly in the past week. It's had plenty of traffic so far. The full migration is still ongoing and I want to complete it this week. - I've finished reorganizing some of the Git and Repository pages after some discussion. We now have the Repositories[1] page, linked to on the left side, which details some notes on the repositories we use, and links to other various pages. I'm thinking of replacing this side-bar "root" with a link to the main Git[2] page, perhaps. - Miscellaneous: ghc.haskell.org and phabricator.haskell.org now sets the "Strict-Transport-Security" header. This just means you always use SSL now when you visit those pages (so you can't be connection-hijacked via a 503 redirect). - I'm merging some patches at the moment, although the windows fix is currently what I'll push first: D205, D204, D203, D199, D194, D179, D174. Do let me know if there's anything you want me to look at. - GHC works on Wine apparently for all you Linux users - thanks Mikolaj![3] - Jan had some questions about infrastructure which I just followed up on this morning. In particular: does anyone feel strongly about his first question?[4] - Herbert committed the first part of the Traversable/Foldable changes, by moving the typeclasses to Prelude. This is part of an ongoing series of patches. Things like adding Bifunctor will finally come after this.[5] Also, added bonus: we'll start including some of the tickets we closed this week. Closed tickets for the past week include: #9585, #9545, #9581, #6086, #9558, and #3658. Please let me know if you have any questions. [1] https://ghc.haskell.org/trac/ghc/wiki/Repositories [2] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git [3] https://www.haskell.org/pipermail/ghc-devs/2014-September/006283.html [4] https://www.haskell.org/pipermail/ghc-devs/2014-September/006275.html [5] https://phabricator.haskell.org/D209 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

The build is broken on {32,64}-bit Windows
by Páli Gábor János 15 Sep '14

15 Sep '14

Hello there, For your information, the build has been failing for a few days now on both my Windows builders [1][2], basically in the same way. [...] librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Could somebody do something with this, or does anybody have hints on how to fix this? Looks like the culprit is the haskeline library. [1] http://haskell.inf.elte.hu/builders/windows-x86-head/34/10.html [2] http://haskell.inf.elte.hu/builders/windows-x86_64-head/29/10.html

2 1

It's that time again (for the HCAR)
by Austin Seipp 15 Sep '14

15 Sep '14

Hi *, It is that time again where once every 6 months, we write our entry for the Haskell Communities and Activities Report (HCAR), summarizing what exactly we're all doing. I say 'we' write this of course because I need everyone to write some stuff on what they're doing. :) I'll editorialize it before sending it in, but please feel free to add things. I've drafted a very basic page, based on the last one: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 I sort of selectively cherry-picked some things from the prior 7.10 updates. Again, please feel free to add things as you see fit. I eagerly await your edits! Let's try to get this one done on time. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Preliminary proposal: Monoidal categories in base and proc notation support
by Sophie Taylor 15 Sep '14

15 Sep '14

Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any input/constructive criticism would be greatly appreciated; this is the first one of these I've written. Here is the proposal in its current form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Thanks, Sophie Taylor

3 2

Re: The list fusion lab
by David Feuer 14 Sep '14

14 Sep '14

Joachim Breitner wrote: > Together with John Wiegly at ICFP, I started to create a list > performance laboratory. You can find it at: > https://github.com/nomeata/list-fusion-lab Many thanks to you both! This sounds like an excellent idea. I do hope someone figures out a way around the criterion dependency shortly. Alternatively/longer term, I would love to see criterion refactored a bit—separating benchmarking and analysis into separate packages would presumably help with its dependency problems, and having the benchmarking side work with GHC HEAD reliably would be a Good Thing.

3 3

Re: FoldrW/buildW issues
by David Feuer 14 Sep '14

14 Sep '14

Joachim Breitner wrote: > Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: > > On Sep 12, 2014 2:35 PM, "Joachim Breitner" <mail(a)joachim-breitner.de> > > wrote: > > > Interesting. I assumed that some wrap.unwrap=id law would hold, or > > at > > > least some moral approximation (e.g. disregarding bottoms in an > > > acceptable manner). But if the wrappers have to do arbitrary stuff > > that > > > can arbitrarily interact with how the producer calls them, this > > becomes > > > a bit less appealing. > > > > No, nothing pleasant like that, I'm afraid. isoSimple is like that of > > course, but once it gets to foldl, the fusion rule is handing the > > builder a wrap/unwrap pair that isn't even close to that. > > and parametricity doesn't help here? Note that due to the forall in the > type of buildW, you can probably reason about what kind of values buildW > can produce, as it can only use whatever the consumer handed to it. > Maybe there is an invariant for that type, and the worker/wrapper pair > is the identity for values that fulfill that invariant. > That seems reasonable, and I suspect without any proof that Takano Akio's wrapper for foldl and Dan Doel's wrapper for reverse probably satisfy it. Scans seem to be more of a challenge. It appears to me that Dan's scanl wrapper probably does *not* satisfy that requirement, and I don't know enough to have much chance of finding one that does. David

3 3

Re: FoldrW/buildW issues
by David Feuer 13 Sep '14

13 Sep '14

On Sep 12, 2014 2:35 PM, "Joachim Breitner" <mail(a)joachim-breitner.de> wrote: > Interesting. I assumed that some wrap.unwrap=id law would hold, or at > least some moral approximation (e.g. disregarding bottoms in an > acceptable manner). But if the wrappers have to do arbitrary stuff that > can arbitrarily interact with how the producer calls them, this becomes > a bit less appealing. No, nothing pleasant like that, I'm afraid. isoSimple is like that of course, but once it gets to foldl, the fusion rule is handing the builder a wrap/unwrap pair that isn't even close to that. > > 2. Somewhat related to the above, this framework has a huge amount of > > "wiggle room". There is very little to guide the choice of Wrap type. > > I guess that would be resolved by time and experience, if we’d employ > that scheme. But maybe we don’t. The only way I would imagine would be if it turned out there were a few types that could be composed somehow. But when I, experimentally, applied Dan Doel's scanl wrapper type combined with Simple to (!!), I just got wrong answers. > > Do you have any ideas? > > Directly related to foldrW, no. > > About list fusion and foldl in general, some half-baked. > > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > function, semantically the identity, but tell the compiler not to share > the result of the computation. Using that in the definition of > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > more reliable. I need to investigate if that solves the sumConcatInits > problem. How does that work exactly? Where do you stick the oneShot/why is it valid? > Another idea, probably with the same effect: What happens if we extend > build :: (forall b. (a -> b -> b) -> b -> b) -> [a] > to > buildI :: (forall b. (a -> b -> b) -> b -> (b -> b) -> b) -> [a] > where the extra argument is the identity, but magically „improves values > of type b“. So with > > enum = buildI $ \c n imp -> go 0 > where go i = imp $ case i of 100 -> n ; _ -> i `c` go (i+1) > > and > > foldl f a0 = foldrI (\x k a -> k (f x a)) id (\k a -> k a) a0 > > we might get good code (but this is half-baked and written as I go). It sounds a lot like the foldrW/buildW thing again, but maybe you can do better with it. > Shouldn’t this be on ghc-dev where others can join an, and people will > find it in the archives later? I prefer to reserve private mail to, > well, private matters :-) If you like. David

2 1