- Glasgow-haskell-users

Liberalising IncoherentInstances
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

Friends I've realised that GHC's -XIncoherentInstances flag is, I think, over-conservative. I propose to liberalise it a bit. This email describes the issue. Please yell if you think this is a bad idea. Simon Suppose we have class C a where { op :: a -> String } instance C [a] where ... instance C [Char] where ... f :: [b] -> String f xs = "Result:" ++ op xs With -XOverlappingInstances, but without -XIncoherentInstances, f won't compile. Reason: if we call 'f' at Char (e.g. f "foo") then you might think we should use instance C [Char]. For example, if we inlined 'f' at the call site, to get ("Result:" ++ op "foo"), we certainly then would use the C [Char] instance, giving perhaps different results. If we accept the program as-is, we'll permanently commit 'f' to using the C [a] instance. The -XIncoherentInstances flag says "Go ahead and use an instance, even if another instance might become relevant if you were to specialise or inline the enclosing function." The GHC user manual gives a more precise spec [1]. Now consider this class D a b where { opD :: a -> b -> String } instance D Int b where ... instance D a Int where ... g (x::Int) = opD x x Here 'g' gives rise to a constraint (D Int Int), and that matches two instance declarations. So this is rejected regardless of flags. We can fix it up by adding instance D Int Int where ... but this is pretty tiresome in cases where it really doesn't matter which instance you choose. (And I have a use-case where it's more than tiresome [2].) The underlying issue is similar to the previous example. Before, there was *potentially* more than one way to generate evidence for (C [b]); here there is *actually* more than one instance. In both cases the dynamic semantics of the language are potentially affected by the choice -- but -XIncoherentInstnaces says "I don't care". So the change I propose to make IncoherentInstances to pick arbitrarily among instances that match. More precisely, when trying to find an instance matching a target constraint (C tys), a) Find all instances matching (C tys); these are the candidates b) Eliminate any candidate X for which another candidate Y is strictly more specific (ie Y is a substitution instance of X), if either X or Y was complied with -XOverlappingInstances c) Check that any non-candidate instances that *unify* with (C tys) were compiled with -XIncoherentInstances d) If only one candidate remains, pick it. Otherwise if all remaining candidates were compiled with -XInccoherentInstances, pick an arbitrary candidate All of this is precisely as now, except for the "Otherwise" part of (d). One could imagine different flags for the test in (c) and (d) but I really don't think it's worth it. Incidentally, I think it'd be an improvement to localise the Overlapping/Incoherent flags to particular instance declarations, via pragmas, something like instance C [a] where {-# ALLOW_OVERLAP #-} op x = .... Similarly {-# ALLOW_INCOHERENT #-}. Having -XOverlappingInstances for the whole module is a bit crude., and might be missed when looking at an instance. How valuable would this be? [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio… [2] http://ghc.haskell.org/trac/ghc/wiki/NewtypeWrappers

7 12

Marking type constructor arguments as nominal (e.g. Set)
by Joachim Breitner 19 Aug '13

19 Aug '13

Hi, now that roles are in HEAD, I could play around a bit with it. They were introduced to solve the unsoundness of newtype deriving, but there is also the problem of abstraction: If I define a set type based on an ord instance, e.g. data Set a = Set a -- RHS here just for demonstration the I don’t want my users to replace a "Set Int" by a "Set (Down Int)", even though the latter is a newtype of the former. This can be prevented by forcing the role of "a" to be Nominal (and not Representational, as it is by default). What I just noticed is that one does not even have to introduce new syntax for it, one can just use: type family NominalArg x type instance (NominalArg x) = x data Set' a = Set' (NominalArg a) and get different roles; here the excerpt from --show-iface (is there an easier way to see role annotations): 5b7b2f7c3883ef0d9fc7934ac56c4805 data Set a@R [..] 8e15d783d58c18b8205191ed3fd87e27 data Set' a@N The type family does not get into the way, e.g. conv (Set a) = Set' a works as usual. (I now also notice that the parser actually supports role annotations... but still a nice, backward-compatible trick here). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 5

Question about `compileToCoreModule`
by Daniel F 19 Aug '13

19 Aug '13

