- ghc-devs - Haskell.org

RE: [Diffusion] [Build Failed] rGHC55b1b85df424: Accept tcrun045 output
by Simon Peyton Jones 21 Apr '16

21 Apr '16

Ben: now are down to T4029 with max-bytes increased. Maybe just increase it? it's a flaky number because it depends on timing of major gc Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 20 April 2016 21:49 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Diffusion] [Build Failed] rGHC55b1b85df424: Accept tcrun045 output | | Harbormaster failed to build B9261: rGHC55b1b85df424: Accept tcrun045 output! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC55b1b85df424 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite, Harbormaster

2 1

Re: Pattern synonym type flexibility
by David Feuer 20 Apr '16

20 Apr '16

I don't know what that means. There's no way to enforce duality at the term level. Enforcing it at the type level prevents me from doing what I want and serves no apparent purpose. Remember that pattern synonyms are all about providing nice syntax, not adding essential expressiveness. On Apr 20, 2016 1:41 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> wrote: Shouldn't the design simply be both directions are the dual of the other, and pure in some sense ? On Wednesday, April 20, 2016, David Feuer <david.feuer(a)gmail.com> wrote: > To some degree, it probably could be. But I believe that imposing any > substantial relationship between the smart constructor and the pattern > synonym is likely to fall squarely into the category of things that are > subtle, hard, and almost completely useless. In the arrangement I > suggested, people would be free to do some things that "don't make sense", > and that doesn't bother me in the least. > On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> > wrote: > >> Would that duality be related to the given vs wanted constraints ? >> >> On Wednesday, April 20, 2016, David Feuer <david.feuer(a)gmail.com> wrote: >> >>> As far as I can tell from the 7.10 documentation, it's impossible to >>> make a bidirectional pattern synonym used as a constructor have a >>> different type signature than when used as a pattern. Has this been >>> improved in 8.0? I really want something like >>> >>> class FastCons x xs | xs -> x where >>> fcons :: x -> xs -> xs >>> class FastViewL x xs | xs -> x where >>> fviewl :: xs -> ViewL x xs >>> >>> pattern x :<| xs <- (fviewl -> ConsL x xs) where >>> x :<| xs = fcons x xs >>> >>> This would allow users to learn just *one* name, :<|, that they can >>> use for sequences that are consable or viewable even if they may not >>> be the other. >>> >>> If this is not yet possible, then I think the most intuitive approach >>> is to sever the notions of "pattern synonym" and "smart constructor". >>> So I'd write >>> >>> pattern x :<| xs <- (fviewl -> ConsL x xs) >>> constructor (:<|) = fcons >>> >>> The current syntax could easily be desugared to produce *both* a >>> pattern synonym and a smart constructor in the bidirectional case. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>

1 1

Pattern synonym type flexibility
by David Feuer 20 Apr '16

20 Apr '16

As far as I can tell from the 7.10 documentation, it's impossible to make a bidirectional pattern synonym used as a constructor have a different type signature than when used as a pattern. Has this been improved in 8.0? I really want something like class FastCons x xs | xs -> x where fcons :: x -> xs -> xs class FastViewL x xs | xs -> x where fviewl :: xs -> ViewL x xs pattern x :<| xs <- (fviewl -> ConsL x xs) where x :<| xs = fcons x xs This would allow users to learn just *one* name, :<|, that they can use for sequences that are consable or viewable even if they may not be the other. If this is not yet possible, then I think the most intuitive approach is to sever the notions of "pattern synonym" and "smart constructor". So I'd write pattern x :<| xs <- (fviewl -> ConsL x xs) constructor (:<|) = fcons The current syntax could easily be desugared to produce *both* a pattern synonym and a smart constructor in the bidirectional case.

2 3

RE: [Diffusion] [Build Failed] rGHC353d8ae6fafe: SCC analysis for instances as well as types/classes
by Simon Peyton Jones 20 Apr '16

20 Apr '16

Harbormaster below says that T11195 and T4029 fail; but they don't on my machine. But tcrun045 does.. patch for that coming Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 20 April 2016 16:08 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Diffusion] [Build Failed] rGHC353d8ae6fafe: SCC analysis for | instances as well as types/classes | | Harbormaster failed to build B9256: rGHC353d8ae6fafe: SCC analysis for | instances as well as types/classes! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | GHC - Core/System FC (Auditor) | GHC - HsSyn/Parser (Auditor) | GHC - Renamer (Auditor) | GHC - Type checker/inferencer (Auditor) | GHC - Utilities (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC353d8ae6fafe | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite, GHC - Core/System FC, GHC - HsSyn/Parser, | GHC - Renamer, GHC - Type checker/inferencer, GHC - Utilities, | Harbormaster

