- Glasgow-haskell-users

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

ScopedTypeVariables
by Evan Laforge 06 Aug '13

06 Aug '13

Occasionally I have to explicitly add a type annotation, either for clarity or to help choose a typeclass instance. Usually top-level type annotations take care of this, but sometimes it's convenient to only annotate a certain value, e.g. one argument of a lambda. I've noticed that while vanilla haskell is happy to allow me to put type annotations on variables where they are used (e.g. '\x -> f (x :: T)'), if I put it on the variable where it is bound (e.g. '\(x :: T) -> f x'), it wants me to turn on ScopedTypeVariables. I think ScopedTypeVariables is a nice extension and I'm sure it comes from a perfectly respectable family and all, but it feels like annotations on arguments comes in as a side-effect. Would it make sense to split it into a separate extension like TypesOnArguments so I can more accurately express my deviation from haskell2010 orthodoxy? Or is there some deeper tie between scoped type variables and annotations on arguments? Now that I think of it, it seems inconsistent that 'x :: A -> B; x a = ...' is valid, but 'x = \(a :: A) -> (...) :: B' is not. Doesn't the former desugar to the latter? And what about getting ScopedTypeVariables into haskell prime? As far as I know everyone loves it, or at least no one actually hates it :)

2 1

GHC 7.6.3 with gold linker
by harry 05 Aug '13

05 Aug '13

I'm trying to use GHC with the gold linker. This is what I get: ghc Main -pgml ld.gold Linking Main ... ld.gold: error: cannot find -lrt ld.gold: error: cannot find -lutil ld.gold: error: cannot find -ldl ld.gold: error: cannot find -lgmp ld.gold: error: cannot find -lm ld.gold: error: cannot find -lrt ld.gold: error: cannot find -ldl ... then tons of undefined reference errors. Do I need to configure something else? -- View this message in context: http://haskell.1045720.n5.nabble.com/GHC-7-6-3-with-gold-linker-tp5733763.h… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

1 0

Threadscope reporting that nothing is happening (MUT or GC) for ~2 seconds
by Patrick Palka 30 Jul '13

30 Jul '13

Hi, I'm analyzing the performance of my parallel --make branch of GHC ( https://github.com/parcs/ghc/tree/cherry-picking if anyone is interested) by compiling the Cabal repository in parallel, using two capabilities. I'm seeing very strange results from Threadscope: at some point during the compile, absolutely no work is being performed on any HEC for about 2 seconds. How do I interpret this kind of behavior? What does it mean? Relevant screenshot: http://i.imgur.com/uDQk9zG.png Patrick

1 1