Hi, everyone, I have a question about `compileToCoreModule` function from the GHC module. I noticed that the following code not just outputs the Core code, but also produces object files and a linked executable (in case when 'test.hs' is a program): --------------------------- module Main where import DynFlags import GHC import GHC.Paths import MonadUtils import Outputable main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags cm <- compileToCoreModule "test.hs" output cm -- | Outputs any value that can be pretty-printed using the default style output :: (GhcMonad m, MonadIO m) => Outputable a => a -> m () output a = do dfs <- getSessionDynFlags let style = defaultUserStyle let cntx = initSDocContext dfs style liftIO $ print $ runSDoc (ppr a) cntx ----------------------------- I thought this was strange and looked up the source of 'compileToCoreModule', and indeed, it calls 'load LoadAllTargets'. So my question is, why is it necessary to do so? I had the impression that compiling Haskell to Core is a step that precedes compiling to the actual binary. NB: I tried setting `ghcLink' and `hscTarget' options in dynflags to `NoLink' and `HscNothing' respectively, but that resulted in somewhat weird Core: $ cat test.hs module Test (test) where test :: Int test = 123 test2 :: String test2 = "Hi" $ ./testcore %module main:Test (Safe-Inferred) [(reF, Identifier `Test.test')] Test.test :: GHC.Types.Int [LclIdX] Test.test = GHC.Types.I# 123 $ ./testcore-nolinknothing %module main:Test (Safe-Inferred) [] Thanks. -- Sincerely yours, -- Daniil Frumin

1 0

Private classes
by Joachim Breitner 18 Aug '13

18 Aug '13

Hi, for some reason I was under the impression that if I don’t export the methods of a class, then no user of my module can create instances. But I was wrong and in fact they can; the methods will just all be bound to "error ...". Is there really no way to create a class so that no-one else can create any instances? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 5

Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]
by Austin Seipp 14 Aug '13

14 Aug '13

On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > My proposal below doesn't really give different behavior for EmptyDataDecls in the two scenarios… the available constructs are the same under either H98 or H2010. It's just that the "distance" from the spec is different. > > Personally, I'm loathe to stray from a well-defined note in a standard for this. You're right, sorry about that. I suppose we can let someone else weigh in on this note. > I see my proposal below as a feasible solution to #7401, but I would actually favor not implementing any change here, because the workaround -- using standalone deriving -- is so easy and doesn't seem to have any real drawbacks (e.g. performance). Hmmm, I'm sort of ambivalent at this point. Looking at the user manual[1], the relevant point for -XStandaloneDeriving is that "Unlike a deriving declaration attached to a data declaration, GHC does not restrict the form of the data type..." At the same time, from a user POV, I'd think it's reasonably annoying to reject: data Foo deriving (Eq, Show, Ord) in favor of: data Foo deriving instance Eq deriving instance Show deriving instance Ord with an extra extension - and if you happen to mention a type variable, then it gets even longer since the context isn't inferred. Also, given that EmptyDataDecls in its current form is now standard in H2010, but StandaloneDeriving is not, this makes for longer code for people who do want to be standards compliant to write the trivial instance. And as a user of H2010, I'd see an empty data type as "a data type" - and not an extension. So I might expect deriving to work consistently with it, like with any other H2010 data type. This, I suppose, is what I was alluding to when I talked about 'inconsistency' earlier. Although, then it is a question of the standard itself! And then maybe it should be under an extra flag. I think there are legitimate points on all sides here. But, I think this is pretty squarely a 'user interface problem'. It's easy for us no matter what. So, I have CC'd glasgow-haskell-users - I think there's room for voices on this note, and I'd really appreciate users and developers weighing in. [1] http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/deriving.html > Richard > > On Aug 12, 2013, at 12:55 AM, Austin Seipp wrote: > >> On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >>> But, instead of creating a new extension for this feature, what about just co-opting EmptyDataDecls? More concretely, I propose this: >>> >>> Under H98: EmptyDataDecls allows both the declaration of empty data decls and deriving instances for them. >>> >>> Under H2010: EmptyDataDecls allows deriving instances for empty data decls. >>> >>> This proposal brings the annoyance that H2010 no longer implies EmptyDataDecls. >>> >>> Thoughts? >>> >>> Richard >>> >> >> IMHO, I'd find this inconsistency in extension behavior much more >> annoying than just going against the standard on this note. But that's >> just my 0.02c. >> >> -- >> Regards, >> Austin - PGP: 4096R/0x91384671 > -- Regards, Austin - PGP: 4096R/0x91384671

3 2

Problems with installing dph
by Jan Clemens Gehrke 14 Aug '13

14 Aug '13