1 0

Re: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..."
by George Colpitts 20 Apr '16

20 Apr '16

Yes, this is consistent with my investigation. The only place I could find in the source which emitted the message "Too late for parseStaticFlags..." was ghc/Main.hs. What puzzled me was why this is a Mac specific bug. On Tue, Apr 19, 2016 at 10:21 AM GHC <ghc-devs(a)haskell.org> wrote: > #10053: Regression on MacOS platform, error in ghci calling main after > loading > compiled code: "Too late for parseStaticFlags..." > -------------------------------------+------------------------------------- > Reporter: George | Owner: ak3n > Type: bug | Status: new > Priority: normal | Milestone: > Component: GHCi | Version: 7.10.1-rc2 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: x86_64 > Type of failure: Incorrect result | (amd64) > at runtime | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by ak3n): > > Replying to [comment:17 bgamari]: > > ak3n, could you elaborate? > > This error is raised in > [https://github.com/ghc/ghc/blob/master/compiler/main/StaticFlags.hs#L80 > compiler/main/Staticflags.hs], when parseStaticFlags is called in > [https://github.com/ghc/ghc/blob/master/ghc/Main.hs#L113 ghc/Main.hs]. > > So, this code is called two times: on ghci start and on "main" input > statement. > > It looks like, linker replaces "main" from the loaded module > with "main" of ghc. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10053#comment:18> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Reification of out-of-scope variables?
by Boespflug, Mathieu 19 Apr '16

19 Apr '16

