- Glasgow-haskell-users

GHC HEAD build error
by Bas van Dijk 07 Dec '11

07 Dec '11

Hello, I'm trying to build GHC HEAD but get the following error: "inplace/bin/ghc-stage1" -H64m -O0 -fasm -Iincludes -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -optc-O2 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o rts/HeapStackCheck.cmm:159:305: parse error on input `(' The bug is in the GC_GENERIC macro on line 99: Capability_interrupt(MyCapability()) != 0 :: CInt However, I can't spot the problem. Bas

3 3

Re: [Haskell-cafe] More liberal than liberal type synonyms
by Dan Doel 07 Dec '11

07 Dec '11

On Wed, Dec 7, 2011 at 5:48 AM, Dmitry Kulagin <dmitry.kulagin(a)gmail.com> wrote: > I am still pretty new in Haskell, but this problem annoys me already. > > If I define certain monad as a type synonym: > > type StateA a = StateT SomeState SomeMonad a > > Then I can't declare new monad based on the synonym: > > type StateB a = StateT SomeOtherState StateA a > > The only way I know to overcome is to declare StateA without `a': > > type StateA = StateT SomeState SomeMonad > > But it is not always possible with existing code base. I'm afraid my proposal doesn't make this work. You could perhaps define StateB, but when you expand in a type you get: StateB a = StateT SomeOtherState StateA a which has a partially applied StateA, and is rejected. The only way to make this work is to eta reduce StateA manually, or make GHC recognize when a synonym can be eta reduced in this way (which might be both possible and useful as a separate proposal). My extension fell within the liberal type synonym space, which says that if you have: F G where F and G are both synonyms, and G is partially applied, then it is okay as long as expansion of F (and any subsequent expansions) cause G to become fully applied. My extension of this is just to allow partial application inside aliases as long as it meets these same criteria. The reason to disallow partially applied type aliases is that they make inference pretty much impossible, unless you only infer them in very limited circumstances perhaps. And if you can't get inference of them, you probably need to start having explicit annotations to tell the type checker what you want to happen, which has some of its own complications with the way quantifiers work in GHC and such. It'd cascade into some thorny issues. Hopefully that covers all the other subsequent stuff folks have been talking about. -- Dan

1 0

More liberal than liberal type synonyms
by Dan Doel 06 Dec '11

06 Dec '11

Greetings, In the process of working on a Haskell-alike language recently, Ed Kmett and I realized that we had (without really thinking about it) implemented type synonyms that are a bit more liberal than GHC's. With LiberalTypeSynonyms enabled, GHC allows: type Foo a b = b -> a type Bar f = f String Int baz :: Bar Foo baz = show because Bar expands to saturate Foo. However, we had also implemented the following, which fails in GHC: type Foo a b = b -> a type Bar f = f (Foo Int) (Foo Int) type Baz f g = f Int -> g Int quux :: Bar Baz quux = id That is: type synonyms are allowed to be partially applied within other type synonyms, as long as similar transitive saturation guarantees are met during their use. I don't know how useful it is, but I was curious if anyone can see anything wrong with allowing this (it seems okay to me after a little thought), and thought I'd float the idea out to the GHC developers, in case they're interested in picking it up. -- Dan

1 0

Why no multiple default method implementations?
by Bas van Dijk 24 Nov '11

24 Nov '11

Hello, Now that we have DefaultSignatures, why is it not allowed to have multiple default method implementations, as in: {-# LANGUAGE DefaultSignatures #-} class Foo a where foo :: a foo = error "foo" default foo :: Num a => a foo = 1 GHC complains: "Conflicting definitions for `foo'" The following use of multiple default signatures also gives the same error: class Foo a where foo :: a default foo :: Fractional a => a foo = 0.5 default foo :: Num a => a foo = 1 Couldn't GHC always pick the most specific default method, just as it does with instances when OverlappingInstances is enabled? Regards, Bas

2 2

Fwd: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6)
by Simon Marlow 24 Nov '11

24 Nov '11