Hi Glasgow-Haskell-Users, I'm trying to get started with DPH and have some problems. If i try getting DPH with cabal install dph-examples I get to warnings numerous times. The first warning is: You are using a new version of LLVM that hasn't been tested yet! We will try though... and the second one: Warning: vectorisation failure: identityConvTyCon: type constructor contains parallel arrays [::] Could NOT call vectorised from original version Cabal finishes with: Installing executable(s) in /home/clemens/.cabal/bin Installed dph-examples-0.7.0.5 If i try compiling the first example from http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell with ghc -c -Odph -fdph-par DotP.hs i get ghc: unrecognised flags: -fdph-par I'm running ghc version 7.6.3 cabal-install 1.16.0.2 with version 1.16.0 of the cabal library llvm 3.3-1 on a Linux (Manjaro) System. Thanks in advance for any help Jan Clemens Gehrke

2 1

Log exceptions to eventlog
by Roman Cheplyaka 13 Aug '13

13 Aug '13

Hi, Is there any way to log asynchronous exceptions to the eventlog, including information on which thread sent the exception and to which thread it was sent? Or are there any other ways to get this information? Roman

2 2

throwTo semantics
by Roman Cheplyaka 13 Aug '13

13 Aug '13

The documentation for throwTo says: throwTo does not return until the exception has been raised in the target thread. The calling thread can thus be certain that the target thread has received the exception. This is a useful property to know when dealing with race conditions: eg. if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other. I don't see how the last sentense follows. I understood it so that the implication throwTo has returned => exception has been delivered is true, but not the reverse. If my understanding is correct, then both exceptions could be delivered without any of throwTos returning. Or is it true that throwTo has returned <=> exception has been delivered ? Roman

3 3

Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
by Luke Iannini 13 Aug '13

13 Aug '13

