November 2011 - Glasgow-haskell-users

Re: instance union decl
by Serge D. Mechveliani 12 Nov '11

12 Nov '11

The general idea of my recent instance union proposal is that for a single polymorphic type T, sometimes it is natural to define several instances by a single `instances' declaration. ------ Sergei

1 0

GHC 7.2.2 RC 1
by Ian Lynagh 12 Nov '11

12 Nov '11

We are pleased to announce the first release candidate for GHC 7.2.2: http://www.haskell.org/ghc/dist/7.2.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. 7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be worked around. Please let us know if you find any showstoppers. Thanks Ian, on behalf of the GHC team

8 11

sendWakeup bug #5553
by Bit Connor 11 Nov '11

11 Nov '11

Here's a bug I submitted 4 weeks ago, and there hasn't been much activity or responses regarding it since then: http://hackage.haskell.org/trac/ghc/ticket/5553 It causes the error message: ghc_sendWakeup_bug: sendWakeup: invalid argument (Bad file descriptor) It would be great if someone could take a look at this, or at least verify that you are able to reproduce the error using the test code provided in the bug report. Thanks, Bit

2 1

Should GHC default to -O1 ?
by Daniel Fischer 09 Nov '11

09 Nov '11

On the haskell-cafe as well as the beginners mailing lists, there frequently (for some value of frequent) are posts where the author inquires about a badly performing programme, in the form of stack overflows, space leaks or slowness. Often this is because they compiled their programme without optimisations, simply recompiling with -O or -O2 yields a decently performing programme. So I wonder, should ghc compile with -O1 by default? What would be the downsides?

11 13

Re: Records in Haskell
by Wolfgang Jeltsch 08 Nov '11

08 Nov '11

Am Montag, den 07.11.2011, 17:53 +0000 schrieb Barney Hilken: > Here is my understanding of the current state of the argument: > > Instead of Labels, there will be a new kind String, which is not a > subkind of *, so its elements are not types. The elements of String > are strings at the type level, written just like normal strings. If > you want labels, you can define them yourself, either empty: > > data Label (a :: String) > > or inhabited > > data Label (a :: String) = Label > > these definitions give you a family of types of the form Label "name", > in the first case empty (except for undefined), in the second case > inhabited by a single element (Label :: Label "name") > > There are several similar proposals for extensible records defined > using labels, all of which (as far as I can see) could be defined just > as easily using the kind String. The problem with this approach is that different labels do not have different representations at the value level. In my record system, I use label definitions like the following ones: data MyName1 = MyName1 data MyName2 = MyName2 This allows me to pattern match records, since I can construct record patterns that contain fixed labels: X :& MyName1 := myValue1 :& MyName2 := myValue2 I cannot see how this could be done using kind String. Do you see a solution for this? A similar problem arises when you want to define a selector function. You could implement a function get that receives a record and a label as arguments. However, you could not say something like the following then: get myRecord MyName1 Instead, you would have to write something like this: get myRecord (Label :: MyName1) Whis is ugly, I’d say. Yes, Simon’s proposal contains syntactic sugar for selection, but this sugar might not be available for other record systems, implemented in the language. The situation would be different if we would not only have kind String, but also an automatically defined GADT that we can use to fake dependent types with string parameters: data String :: String -> * -- automatically defined A string literal "abc" would be of type String "abc" then. However, I am not sure at the moment, if this would solve all the above problems. Best wishes, Wolfgang

6 7

Compiling using gmake
by Christian Brolin 08 Nov '11

08 Nov '11

Hello I try to set-up a gnu makefile for compiling Haskell programs with GHC. I want to generate dependencies automatically and I want to put my object (.o) files in a binary specifc directories to be able to compile for different architechtures. The problem is when GHC derives the dependencies it names the object file for the Main module to Main.o and not filename.o as it does if I don't specifiy an odir. This gives me two problems, first I cannot have more than one Main module in the same directory as I often need, e.g. for different test programs. The second problem is that it doesn't match my compile command which always names the object files after the the source files by just changing extensions from .hs to .o. So gmake does not recognize dependencies from my Main modules to other modules. I am stuck here. Any ideas?

3 2

Re: Way to expose BLACKHOLES through an API?
by Ryan Newton 07 Nov '11

07 Nov '11

Jan voted for the explicit "lockAndBlackhole" version as safer. I realize that for the Bytestring example all you would want to "gently" consume what is already available is WHNF detection alone. In that scenario you don't want to evaluate anything, just consume what is already evaluated. I would propose that when you do want to explicitly and actively blackhole something that that call be non-blocking (i.e. if someone else has already blackhole'd you don't wait). So the state machine would go: tryAcquire x = case unsafeRTStatus x of Blackhole -> return Nothing Unevaluated -> do b <- tryBlackhole x if b then return (Just x) else return Nothing Evaluated -> return (Just x) >> It would simply return Nothing if the value is BLACKHOLE'd. Of course >> it may be helpful to also distinguish the evaluated and unevaluated >> states. Further, the above simple version allows data-races (it may >> become blackhole'd right after we evaluate). An extreme version would >> actively blackhole it to "lock" the thunk... but maybe that's overkill >> and there are some other good ideas out there. > > I'd submit that your latter suggestion is far safer: return Nothing > unless we successfully blackhole the thunk or find that it's already > been evaluated. We actually *know* the blocking behavior we'll get, > and it's behavior we can't easily obtain through any other mechanism > (eg we'd have to add multiple unsafe indirections through mutable > cells into the lazy bytestring implementation to obtain the same > behavior in any other way, and essentially write out the laziness > longhand losing the benefits of indirection removal and so forth). >> A mechanism like the proposed should, for example, allow us to consume >> just as much of a lazy Bytestring as has already been computed by a >> producer, WITHOUT blocking and waiting on that producer thread, or >> migrating the producer computation over to our own thread (blowing its >> cache). > > For that you probably want WHNF-or-not detection as well (at least if > you want to schedule streaming of computation.

1 0

problems with impredicativity
by Wolfgang Jeltsch 07 Nov '11

07 Nov '11

Hello, this code is accepted by GHC 7.0.4: > {-# LANGUAGE ImpredicativeTypes #-} > > polyId :: (forall a. a) -> a > polyId x = x > > polyIdMap :: [forall a. a] -> [forall a. a] > polyIdMap xs = fmap polyId xs However, this one isn’t: > {-# LANGUAGE ImpredicativeTypes #-} > > polyId :: (forall a. Maybe a) -> Maybe a > polyId x = x > > polyIdMap :: [forall a. Maybe a] -> [forall a. Maybe a] > polyIdMap xs = fmap polyId xs Is there a way to make it accepted? Best wishes, Wolfgang

3 5

Re: Records in Haskell
by Matthew Farkas-Dyck 05 Nov '11

05 Nov '11

On 04/11/2011, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > | I really like Simon PJ's "proposal for records in Haskell". Some > | reasons for this are: > > Which one? You'll need to give your readers an explicit link > > S > Sorry. http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html -- Matthew Farkas-Dyck

1 0

Re: Using extcore
by Tim Chevalier 02 Nov '11

02 Nov '11

On Wed, Nov 2, 2011 at 8:19 AM, Knut Halvor Skrede <khskrede(a)gmail.com> wrote: > Hi, > > I'm working on a project where I need to dump Core to an alternative format. > So I'm wondering if it is possible to use the ghc api to compile haskell to > core, > and then use the extcore package to make a representation of the result as a > Core module. That way I could simply traverse it and make whatever > representation > necessary, based on the Core language definition. It seems to me like the > extcore > package is only for parsing external-core files? I don't want to have to > dump core to > a file, then parse it back. I was unable to find any documentation on how to > do this. Hi Knut -- If I may ask, why don't you want to dump ext-core to a text file? I can understand if the answer is performance reasons, but I would strongly encourage you to start with this route in order to get a prototype working. It's much easier; at least the last time I tried to use it (which was over a year ago), the GHC API was quite imperative, and when you're just starting your implementation, it's easier not to worry about that sort of thing. If you go this route, you should be able to just use the extcore library out of the box. There is some minimal documentation as a README inside the extcore package (the version that's on hackage); if you have any questions that it doesn't answer, as is likely, feel free to ask me and CC the ghc-users mailing list (so that the answer will be public and searchable). Once you have a prototype working, if you find that intermediate file reading/parsing is a bottleneck, you can change what you have to use the API to generate Core in-process instead of generating an intermediate file with -fext-core. If you want to just use the GHC API from the start, I can't be as helpful there, because I haven't played with that part of GHC in a long time, and it's known to change quickly. People on the ghc-users mailing list may be able to help. Depending on what you want to do, you may not need to use the extcore library at all if you use the API. You can generate a Core module, as well as typecheck it (using Core Lint) only using API functions that are documented in the GHC API documentation. If you did need to use the extcore library together with the API, you would need to use one of the functions in the MkExternalCore module (which should also be part of the API) to explicitly convert GHC's internal Core into external Core. I haven't done this, but there's no reason in principle why it wouldn't work. If you do get results this way, and feel like helping out, you could add your procedure to the wiki: http://hackage.haskell.org/trac/ghc/wiki If you have any followup questions, please reply to me and CC the mailing list, as I don't always read the mailing list, but it's also good if replies are on the record. 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