Re: Trouble building GHC
Hi Lyle,
There was a temporary build issue, fetching newest master should fix it.
Krzysztof
On Thu, Jun 1, 2023 at 12:03 AM Lyle Kopnicky wrote:
>>
>> Thanks, Georgi and Sebastian.
>
>
> The instructions at https://github.com/alpmestan/ghc.nix and https://ghc.dev/
> seem a bit outdated, then. I’m not sure who maintains those.
>
> In the README.md for ghc.nix, it says to run:
>
> nix-shell https://github.com/alpmestan/ghc.nix/archive/master.tar.gz --attr
> devShells..default
>
> That failed didn’t work for me and I was told I needed to use nix-develop,
> which worked.
>
> Then later, it says to run:
>
> $ ./boot && ./configure $CONFIGURE_ARGS # In zsh, use ${=CONFIGURE_ARGS}
>
> …which as you pointed out should be updated to configure_ghc.
>
> Anyway, that got me further, but I still get several fatal errors of this
> sort:
>
> compiler/GHC/Tc/Zonk/Type.hs:1277:13: error:
> • Illegal equational constraint Anno
> (StmtLR GhcTc GhcTc (LocatedA (body
> GhcTc)))
> ~ SrcSpanAnnA
> (Use GADTs or TypeFamilies to permit this)
> • In the type signature:
> zonkStmt :: Anno (StmtLR GhcTc GhcTc (LocatedA (body GhcTc)))
> ~ SrcSpanAnnA =>
> (LocatedA (body GhcTc) -> ZonkTcM (LocatedA (body GhcTc)))
> -> Stmt GhcTc (LocatedA (body GhcTc))
>-> ZonkBndrTcM (Stmt GhcTc (LocatedA (body GhcTc)))
> |
> 1277 | zonkStmt :: Anno (StmtLR GhcTc GhcTc (LocatedA (body GhcTc))) ~
> SrcSpanAnnA
> |
> ^^^...
> Command failed
> Build failed.
>
>
> Georgi, I might just ping you on Slack about it. (We’re coworkers.)
>
> Thanks,
> Lyle
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Alternative to isTypeLevPoly
The type argument to LitRubbish should be a fixed RuntimeRep. If it is not, you can file a bug. I have fixed a related bug in f435d55fe969e7. Krzysztof On Thu, Sep 15, 2022 at 1:12 PM Csaba Hruska wrote: > > I've investigated a bit more. You are right `typeHasFixedRuntimeRep` works > fine, the panic was caused by querying the representation type of > `LitRubbish` type argument. In some cases `getRuntimeRep` causes GHC panic > for `LitRubbish` type arguments. > I did solve the issue with special casing the LitRubbish type argument > handling by using only the `runtimeRepPrimRep` function. In the general case > I tested the type with `isUnboxedTupleType` and `isUnboxedSumType` which rely > on `getRuntimeRep`. > Thanks for the tips and feedback. > Regards, > Csaba > > On Wed, Sep 14, 2022 at 6:44 PM Sam Derbyshire > wrote: >> >> Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep have the >> same precondition: the kind of the type is of the form TYPE rep. So they >> should panic in the same circumstances. Can you give a bit more information? >> What panics are you running into? >> >> On Wed, 14 Sept 2022 at 18:40, Csaba Hruska wrote: >>> >>> Hi, >>> Thanks for the tip, I've tried it and it behaves differently than >>> isTypeLevPoly. I can get panic when querying the reptype for fixed >>> reptypes. That means isTypeLevPoly semantically is not the same as the >>> negated result of typeHasFixedRuntimeRep. >>> >>> On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, wrote: Hi Csaba, I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type. Best, Sam On Wed, 14 Sept 2022 at 18:12, Csaba Hruska wrote: > > Hello GHC Devs, > > I've noticed that the `isTypeLevPoly` function has been removed from GHC > since 9.4. > I used it to decide the validity of querying the representation type of > every value in the STG IR. > It was mandatory to prevent GHC panics, because there are a lot of > partial functions in GHC. > Is there an alternative to `isTypeLevPoly` in GHC 9.4? > > Best regards, > Csaba Hruska > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why can't arguments be levity polymorphic for inline functions?
Note that you can use Typed Template Haskell as a workaround, e.g.
f :: forall r (a :: TYPE r). Code Q (a -> a)
f = [||\x -> x||]
In the future this might be integrated better with the restriction
polymorphism checking:
https://gitlab.haskell.org/ghc/ghc/-/issues/18170
https://gitlab.haskell.org/ghc/ghc/-/wikis/FixedRuntimeRep#typed-template-haskell
On Fri, Oct 8, 2021 at 5:19 PM Simon Peyton Jones via ghc-devs
wrote:
>
> We do have a few such functions, and we give them a “compulsory unfolding”
> which means they MUST be inlined at EVERY call site. But
>
>
>
> Usually if a module exports a function, it generates code for that function.
> But for these guys it can’t. We don’t have a mechanism for *not* generating
> code for user-defined functions. We could add an INLINE-COMPULSORY pragma
> perhaps.
> Even then we’d have to check that every call of such a function is applied to
> enough arguments to get rid of all levity/representation polymorphism; so
> that when it is inlined all is good. It’s not clear how to do that in general.
>
>
>
> That’s the kind of thing Richard means by “templates”.
>
>
>
> Simon
>
>
>
> PS: I am leaving Microsoft at the end of November 2021, at which point
> simo...@microsoft.com will cease to work. Use simon.peytonjo...@gmail.com
> instead. (For now, it just forwards to simo...@microsoft.com.)
>
>
>
> From: ghc-devs On Behalf Of Clinton Mead
> Sent: 08 October 2021 00:37
> To: ghc-devs@haskell.org
> Subject: Why can't arguments be levity polymorphic for inline functions?
>
>
>
> Hi All
>
>
>
> Not sure if this belongs in ghc-users or ghc-devs, but it seemed devy enough
> to put it here.
>
>
>
> Section 6.4.12.1 of the GHC user manual points out, if we allowed levity
> polymorphic arguments, then we would have no way to compile these functions,
> because the code required for different levites is different.
>
>
>
> However, if such a function is {-# INLINE #-} or {-# INLINABLE #-} there's no
> need to compile it as it's full definition is in the interface file. Callers
> can just compile it themselves with the levity they require. Indeed callers
> of inline functions already compile their own versions even without levity
> polymorphism (for example, presumably inlining function calls that are known
> at compile time).
>
>
>
> The only sticking point to this that I could find was that GHC will only
> inline the function if it is fully applied, which suggests that the
> possibility of partial application means we can't inline and hence need a
> compiled version of the code. But this seems like a silly restriction, as we
> have the full RHS of the definition in the interface file. The caller can
> easily create and compile it's own partially applied version. It should be
> able to do this regardless of levity.
>
>
>
> It seems to me we're okay as long as the following three things aren't true
> simultaneously:
>
>
>
> 1. Blah has levity polymorphic arguments
>
> 2. Blah is exported
>
> 3. Blah is not inline
>
>
>
> If a function "Blah" is not exported, we shouldn't care about levity
> polymorphic arguments, because we have it's RHS on hand in the current module
> and compile it as appropriate. And if it's inline, we're exposing it's full
> RHS to other callers so we're still fine also. Only when these three
> conditions combine should we give an error, say like:
>
>
>
> "Blah has levity polymorphic arguments, is exported, and is not inline.
> Please either remove levity polymorphic arguments, not export it or add an
> {-# INLINE #-} or {-# INLINABLE #-} pragma.
>
>
>
> I presume however there are some added complications that I don't understand,
> and I'm very interested in what they are as I presume they'll be quite
> interesting.
>
>
>
> Thanks,
> Clinton
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: magicDict
I would like to propose one more option: withDict :: dt -> (ct => a) -> a 1. This is less symmetric than '(ct => a) -> dt -> a' but in existing applications magicDict gets the arguments in the reverse order. 2. Easier to chain 'withDict d1 (withDict d2 ...)'. 3. The name is similar to 'withTypeable' or 'withFile', and avoids arguing which is reify or reflect. On Mon, Apr 26, 2021 at 9:41 AM Simon Peyton Jones via ghc-devs wrote: > > Can we just agree a name, then? Please correct me if I’m wrong, but > > I think Ed prefers ‘reifyDict’, > That is compatible with the existing reflection library > Arnaud disagrees but isn’t going to die in the trenches for this one > Virtually anything is better than ‘magicDict’. > > > > > > So: reifyDict it is? > > > > Simon > > > > From: Spiwack, Arnaud > Sent: 26 April 2021 08:10 > To: Edward Kmett > Cc: Simon Peyton Jones ; GHC developers > > Subject: Re: magicDict > > > > > > > > On Sun, Apr 25, 2021 at 2:20 AM Edward Kmett wrote: > > I speak to much this same point in this old stack overflow response, though > to exactly the opposite conclusion, and to exactly the opposite pet peeve. > > > > https://stackoverflow.com/a/5316014/34707 > > > > :-) > > > > I do not feel that I chose the vocabulary without due consideration of the > precise meaning of the words used. > > > > I didn't mean to imply that you did. Sorry if I did so: written communication > is hard. For what it's worth, I didn't really think that I would change your > mind, either. > > > > Though it still seems to me that the name `ReifiedMonoid` uses the word for a > different thing than the `reifyMonoid` function does. > > > > To be explicit: > > > > Viewing a type as a space, 'reify' in the reflection library takes some space > 'a' and splits it into individual fibers for each term in 'a', finding the > appropriate one and handing it back to you as a fresh type 's' that captures > just that singular value. The result is significantly less abstract, as we > gained detail on the type, now every point in the original space 'a' is a new > space. At the type level the fresh 's' in s `Reifies` a now concretely names > exactly one inhabitant of 'a'. > > > > On the flip side, 'reflect' in the reflection library forgets this finer > fibration / structure on space, losing the information about which fiber the > answer came from, being forgetful is precisely the justification of it being > the 'reflect' half of the reify -| reflect pairing. > > > > I confess I don't necessarily anticipate this changing your mind but it was > not chosen blindly, reflect is the forgetful mapping here, reification is > free and left adjoint to it, at least in the context of > reflection-the-library, where a quantifier is being injected to track the > particular member. > > > > I've got to admit that I have the hardest time seeing the `s` as representing > an inhabitant of `a`. I'm probably missing something here. > > > > I also don't think that a free object construction embodies a reify/reflect > pair completely. It's probably fair to see `reify` as being the natural > mapping from the free object of X to X (the counit of the adjunction). But > reification will not be the unit of the adjunction, because it's trivial. So > there is still a piece missing in this story. > > > > Anyway… I've made my point, and I am not too willing to spend too much time > proving Wadler's law correct. So I think I'll stop here, fascinating a > conversation though it is. > > > > Best, > > Arnaud > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: magicDict
How about 'reifyDict'? The reflection library uses 'reify' to create a dictionary and 'reflect' to extract a value out of it. https://hackage.haskell.org/package/reflection-2.1.6/docs/Data-Reflection.html#v:reify On Thu, Apr 22, 2021 at 3:27 PM Spiwack, Arnaud wrote: > > Let me upvote `reflectDict`. > > On Thu, Apr 22, 2021 at 12:41 PM Simon Peyton Jones via ghc-devs > wrote: >> >> Ed, and other ghc-devs >> >> We are busy tidying up magicDict, and making it much more type-safe: see >> >> https://gitlab.haskell.org/ghc/ghc/-/issues/16646 >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5573 >> >> As part of that change we’re think of changing its currently-rather-obscure >> name. I rather favour “reflectDict”. Any other views? >> >> Simon >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Use of forall as a sigil
We should not reuse the lambda abstraction syntax for foralls. One is defining a function, and the other a function type. With Dependent Haskell, we could have: type T = forall a -> Maybe a type R = \a -> Maybe a Here, T has kind * and (\_ -> Nothing) is a value of type T, while R has kind * -> * and could be defined with 'type R a = Maybe a'. On Thu, Dec 3, 2020 at 6:32 PM Sylvain Henry wrote: > > I don't know if this has been discussed but couldn't we reuse the lambda > abstraction syntax for this? > > That is instead of writing: forall a -> > Write: \a -> > > Sylvain > > > On 03/12/2020 17:21, Vladislav Zavialov wrote: > > There is no *implicit* universal quantification in that example, but there is > an explicit quantifier. It is written as follows: > > forall a -> > > which is entirely analogous to: > > forall a. > > in all ways other than the additional requirement to instantiate the type > vatiable visibly at use sites. > > - Vlad > > > On Thu, Dec 3, 2020, 19:12 Bryan Richter wrote: >> >> I must be confused, because it sounds like you are contradicting yourself. >> :) In one sentence you say that there is no assumed universal quantification >> going on, and in the next you say that the function does indeed work for all >> types. Isn't that the definition of universal quantification? >> >> (We're definitely getting somewhere interesting!) >> >> Den tors 3 dec. 2020 17:56Richard Eisenberg skrev: >>> >>> >>> >>> On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: >>> >>> Consider `forall a -> a -> a`. There's still an implicit universal >>> quantification that is assumed, right? >>> >>> >>> No, there isn't, and I think this is the central point of confusion. A >>> function of type `forall a -> a -> a` does work for all types `a`. So I >>> think the keyword is appropriate. The only difference is that we must state >>> what `a` is explicitly. I thus respectfully disagree with >>> >>> But somewhere, an author decided to reuse the same keyword to herald a type >>> argument. It seems they stopped thinking about the meaning of the word >>> itself, saw that it was syntactically in the right spot, and borrowed it to >>> mean something else. >>> >>> >>> Does this help clarify? And if it does, is there a place you can direct us >>> to where the point could be made more clearly? I think you're far from the >>> only one who has tripped here. >>> >>> Richard >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Question about HsWrapper for constructors
Hi Kai,
This was changed with linear types.
In Core, the constructor Just has now the linear type forall a. a %1 -> Maybe a.
For backwards compatibility, every occurrence of Just is eta-expanded
to \(@a # m) (x :: a) -> Just @a x, so that it can be used in a
non-linear context.
In the case of [], this transformation adds an extra type parameter, which
doesn't change much.
The details are in return_data_con and in Note [Linear fields generalization]
in Tc/Gen/Head.hs.
Best,
Krzysztof
On Wed, Nov 18, 2020 at 5:01 PM Kai-Oliver Prott
wrote:
>
> Hi all,
>
> I've tried a development snapshot of GHC's master branch from the
> beginning of this month and I am curious about the reason for a specific
> change. I noticed that a simple program like
>
> idNil :: [a] -> [a]
> idNil [] = []
>
> is internally represented (after type checking) as:
>
> AbsBinds [] []
>{Exports: [idNil <= idNil2]
> Exported types: idNil :: forall a. [a] -> [a]
> Binds: idNil2 [] = (/\(@a2). [] @a2) @a
>
> Can someone point me to a reason why the right side of idNil2 is not
> represented as [] @ a, like it was in GHC 8.10.1? I have not tried it
> with GHC 9.0. It is interesting to have a type lambda that is
> immediately followed by a type application.
>
> Thanks,
>
> Kai
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GHC 9.0?
Hi, There is an exceptional number of changes stated for the next release. * Better pattern matching coverage detection * New windows IO manager * Linear types * Large-scale typechecker changes - Taming the Kind Inference Monster, simplified subsumption * Better register allocation, improving runtime by 0.8% according to release notes * ghc-bignum * Explicit specificity and eager instantiation * Qualified do * Lexical negation * Perhaps Quick Look will manage to land Should we call it GHC 9.0? I think the name would be deserved. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HsTick and HsBinTick
I confirm. I added this in the description of https://gitlab.haskell.org/ghc/ghc/issues/16830. Krzysztof On Mon, Apr 13, 2020 at 1:00 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Friends > > I think HsTick and HsBinTick are added (only) by GHC.HsToCore.Coverage > > So I think the cannot occur in HsExpr GhcPs or HcExpr GhcRn > > If so we should change the data type decl to say this explicitly. > > Can anyone confirm or deny and add a ticket if so? > > Simon > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How to access a wiki page?
The search link goes to https://gitlab.haskell.org/ghc/ghc/wikis/Core-Representation-of-Typed-Template-Haskell-Quotes but it should go to https://gitlab.haskell.org/ghc/ghc/wikis/template-haskell/Core-Representation-of-Typed-Template-Haskell-Quotes On Fri, Mar 22, 2019 at 11:33 AM Matthew Pickering < matthewtpicker...@gmail.com> wrote: > I made a wiki page for something I am working on but now I can't > access the page anymore. > > The search thankfully displays the page as the first result. > > > https://gitlab.haskell.org/search?utf8=%E2%9C%93=core+representation_id=_id=1=wiki_blobs_ref= > > But if I click on the page then it takes me to a UI which asks me to > create a new page. > > This is obviously a bug in gitlab but how can I get to the page anyway? > > Cheers, > > Matt > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cabal not updated after rebase?
Hi, Does `git clean -fdx .` in libraries/Cabal help? git clean doesn't go into submodules. -Krzysztof On Mon, Dec 3, 2018 at 6:09 PM My Nguyen wrote: > Hi all, > > > I've finished quite a big rebase and was trying to rebuild, but it failed > with: > > ghc-cabal: Encountered missing dependencies: > Cabal ==2.5.* > > I then tried applying my patch on a fresh checkout of GHC and found the > reason: > > *libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:119:1:**error:* > > * Bad interface file: > libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Binary.hi* > > * Something is amiss; requested module > Cabal-2.4.0.1:Distribution.Compat.Binary differs from name found in the > interface file Cabal-2.5.0.0:Distribution.Compat.Binary (if these names > look the same, try again with -dppr-debug)* > > * |* > > *119 |**import Distribution.Compat.Binary (Binary (..))* > > * |** ^^* > > > *libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:120:1:**error:* > > * Bad interface file: > libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Semigroup.hi* > > * Something is amiss; requested module > Cabal-2.4.0.1:Distribution.Compat.Semigroup differs from name found in the > interface file Cabal-2.5.0.0:Distribution.Compat.Semigroup (if these names > look the same, try again with -dppr-debug)* > > * |* > > *120 |**import Distribution.Compat.Semigroup (Semigroup (..), gmappend, > gmempty)* > > * |** > * > > > *libraries/Cabal/Cabal/Distribution/Compat/Prelude.hs:141:1:**error:* > > * Bad interface file: > libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/Stack.hi* > > * Something is amiss; requested module > Cabal-2.4.0.1:Distribution.Compat.Stack differs from name found in the > interface file Cabal-2.5.0.0:Distribution.Compat.Stack (if these names look > the same, try again with -dppr-debug)* > > * |* > > *141 |**import Distribution.Compat.Stack* > > * |** * > > > I'm sure I did `git module update`; I even `git clean` everything and > `make` from fresh but somehow the cabal still isn't updated. Can anyone > help me on why this is happening and how to fix it? > > > Thanks so much, > > My > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows build broken (again)
Python 3 is a likely culprit (though I couldn't confirm it), so I reverted it. Does it work now? On Fri, Oct 3, 2014 at 5:51 PM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-10-03 at 17:29:31 +0200, Simon Peyton Jones wrote: Perhaps, yes, it is Python 3. I don't know. Could someone revert to make it work again, please? Fyi, I can't reproduce this specific problem on Cygwin at least (I don't have any working pure Msys2 environment yet (still working on it), as this may exactly be the kind of failure I'd expect Msys2 to be prone to while Cygwin to be unaffected by). What I tried in order to reproduce: $ git rev-parse HEAD 084d241b316bfa12e41fc34cae993ca276bf0730 # -- this is the Py3/testsuite commit $ make TEST=tc012 WAY=normal ... = tc012(normal) 3039 of 4088 [0, 0, 0] cd ./typecheck/should_compile 'C:/cygwin64/home/ghc/ghc-hvr/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc012.hs -fno-warn-incomplete-patterns tc012.comp.stderr 21 OVERALL SUMMARY for test run started at Fri Oct 3 15:42:04 2014 GMT 0:00:03 spent to go through 4088 total tests, which gave rise to 12360 test cases, of which 12359 were skipped 0 had missing libraries 1 expected passes 0 expected failures ... And btw, with the latest GHC HEAD commit (and I suspect the recent HEAP_ALLOCED-related commits to be responsible for that), I get a ton of testsuite failures due to such errors: T8639_api.exe: Unknown PEi386 section name `staticclosures' (while processing: C:\cygwin64\home\ghc\ghc-hvr\libraries\ghc-prim\dist-install\build\HSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.o) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: doc fix
That's correct: https://ghc.haskell.org/trac/ghc/ticket/3202 It was documented in the GHCi section of documentation, I added now a mention in the MR section. On Wed, Feb 5, 2014 at 8:22 PM, Edward A Kmett ekm...@gmail.com wrote: Isn't it just the default for ghci? -Edward On Feb 5, 2014, at 12:35 AM, Kazu Yamamoto (山本和彦) k...@iij.ad.jp wrote: Hi, If I understand correctly, NoMonomorphismRestriction is now the default for GHC 7.8. I think that its document explicitly describes it. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Enable TypeHoles by default?
I have re-sent the question to glasgow-haskell-users; to avoid duplication, let's continue the thread there. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Enable TypeHoles by default?
Hello, I propose to enable -XTypeHoles in GHC by default. Unlike other -X* flags, holes do not really change meaning of the program, they only change error messages. Instead of _x not in scope, we effectively get _x not in scope, its expected type is a - a. You get it only if you precede the identifier not in scope with underscore, so in some sense you declare the intention of using holes. Two possible issues: (a) If you use -fdefer-type-errors, then a program might compile, while previously it did not. However, we should facilitate compiling with defer-type-errors, so I don't think this is a disadvantage. (b) The identifier _ becomes both a pattern and a hole by default, which might confuse new users. Reply: I have never seen anyone ask why code such as Just _ - _ does not work. IMO the productivity boost by having holes by default outweighs those two objections. I am open to hearing any other possible issues others might find. The change is trivial implementation-wise; add Opt_TypeHoles to the list in languageExtensions Nothing in DynFlags. -KG ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