This deserves a wider audience: if you've encountered failures when compiling FFI code with recent GHCs due to the new requirement that newtypes be non-abstract, note that this will now be a warning, not an error, in 7.4.1. We're deferring turning it into an error until 7.6.1. Cheers, Simon -------- Original Message -------- Subject: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6) Date: Thu, 24 Nov 2011 06:57:21 -0800 From: Simon Marlow <marlowsd(a)gmail.com> To: cvs-ghc(a)haskell.org Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/c6b0fd62fc715aa6c666eb8afe090… >--------------------------------------------------------------- commit c6b0fd62fc715aa6c666eb8afe09073ac7b87a83 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Thu Nov 24 14:04:23 2011 +0000 Relax the restriction on using abstract newtypes in FFI declarations. Given the high impact of this change, we decided to back off and make abstract newtypes give a warning for one release, before we make it an error in 7.6.1. Codec/Compression/Zlib/Stream.hsc:884:1: Warning: newtype `CInt' is used in an FFI declaration, but its constructor is not in scope. This will become an error in GHC 7.6.1. When checking declaration: foreign import ccall unsafe "static zlib.h deflate" c_deflate :: StreamState -> CInt -> IO CInt >--------------------------------------------------------------- compiler/typecheck/TcForeign.lhs | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/compiler/typecheck/TcForeign.lhs b/compiler/typecheck/TcForeign.lhs index 886b84d..5a4bf77 100644 --- a/compiler/typecheck/TcForeign.lhs +++ b/compiler/typecheck/TcForeign.lhs @@ -121,17 +121,29 @@ normaliseFfiType' env ty0 = go [] ty0 panic "normaliseFfiType': Got more GREs than expected" _ -> return False - if newtypeOK - then do let nt_co = mkAxInstCo (newTyConCo tc) tys - add_co nt_co rec_nts' nt_rhs - else children_only + when (not newtypeOK) $ + -- later: stop_here + addWarnTc (ptext (sLit "newtype") <+> quotes (ppr tc) <+> + ptext (sLit "is used in an FFI declaration,") $$ + ptext (sLit "but its constructor is not in scope.") $$ + ptext (sLit "This will become an error in GHC 7.6.1.")) + + let nt_co = mkAxInstCo (newTyConCo tc) tys + add_co nt_co rec_nts' nt_rhs + | isFamilyTyCon tc -- Expand open tycons , (co, ty) <- normaliseTcApp env tc tys , not (isReflCo co) = add_co co rec_nts ty + | otherwise - = children_only + = return (mkReflCo ty, ty) + -- If we have reached an ordinary (non-newtype) type constructor, + -- we are done. Note that we don't need to normalise the arguments, + -- because whether an FFI type is legal or not depends only on + -- the top-level type constructor (e.g. "Ptr a" is valid for all a). where + children_only = do xs <- mapM (go rec_nts) tys let (cos, tys') = unzip xs return (mkTyConAppCo tc cos, mkTyConApp tc tys') _______________________________________________ Cvs-ghc mailing list Cvs-ghc(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

1 0

Re: Why not allow empty record updates?
by wren ng thornton 23 Nov '11

23 Nov '11

On 11/15/11 8:07 PM, wagnerdm(a)seas.upenn.edu wrote: > Quoting wren ng thornton <wren(a)freegeek.org>: >> So far I've just defined helper functions to adjust the phantom >> type[1], each of which is implemented by (\x -> x { foo = foo x }). >> It's a horrible hack, but at least it's hidden away in library >> functions instead of something I have to look at. The annoying part > > (a bit tongue-in-cheek, and hence not sent to the mailing list) Forwarding to the list, because I actually have a serious response :) > As long as we're writing hacks, why not use unsafeCoerce? ;-) In this particular case I don't care too much about representation sharing (though I do share Ed's concern), and I generally do my best to avoid unsafeFoo just so I can minimize my personal proof obligations / maximize the utility of the compiler's type checking. Though, yes, in other projects with similar considerations I've also gone the unsafeCoerce route. Other than invalidating type system guarantees, it does have the side effect that it can interfere with rewrite rules firing (since the coercion remains in the System Fc core). And the times when I really care about representation sharing are often also the times I really care about rewrite rules firing. Which in turn means I tend to add additional rewrite rules to push the unsafeCoerce around in order to get it out of the way so that other rules can fire. But I see no way of specifying these additional rules in full generality while retaining correctness--- without some additional mechanism to say things like "this newtype wrapper is opaque in these contexts (to preserve the abstract semantics), but is translucent in these other contexts (to abide by categorical laws like functorality). It's really unfortunate that these complementary goals of sharing representation and doing rewrites/fusion are at odds in current Haskell. I run into similar issues with needing to work around coercions in Coq, since they impede the evaluator and proofs of value equality due to the weakness of Coq's case analysis. That the issue shows up in Coq as well seems to imply that the root of the problem is something deeper than noone having implemented the convenience. Agda has a stronger case analysis and so doesn't run into quite the same issues, though I'm not entirely clear on the exact ways in which Agda's case analysis gains that extra power, so it's unclear whether we could (meaningfully) add the power to Haskell without going whole hog into dependent types. Of course, this all is related to the problem of strong updates; it just happens that the update is Curry-identical, yet Church-different. Given the general preference for Church-style lambda calculi, it's not surprising that this exact problem hasn't been tackled (to my knowledge). Another place this problem has come up for me is in wanting to ensure representation sharing for values constructed by data constructors which don't make use of their type parameters. A trivial example would be sharing the representation of Nothing between all the Maybe types, or sharing the empty list among all the list types. That example isn't especially motivating, but there are other cases where we can end up with a large structure for which the type parameters are 'phantom' even though they may not be phantom in general (because other data constructors make use of them). That we want type updates for records with phantom types is just a symptom of the larger issue of wanting type updates for all quasiphantom/pseudophantom types. -- Live well, ~wren

2 1

What makes GHC's GC good for purely functional workloads?
by Edward Z. Yang 23 Nov '11

23 Nov '11

Apologies if this has been asked before. In some ways GHC's garbage collectors are very traditional, so I was wondering what magic dust makes it do better in Haskelly workloads (e.g. whereas you'd need to do a bit more work in the JVM to make some allocation pattern play nice.) Edward

3 3

Stable names and type constraints
by Lee Pike 23 Nov '11

23 Nov '11

Hi Everybody, This is a question about System.Mem.StableName <http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.4.1.0/System-M…>---let me know if this isn't the right forum, but my understanding is that stable names are GHC-specific. Consider the module below. For a function with type constraints, stable names fails to "realize" that we are pointing to the same object. As a couple of my colleagues pointed out to me, the cause is the dictionary being passed around causing new closures to be created. This can be rectified using a local variable binding (e.g., using a where clause), but it'd be nice if there were a solution to allow for observable sharing, even for functions with type constraints. Are there known solutions other than monomorphism or local variable bindings? Thanks, Lee ------------------------------------------------------------------------------- module Test where import System.Mem.StableName (StableName, makeStableName) --------------------------------------------------------------------------------- type Map a = [StableName (Expr a)] analyze :: Expr a -> IO (Map a) analyze = analyzeExpr [] analyzeExpr :: (Map a) -> Expr a -> IO (Map a) analyzeExpr env e@(Op e0) = do sn <- makeStableName e if elem sn env then return env else analyzeExpr (sn : env) e0 --------------------------------------------------------------------------------- -- Language, with one constructor class Typed a where instance Typed Int data Expr a = Op (Expr a) expr0 :: Expr a expr0 = Op expr0 expr1 :: Typed a => Expr a expr1 = Op expr1 expr2 :: Typed a => Expr a expr2 = x where x = Op x --------------------------------------------------------------------------------- -- Tests -- Returns 1 test0 :: IO () test0 = test (expr0 :: Expr Int) -- Doesn't terminate! test1 :: IO () test1 = test (expr1 :: Expr Int) -- Returns 1 test2 :: IO () test2 = test (expr2 :: Expr Int) test :: Expr a -> IO () test e = analyze e >>= putStrLn . show . length

2 1

Re: Using extcore
by Tim Chevalier 23 Nov '11

23 Nov '11

It wouldn't surprise me at all if the extcore library only worked with GHC versions less than 7. I don't have sufficiently good Internet access to download 7.0.3 right now, but once I do, I'll see what's going on. Just didn't want you to think your question had disappeared into the aether :-) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt “I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one’s own actions or lack of action.” -- Audre Lorde

1 0

behaviour change in getDirectoryContents in GHC 7.2?
by Ganesh Sittampalam 18 Nov '11

18 Nov '11

Hi, I'm just investigating what we can do about a problem with darcs' handling of non-ASCII filenames on GHC 7.2. The issue is apparently that as of GHC 7.2, getDirectoryContents now tries to decode filenames in the current locale, rather than converting a stream of bytes into characters: http://bugs.darcs.net/issue2095 I found an old thread on the subject: http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html and some GHC tickets (e.g. http://hackage.haskell.org/trac/ghc/ticket/3300) Can anyone point me at the rationale and details of the change and/or suggest workarounds? Cheers, Ganesh

13 55