Hi all, the community is increasingly using quasiquotation as a means to interoperate with foreign languages. E.g. language-c-inline, inline-c and inline-r allow calling foreign functions using foreign language syntax, rather than "foreign import" declarations. There are efforts underway for Java, Javascript and other languages too. The pattern common to most of these libraries is: * collect the content of all quasiquotes that appear in a module, generate a compilable foreign source file based on that, and then link the object code resulting from compiling that. When the foreign language is itself statically typed, we need to make sure we generate code with proper type annotations, including for any antiquotation variables. In older versions of GHC, we could derive the type annotations from the inferred Haskell types, but this is not possible since 7.8 because the types of any variable in the current "declaration group" are not made available. So libraries like inline-c ask for some extra verbosity from the user: mycossin1 :: Double -> IO Double mycossin1 somex = [cexp| double { cos($(double somex)) * sin($(double somex)) } |] The type annotations inside the quasiquote are redundant with the explicitly provided type signature. C types are typically short enough, but other languages (e.g. C++, Java), have really long fully qualified type names, so the extra annotations are a cost. The are good reasons why types aren't available from within a declaration group (it was possible to observe the order in which type inference works), hence why the extra annotations are necessary. But by the time type checking of the whole module is finished, types are fixed once and for all. So the question is: * Could we make it possible to query the types of local variables at the end of type checking? The reason I ask is: with 'addModFinalizer' and friends that TH provides, we're tantalizingly close to being able to generate foreign code wrappers that have the right types that match those of the antiquotation variables present in a module. Template Haskell already provides 'addModFinalizer'. You feed it a Q action, which will run once the whole module is type checked. If at that point we could ask, "what's the type of somex (above)?", then we could let the user write mycossin2 :: Double -> IO Double mycossin2 somex = [cexp| cos($somex) * sin($somex) |] and yet still generate a C file capturing the content of above quasiquote with the right types: double module_foo_qq1(double v1) { return (cos(v1) * sin(v1)); } since we know that somex :: Double and that the Haskell type "Double" corresponds to C's "double" primitive type. Bound variables have a unique name associated to them, which we can get hold of in Template Haskell using the 'var syntax, but f x = $(let name = 'x in addModFinalizer (reify name >>= \info -> runIO (print info)) >> [| x |]) results in a compiler error, The exact Name `x' is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful because by the time the TH finalizer runs, we're no longer in the scope of x. But since the names of the local variables are unique, could it possibly make sense to allow calling reify on them, even outside of their scope, so as to get at their type? Best, Mathieu

6 17

RE: [GHC] #11824: GHC error in desugarer lookup
by Simon Peyton Jones 19 Apr '16

19 Apr '16

Ben I'm offline, so can't reply on Phab. Calling mkTypeableBinds in tcRnHsBootDecls isn't quite right, because it'll generate lots of *bindings* whereas all we want is the *Ids* in the GlobalValEnv. (It's possible that tcg_binds is ignored in the boot-module case, but it's unsavoury to generate the bindings at all. They are generated when we process the main module.) I suggest the easiest fix is, in mkModIdBinding and mkTypeableTyConBinds, guard the binding-generation with a test for whether isHsBootOrSig is true. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of GHC | Sent: 13 April 2016 12:06 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #11824: GHC error in desugarer lookup | | #11824: GHC error in desugarer lookup | -------------------------------------+------------------------------------- | Reporter: darchon | Owner: | Type: bug | Status: patch | Priority: normal | Milestone: 8.0.1 | Component: Compiler | Version: 8.0.1-rc3 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Compile-time | Unknown/Multiple | crash | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): Phab:D2107, | Wiki Page: | Phab:D2108 | -------------------------------------+------------------------------------- | Changes (by bgamari): | | * status: new => patch | * differential: => Phab:D2107, Phab:D2108 | | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | org%2ftrac%2fghc%2fticket%2f11824%23comment%3a6&data=01%7c01%7csimonpj%40064d | .mgd.microsoft.com%7cd4862d0ed83c493164fb08d3638c0642%7c72f988bf86f141af91ab2 | d7cd011db47%7c1&sdata=JaXInqbrHs1nrAM9JsMUfX6J6hfbzJHI2k5KKRbH9i0%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell. | org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd4862d0ed83c49 | 3164fb08d3638c0642%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=S85zedvr8ceEm | 4UeWtejgMl%2buRm4XMrgdWiHwcXDVuU%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.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd4862d0ed83c493164f | b08d3638c0642%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WywP4RhTbL5cEfl%2b | xztoUe1EYuHPthiCb3vS2%2b%2fP4F8%3d

2 6

Re: Should TH TExp be able use the Q monad
by Carter Schonwald 18 Apr '16

18 Apr '16

This thread is reminding me of the metaprograming ux that agda has as of the new 2.5 release, where there's a type checking monad for proposed terms and the ability to choose to do error handling when a proposed term fails to type check. Note that their meta ast is unindexed, so the program fragments are constructed in a sort of untyped debrujin data model of agda terms On Apr 18, 2016 10:04 AM, "Richard Eisenberg" <eir(a)cis.upenn.edu> wrote: On Apr 18, 2016, at 9:45 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Well, it opens up the entire issue of dependence on typechecking order and reification. Other things being equal, simple is good... Of course that's true, but other things aren't equal -- losing Q decreases the usefulness of typed TH. I agree that there is some nastiness regarding reification. We could refuse to reify something from the same group. I'm not sure how hard that would be to enforce. Or if reification were a real bear, we could provide the IO monad. Just to see how this is used, I poked around in a download of all of Hackage from September 2015. Here's what I found. - 6 packages use typed TH: clash-prelude-0.9.2, llvm-general-quote-0.2.0.0, lookup-tables-0.1.1.1, network-uri-static-0.1.0.0, refined-0.1.1.0, and validated-literals-0.2.0. - None seem to use the ability to do work in the Q (or IO) monad. - Two (lookup-tables and refined) do use the fact that the TExp constructor is exported from Language.Haskell.TH.Syntax to make an untyped TH expression and unsafely force it into a typed TH expression. If we're going to close back doors, this seems like a much wider one than access to Q. So I guess this suggests that taking typed TH out of the Q monad wouldn't be too disruptive. But saying "no reification of anything, anywhere" seems like a big sledgehammer to stop people from reifying local things whose typed haven't settled yet. Richard _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 2

directory and GHC 8.0.1
by Ben Gamari 18 Apr '16

18 Apr '16

Hi Phil, I noticed that directory has a master-1.2.6 branch with at least one useful looking bug-fix on it. Is this the branch that you would prefer to be included in 8.0.1? Cheers, - Ben

4 10

Whither default build variables for make files?
by Carter Schonwald 18 Apr '16

18 Apr '16

Hey all, I just did a checkout of the tip of ghc 8.0 branch and it looks like the build.mk files have seen a bit of reorganization! Now for the perf aka release build the various doc variavles seem to be implicitly set somewhere else and I got a bit lost when trying to dig them up. On the flip side : is the shake build system alternative mature enough for it to be reasonable to attempt using it on my Mac ? Many thanks

3 3