Further investigation: I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred. The problem only occurs with LLVM 3.0. It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang. LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64<http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz> and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini <lukexipd(a)gmail.com> wrote: > The first error on a fresh checkout is > > "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O > -package-db libraries/bootstrapping.conf -hide-all-packages -i > -iutils/hsc2hs/. -iutils/hsc2hs/dist/build > -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build > -Iutils/hsc2hs/dist/build/autogen -optP-include > -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 > -package containers-0.5.0.0 -package directory-1.2.0.1 -package > filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP > -XForeignFunctionInterface -no-user-package-db -rtsopts -odir > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir > utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o > utils/hsc2hs/dist/build/C.o > > > utils/hsc2hs/C.hs:155:3: > > parse error (possibly incorrect indentation or mismatched brackets) > > > There seem to be two classes of error: one is the layout issue above, but > other files can be fixed by simply running 'expand' on them. > > > On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini <lukexipd(a)gmail.com> wrote: > >> Hi Stephen/all, >> >> I got LLVM 3.0 installed and started building again but hit a very >> strange problem now wherein tons of layout-based code (as in >> http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring >> out, e.g. >> compiler/coreSyn/CoreUnfold.lhs:481:2: >> parse error (possibly incorrect indentation or mismatched brackets) >> (some files also seem to be triggered by mixed tabs and spaces) >> >> I can fix the errors one by one by converting the code to use more >> concrete indentation (like >> do >> thing1 >> thing2 >> ) >> but it's all over the tree. >> >> Anyone have any idea what might cause this? >> >> Cheers >> Luke >> >> >> On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] < >> likeliest.complexions.stephen(a)blacksapphire.com> wrote: >> >>> Luke, >>> >>> Try llvm version 3.0 - that's what I'm using, and it definitely worked >>> before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if >>> it's been fixed yet, but it wasn't working last time I tried a couple of >>> months ago. I think this was because llvm is getting fussier about its >>> input and GHC hasn't been "tightened up" yet. >>> >>> It's really easy to build llvm from source. >>> >>> >>> Steve >>> >>> >>> On 09/08/13 20:35, Luke Iannini wrote: >>> >>>> v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1f<https://gist.github.com/lukexi/7ca55b36269703236f1f> >>>> >>>> >>>> On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <lukexipd(a)gmail.com >>>> <mailto:lukexipd@gmail.com>> wrote: >>>> >>>> OK, that got me past that one. >>>> >>>> Now I'm stuck here during compilation of integer-simple: >>>> https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9<https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9> >>>> >>>> ("unsupported relocation on symbol"/"co-processor offset out of >>>> range") >>>> >>>> >>>> On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini <lukexipd(a)gmail.com >>>> <mailto:lukexipd@gmail.com>> wrote: >>>> >>>> OK, I'm underway on this. >>>> >>>> First roadbump was: >>>> >>>> >>>> "inplace/bin/ghc-stage1" -static -H32m -O -Iincludes >>>> -Iincludes/dist -Iincludes/dist-**derivedconstants/header >>>> -Iincludes/dist-ghcconstants/**header -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 -O2 -c rts/Apply.cmm -o >>>> rts/dist/build/Apply.o >>>> >>>> >>>> >>>> >>>> You are using a new version of LLVM that hasn't been tested yet! >>>> We will try though... >>>> /usr/local/bin/llc: : error: unable to get target for >>>> 'arm-apple-darwin10', see --version and --triple. >>>> >>>> >>>> which I figured out were because the homebrew LLVM 3.4 only >>>> includes host platforms by default (x86/x86-64) >>>> Reinstalling it with all-targets enables them all: >>>> brew install llvm --with-clang --all-targets --HEAD >>>> >>>> Trying again now. >>>> >>>> >>>> >>>> >>>> On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini < >>>> lukexipd(a)gmail.com >>>> <mailto:lukexipd@gmail.com>> wrote: >>>> >>>> Update: I've got GHC HEAD building on 10.9 again, tonight >>>> I'll dive into the iOS patch! >>>> Cheers >>>> Luke >>>> >>>> >>>> On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald >>>> <carter.schonwald(a)gmail.com >>>> <mailto:carter.schonwald@**gmail.com<carter.schonwald(a)gmail.com>>> >>>> wrote: >>>> >>>> if you're on 10.8, just DL the 4.6 CLI tools to get >>>> things working again. >>>> >>>> If you're on 10.9, you'll need to use recent GHC head + >>>> CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI >>>> tools may have all the needed clang patches, but thats >>>> still needing its own validation, orthogonal to the IOS >>>> related issues ) >>>> >>>> >>>> On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini >>>> <lukexipd(a)gmail.com <mailto:lukexipd@gmail.com>> wrote: >>>> >>>> Hi Stephen, >>>> >>>> I installed 10.9 for another project and thus am in >>>> the middle of fixing up my system to be able to >>>> build GHC again, but I think I'm close — as soon as >>>> I have it going I'll try this. >>>> >>>> In the meantime someone still on 10.8 should >>>> definitely try the patch! >>>> >>>> Hope you're great! >>>> Luke >>>> >>>> >>>> On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath >>>> [to GHC-iPhone] >>>> <likeliest.complexions.**stephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >>>> <mailto:likeliest.complexions.** >>>> stephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >>>> >> >>>> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> A couple of months ago I got some patches >>>> applied to GHC mainline for the ability to cross >>>> compile to iOS. I've been doing other things and >>>> now I want to test those changes. The trouble >>>> is, I am having Apple trouble and I can't get >>>> Xcode to work. >>>> >>>> If anyone is interested in testing it for me, >>>> I'd appreciate it. >>>> >>>> The patch attached here needs to be applied to >>>> GHC head. Using this, I was able to get the >>>> cross compiler to build. The instructions are >>>> here: >>>> >>>> http://ghc.haskell.org/trac/__** >>>> ghc/wiki/Building/__**CrossCompiling/iOS<http://ghc.haskell.org/trac/__ghc/wiki/Building/__CrossCompiling/iOS> >>>> >>>> <http://ghc.haskell.org/trac/** >>>> ghc/wiki/Building/**CrossCompiling/iOS<http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS> >>>> > >>>> >>>> >>>> Steve >>>> >>>> ______________________________** >>>> _________________ >>>> iPhone mailing list >>>> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >>>> >>>> http://www.haskell.org/** >>>> mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> iPhone mailing list >>>> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >>>> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >

2 6

cascading type errors in ghc
by Evan Laforge 09 Aug '13

09 Aug '13

I frequently see one logical mistake turn into many type errors in ghc. Of course in general "one logical mistake" to a human and a type checker can be completely different things, so that's not surprising. The thing is, I feel like I started seeing more with the upgrade to ghc 7.6 (or was it 7.4?) a while back, which I guess coincides with a big typechecker overhaul. So I tracked down a specific example, though I haven't checked if this gives different results in older ghcs: complicated :: Bool -> Int -> (Double -> Double) -> Int -> Char -> Int -> Char -> () complicated _ _ _ _ _ _ _ = () t0 = complicated 0 id x1 y1 x1 y1 where x1 :: Int x1 = 0 y1 :: Char y1 = 'a' In this case, the call to complicated is missing the initial Bool. In ghci the above gives 5 separate type errors, for the 2nd, 3rd, 4th, 5th, and 6th arguments. The curious thing is, if I replace x1 and y1 with their values: t0 = complicated 0 id 0 'a' 0 'a' I'm now down to only 3 type errors, for 2nd, 4th, and 6th args. So I'm just curious: what's the difference between the where-bound stuff and literals? Also, why don't I get an error that 0 isn't a Bool? Or I suppose, that there's no instance Integral Bool?

3 3