- Glasgow-haskell-users

Abstracting over things that can be unpacked
by Johan Tibell 06 Mar '12

06 Mar '12

Hi all, These ideas are still in very early stages. I present them here in hope of starting a discussion. (We discussed this quite a bit at last year's ICFP, I hope this slightly different take on the problem might lead to new ideas.) I think the next big step in Haskell performance is going to come from using better data representation in common types such as list, sets, and maps. Today these polymorphic data structures use both more memory and have more indirections than necessary, due to boxing of values. This boxing is due to the values being stored in fields of polymorphic type. First idea: instead of rejecting unpack pragmas on polymorphic fields, have them require a class constraint on the field types. Example: data UnboxPair a b = (Unbox a, Unbox b) => UP {-# UNPACK #-} !a {-# UNPACK #-} !b The Unbox type class would be similar in spirit to the class with the same name in the vector package, but be implemented internally by GHC. To a first approximation instances would only exist for fields that unpack to non-pointer types (e.g. Int.) Second idea: Introduce a new pragma, that has similar effect on representations as DPH's [::] vector type. This new pragma does deep unpacking, allowing for more types to be instances of the Unbox type e.g. pairs. Example: data T = C {-# UNWRAP #-} (a, b) If you squint a bit this pragma does the same as [: (a, b) :], except no vectors are involved. The final representation would be the unpacked representation of a and b, concatenated together (e.g. (Int, Int) would result in the field above being 128-bit wide on a 64-bit machine. The meta-idea tying these two ideas together is to allow for some abstraction over representation transforming pragmas, such as UNPACK. P.S. Before someone suggest using type families. Please read my email titled "Avoiding O(n^2) instances when using associated data types to unpack values into constructors." Cheers, Johan

5 5

ghci 7.4.1 no longer loading .o files?
by Evan Laforge 06 Mar '12

06 Mar '12

Is there something that changed in 7.4.1 that would cause it to decide to interpret .hs files instead of loading their .o files? E.g.: % ghc -c T.hs % ghci GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.0 ... linking ... done. Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) Ok, modules loaded: T. *T> Versus how this works with 7.0.3: % ghc-7.0.3 -c T.hs % ghci-7.0.3 GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Loading package filepath-1.2.0.0 ... linking ... done. Prelude> :l T Ok, modules loaded: T. Prelude T> It makes a big difference when ghci decides to go interpret 100 files vs just sucking in the .o files. This is OS X, 10.6.8. Anyone else see this?

7 18

Error while installing new packages with GHC 7.4.1
by Antoras 06 Mar '12

06 Mar '12

I updated my GHC version from 7.0.3 to 7.4.1. But after that GHC is unable to install some required packages. For example when I type in 'cabal install -v hoogle' I get a lot of errors (see end of message). Even after reinstalling the newest packages the errors still occurs. I use Linux-x86_64 and get this information: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 $ ghc-pkg list | grep Cabal Cabal-1.14.0 How to solve the error? Reading available packages... Resolving dependencies... In order, the following would be installed: deepseq-1.3.0.0 (reinstall) changes: array-0.4.0.0 -> 0.3.0.3 containers-0.4.2.1 (reinstall) changes: array-0.4.0.0 -> 0.3.0.3 Cabal-1.12.0 (new version) binary-0.5.1.0 (reinstall) changes: array-0.4.0.0 -> 0.3.0.3 haskell-src-exts-1.11.1 (new package) syb-0.3.6 (new package) template-haskell-2.7.0.0 (reinstall) cmdargs-0.9.3 (new package) text-0.11.1.13 (reinstall) changes: array-0.4.0.0 -> 0.3.0.3 blaze-builder-0.3.1.0 (new package) enumerator-0.4.18 (new package) blaze-builder-enumerator-0.2.0.3 (new package) hashable-1.1.2.3 (new package) case-insensitive-0.4.0.1 (new package) http-types-0.6.9 (new package) parsec-3.1.2 (new package) network-2.3.0.11 (new package) simple-sendfile-0.2.1 (new package) tagsoup-0.12.6 (new package) time-1.4 (reinstall) random-1.0.1.1 (new package) unordered-containers-0.1.4.6 (new package) uniplate-1.6.6 (new package) wai-0.4.3 (new package) warp-0.4.6.3 (new package) hoogle-4.2.8 (new package) Extracting /home/antoras/.cabal/packages/hackage.haskell.org/deepseq/1.3.0.0/deepseq-1.3.0.0.tar.gz to /tmp/deepseq-1.3.0.016966... Configuring deepseq-1.3.0.0... Dependency array ==0.3.0.3: using array-0.3.0.3 Dependency base ==4.5.0.0: using base-4.5.0.0 Using Cabal-1.10.1.0 compiled by ghc-7.0 Using compiler: ghc-7.4.1 Using install prefix: /home/antoras/.cabal Binaries installed in: /home/antoras/.cabal/bin Libraries installed in: /home/antoras/.cabal/lib/deepseq-1.3.0.0/ghc-7.4.1 Private binaries installed in: /home/antoras/.cabal/libexec Data files installed in: /home/antoras/.cabal/share/deepseq-1.3.0.0 Documentation installed in: /home/antoras/.cabal/share/doc/deepseq-1.3.0.0 Using alex version 2.3.5 found on system at: /usr/bin/alex Using ar found on system at: /usr/bin/ar No c2hs found Using cpphs version 1.12 found on system at: /home/antoras/.cabal/bin/cpphs No ffihugs found Using gcc version 4.6.2 found on system at: /usr/bin/gcc Using ghc version 7.4.1 found on system at: /usr/bin/ghc Using ghc-pkg version 7.4.1 found on system at: /usr/bin/ghc-pkg No greencard found Using haddock version 2.10.0 found on system at: /usr/bin/haddock Using happy version 1.18.6 found on system at: /usr/bin/happy No hmake found Using hsc2hs version 0.67 found on system at: /usr/bin/hsc2hs No hscolour found No hugs found No jhc found Using ld found on system at: /usr/bin/ld No lhc found No lhc-pkg found No nhc98 found Using pkg-config version 0.26 found on system at: /usr/bin/pkg-config Using ranlib found on system at: /usr/bin/ranlib Using strip found on system at: /usr/bin/strip Using tar found on system at: /bin/tar No uhc found Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library deepseq-1.3.0.0... Building deepseq-1.3.0.0... Building library... Creating dist/build (and its parents) /usr/bin/ghc --make -package-name deepseq-1.3.0.0 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id array-0.3.0.3-29b5df20d1fe0ed3d8d697b667bb789e -package-id base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e -O -Wall -XHaskell98 -XCPP Control.DeepSeq [1 of 1] Compiling Control.DeepSeq ( Control/DeepSeq.hs, dist/build/Control/DeepSeq.o ) Control/DeepSeq.hs:56:1: array-0.3.0.3:Data.Array can't be safely imported! The module itself isn't safe. Extracting /home/antoras/.cabal/packages/hackage.haskell.org/haskell-src-exts/1.11.1/haskell-src-exts-1.11.1.tar.gz to /tmp/haskell-src-exts-1.11.116966... Creating /tmp/haskell-src-exts-1.11.116966/haskell-src-exts-1.11.1/dist/setup (and its parents) /usr/bin/ghc --make /tmp/haskell-src-exts-1.11.116966/haskell-src-exts-1.11.1/Setup.hs -o /tmp/haskell-src-exts-1.11.116966/haskell-src-exts-1.11.1/dist/setup/setup -odir /tmp/haskell-src-exts-1.11.116966/haskell-src-exts-1.11.1/dist/setup -hidir /tmp/haskell-src-exts-1.11.116966/haskell-src-exts-1.11.1/dist/setup -i -i/tmp/haskell-src-exts-1.11.116966/haskell-src-exts-1.11.1 -package Cabal-1.14.0 <command line>: cannot satisfy -package Cabal-1.14.0: Cabal-1.14.0-5875475606fe70ef919bbc055077d744 is unusable due to missing or recursive dependencies: array-0.4.0.0-59d1cc0e7979167b002f021942d60f46 containers-0.4.2.1-cfc6420ecc2194c9ed977b06bdfd9e69 directory-1.1.0.2-07820857642f1427d8b3bb49f93f97b0 process-1.1.0.1-18dadd8ad5fc640f55a7afdc7aace500 (use -v for more information) Extracting /home/antoras/.cabal/packages/hackage.haskell.org/syb/0.3.6/syb-0.3.6.tar.gz to /tmp/syb-0.3.616966... Creating /tmp/syb-0.3.616966/syb-0.3.6/dist/setup (and its parents) /usr/bin/ghc --make /tmp/syb-0.3.616966/syb-0.3.6/Setup.hs -o /tmp/syb-0.3.616966/syb-0.3.6/dist/setup/setup -odir /tmp/syb-0.3.616966/syb-0.3.6/dist/setup -hidir /tmp/syb-0.3.616966/syb-0.3.6/dist/setup -i -i/tmp/syb-0.3.616966/syb-0.3.6 -package Cabal-1.14.0 <command line>: cannot satisfy -package Cabal-1.14.0: Cabal-1.14.0-5875475606fe70ef919bbc055077d744 is unusable due to missing or recursive dependencies: array-0.4.0.0-59d1cc0e7979167b002f021942d60f46 containers-0.4.2.1-cfc6420ecc2194c9ed977b06bdfd9e69 directory-1.1.0.2-07820857642f1427d8b3bb49f93f97b0 process-1.1.0.1-18dadd8ad5fc640f55a7afdc7aace500 (use -v for more information) World file is already up to date. cabal: Error: some packages failed to install: Cabal-1.12.0 depends on deepseq-1.3.0.0 which failed to install. binary-0.5.1.0 depends on deepseq-1.3.0.0 which failed to install. blaze-builder-0.3.1.0 depends on deepseq-1.3.0.0 which failed to install. blaze-builder-enumerator-0.2.0.3 depends on deepseq-1.3.0.0 which failed to install. case-insensitive-0.4.0.1 depends on deepseq-1.3.0.0 which failed to install. cmdargs-0.9.3 depends on deepseq-1.3.0.0 which failed to install. containers-0.4.2.1 depends on deepseq-1.3.0.0 which failed to install. deepseq-1.3.0.0 failed during the building phase. The exception was: ExitFailure 1 enumerator-0.4.18 depends on deepseq-1.3.0.0 which failed to install. hashable-1.1.2.3 depends on deepseq-1.3.0.0 which failed to install. haskell-src-exts-1.11.1 failed during the configure step. The exception was: ExitFailure 1 hoogle-4.2.8 depends on syb-0.3.6 which failed to install. http-types-0.6.9 depends on deepseq-1.3.0.0 which failed to install. network-2.3.0.11 depends on deepseq-1.3.0.0 which failed to install. parsec-3.1.2 depends on deepseq-1.3.0.0 which failed to install. random-1.0.1.1 depends on deepseq-1.3.0.0 which failed to install. simple-sendfile-0.2.1 depends on deepseq-1.3.0.0 which failed to install. syb-0.3.6 failed during the configure step. The exception was: ExitFailure 1 tagsoup-0.12.6 depends on deepseq-1.3.0.0 which failed to install. template-haskell-2.7.0.0 depends on deepseq-1.3.0.0 which failed to install. text-0.11.1.13 depends on deepseq-1.3.0.0 which failed to install. time-1.4 depends on deepseq-1.3.0.0 which failed to install. uniplate-1.6.6 depends on syb-0.3.6 which failed to install. unordered-containers-0.1.4.6 depends on deepseq-1.3.0.0 which failed to install. wai-0.4.3 depends on deepseq-1.3.0.0 which failed to install. warp-0.4.6.3 depends on deepseq-1.3.0.0 which failed to install.

5 8

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Do something with TypecheckedSource during build?
by JP Moresmau 02 Mar '12

02 Mar '12

Hello, I know that in 7.4 I can add a Core transformation plugin, but I didn't find in the doc if there was a way to do what I'd like to. I don't really want to go as far as Core, I think. What I do at the moment is that I use the GHC API to get to the point where I have a TypedcheckedSource and then dump information about it in a file. I was wondering if I could do the same thing by plugging "something" into GHC via the command line. So I could do ghc --make test.hs -c -fsourceplugin=myplugin, and my plugin would be given the TypecheckedSource. That means I could do my transformation directly my calling Cabal and not have to worry about launching the GHC API with all the proper flags, but without even actually generating something. Is what I want achievable with today's tools or shall I stick to using the API? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/

2 1

Re: Error while installing new packages with GHC 7.4.1
by Neil Mitchell 02 Mar '12

02 Mar '12

Hi Antoras, My suspicion is you've ended up with corrupted packages in your package database - nothing to do with Hoogle. I suspect trying to install parsec-3.1.2 directly would give the same error message. Can you try ghc-pkg list, and at the bottom it will probably say something like: The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. warp-1.1.0 I often find ghc-pkg unregister <warp> --force on all the packages cleans them up enough, but someone else may have a better suggestion. Thanks, Neil On Fri, Mar 2, 2012 at 12:02 AM, Antoras <mail(a)antoras.de> wrote: > Hi Neil, > > thanks for your effort. But it still does not work. The old errors > disappeared, but new ones occur. > > Maybe I have not yet the most current versions: > > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.4.1 > > $ cabal --version > cabal-install version 0.10.2 > using version 1.10.1.0 of the Cabal library > > This seems to be the most current version of Cabal. The command 'cabal info > cabal' brings: "Versions installed: 1.14.0" but not 1.15 > > An extract of the error messages: > > [...] > Configuring parsec-3.1.2... > Preprocessing library parsec-3.1.2... > Building parsec-3.1.2... > <command line>: cannot satisfy -package-id > text-0.11.1.13-9b63b6813ed4eef16b7793151cdbba4d: > text-0.11.1.13-9b63b6813ed4eef16b7793151cdbba4d is unusable due to missing > or recursive dependencies: > deepseq-1.3.0.0-a73ec930018135e0dc0a1a3d29c74c88 > > (use -v for more information) > <command line>: cannot satisfy -package Cabal-1.14.0: > Cabal-1.14.0-5875475606fe70ef919bbc055077d744 is unusable due to missing or > recursive dependencies: > array-0.4.0.0-59d1cc0e7979167b002f021942d60f46 > containers-0.4.2.1-cfc6420ecc2194c9ed977b06bdfd9e69 > directory-1.1.0.2-07820857642f1427d8b3bb49f93f97b0 > process-1.1.0.1-18dadd8ad5fc640f55a7afdc7aace500 > (use -v for more information) > [...] > > > On Thu 01 Mar 2012 11:06:43 PM CET, Neil Mitchell wrote: >> >> Hi Antoras, >> >> I've just released Hoogle 4.2.9, which allows Cabal 1.15, so hopefully >> will install correctly for you. >> >> Thanks, Neil >> >> On Thu, Mar 1, 2012 at 5:02 PM, Neil Mitchell<ndmitchell(a)gmail.com> >> wrote: >>> >>> Hi Antoras, >>> >>> The darcs version of Hoogle has had a more permissive dependency for a >>> few >>> weeks. Had I realised the dependency caused problems I'd have released a >>> new >>> version immediately! As it stands, I'll release a new version in about 4 >>> hours. If you can't wait that long, try darcs get >>> http://code.haskell.org/hoogle >>> >>> Thanks, Neil >>> >>> >>> On Thursday, March 1, 2012, Antoras wrote: >>>> >>>> >>>> Ok, interesting info. But how to solve the problem now? Should I contact >>>> the author of Hoogle and ask him about how solving this? >>>> >>>> >>>> On 03/01/2012 02:02 AM, Albert Y. C. Lai wrote: >>>>> >>>>> >>>>> On 12-02-29 06:04 AM, Antoras wrote: >>>>>> >>>>>> >>>>>> I don't know where the dependency to array-0.3.0.3 comes from. Is it >>>>>> possible to get more info from cabal than -v? >>>>> >>>>> >>>>> >>>>> hoogle-4.2.8 has "Cabal>= 1.8&& < 1.13", this brings in Cabal-1.12.0. >>>>> >>>>> Cabal-1.12.0 has "array>= 0.1&& < 0.4", this brings in array-0.3.0.3. >>>>> >>>>> >>>>> It is a mess to have 2nd instances of libraries that already come with >>>>> GHC, unless you are an expert in knowing and avoiding the treacherous >>>>> consequences. See my >>>>> http://www.vex.net/~trebla/haskell/sicp.xhtml >>>>> >>>>> It is possible to fish the output of "cabal install --dry-run -v3 >>>>> hoogle" >>>>> for why array-0.3.0.3 is brought in. It really is fishing, since the >>>>> output >>>>> is copious and of low information density. Chinese idiom: needle in >>>>> ocean >>>>> (haystack is too easy). Example: >>>>> >>>>> "selecting hoogle-4.2.8 (hackage) and discarding Cabal-1.1.6, 1.2.1, >>>>> 1.2.2.0, >>>>> 1.2.3.0, 1.2.4.0, 1.4.0.0, 1.4.0.1, 1.4.0.2, 1.6.0.1, 1.6.0.2, 1.6.0.3, >>>>> 1.14.0, blaze-builder-0.1, case-insensitive-0.1," >>>>> >>>>> We see that selecting hoogle-4.2.8 causes ruling out Cabal 1.14.0 >>>>> >>>>> Similarly, the line for "selecting Cabal-1.12.0" mentions ruling out >>>>> array-0.4.0.0 >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> >

2 2

Re: [Haskell-cafe] Records in Haskell
by Evan Laforge 01 Mar '12

01 Mar '12

> Thanks Evan, I've had a quick read through. Thanks for reading and commenting! > It's a bit difficult to compare to the other proposals. > > I can't see discussion of extracting higher-ranked functions and applying them > in polymorphic contexts. (This is SPJ's `rev` example.) > > Putting h-r fields into records is the standard way of emulating object- > oriented style. SPJ's view is that requirement is "very important in practice". > > (No proposal has a good answer to updating h-r's, which you do discuss.) Yeah, I've never wanted that kind of thing. I've written in object-oriented languages so it's not just that I'm not used to the feature so I don't feel its lack. And if I did want it, I would probably not mind falling back to the traditional record syntax, though I can see how people might find that unsatisfying. But my suggestion is meant to solve only the problem of composed record updates and redundant "thing"s in 'Thing.thing_field thing'. Not supporting higher-ranked function record fields *only* means that you can't use this particular convenience to compose updates to a higher-ranked field. If you happen to have that particular intersection of requirements then you'll have to fall back to typing more "thing"s for that particular update. My motivation is to solve an awkward thing about writing in haskell as it is, not add a new programming style. > Re the cons 1. "Still can't have two records with the same field name in the > same module since it relies on modules for namespacing." > > Did you see the DORF precursor page ? > http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFi… > /NoMonoRecordFields > > I tried to figure out if that would help, but I suspect not. (Looking at the > desugar for `deriving (Lens)`, you need the H98 field selector functions.) > Then for me, cons 1. is a show-stopper. (I know you think the opposite.) Yeah, I don't think the DORF precursor stuff is related, because it's all based on typeclasses. I think there are two places where people get annoyed about name clashes. One is where they really want to have two records with the same field name defined in one module. The other is where they are using unqualified imports to shorten names and get a clash from records in different modules. Only the former is a problem, the latter should work just fine with my proposal because ghc lets you import clashing names as long as you don't call them unqualified, and SDNR qualifies them for you. So about the former... I've never had this problem, though the point about circular imports forcing lots of things into the same module is well taken, I have experienced that. In that case: nested modules. It's an orthogonal feature that can be implemented and enabled separately, and can be useful in other ways too, and can be implemented separately. If we are to retain modules as *the* way to organize namespaces and visibility then we should think about fancying-up modules when a namespacing problem comes up. Otherwise you're talking about putting more than one function into one symbol, and that's typeclasses, and now you have to think of something clever to counteract typeclasses' desire to be global (e.g. type proxies). Maybe that's forcing typeclasses too far beyond their power/weight compromise design? > I also don't see whether you can 'hide' or make abstract the representation of > a record type, but still allow read-access to (some of) its fields. If you want a read-only field, then don't export the lens for 'a', export a normal function for it. However, it would mean you'd use it as a normal function, and couldn't pass it to 'get' because it's not a lens, and couldn't be composed together with lenses. I'd think it would be possible to put 'get' and 'set' into different typeclasses and give ReadLenses only the ReadLens dictionary. But effectively we'd need subtyping, so a Lens could be "casted" automatically to a ReadLens. I'm sure it's possible to encode with clever rank2 and existentials and whatnot, but at that point I'm inclined to say it's too complicated and not worth it. Use plain functions. Since 'get' turns a lens into a plain function, you can still compose with '#roField . get (#rwField1 . #rwField2)'. We could easily support 'get (#roField1 . #roField2)' by doing the ReadLens thing and putting (->) into ReadLens, it's just combining rw fields and ro fields into the same composition that would require type gymnastics. > Suppose a > malicious client declares a record with field #a. Can you stop them reading > and/or updating your field #a whilst still letting them see field #b of your > record type? I don't think it's worth designing to support malicious clients, but if you don't want to allow access to a function or lens or any value, then don't export it. #a can't resolve to M.a if M doesn't export 'a'. > With SDNR, is it possibly to define a polymorphic field selector function? I > suspect no looking at the desugar for `deriving (Lens)`, but perhaps I've mis- > understood. I mean: > get_a r = ?? #a r -- gets the #a field from any record r Nope, 'r' has to be monomorphic. That's the "no structural polymorphism" thing I was talking about. I don't mind not having it. If we do that I believe we're moving to a fundamentally different type of polymorphism, and, I think, a less principled one than typeclasses. > This mechanism then supports the idea of 'virtual' fields -- SPJ's example of > fullName, built from polymorphic firstName and lastName. The read-only version is a plain function: fullName r = firstName r ++ " " ++ lastName r Because we are using plain functions we don't need to get all fancy with "virtual" things, they're just normal functions. If you want to update fullName as well, then you could write a lens version: fullName r = lens (firstName r ++ " " ++ lastName r) (\name -> let [first, last] = unwords name in set #firstName first . set #lastName last) Also, fclabels has a notion of views where you can express one type in terms of another (say extract two fields as a pair) and then if you update the first element of the pair it updates the record that came from. It seemed complicated, but maybe it has uses I haven't thought of. I suppose if you wanted to have a record with some internal and some external ones, you could then define the external view as another record, and then they can pass around the whole thing but only get to fiddle with the external fields. I would try to solve the problem without views, e.g. nest the externally visible record inside the internal one instead of trying to put all the fields into one record. > [By the way, did you mean to post to the cafe only? Most of the discussion is > going on on ghc-users.] Oops, no I hadn't noticed which list the threads were on, thanks for pointing it out. Ccing ghc-users. Anyway, one thing I think is different about this proposal is what I said before: it aims to solve an awkward thing about haskell as it is, not add a new programming style. So it adds no power whatsoever. It's more limited than the existing record notation, so it's not even a replacement (but from what I understand, the other proposals aren't either). But it takes what is, for me, the 90% use case and eliminates the redundant typing. Maybe it's not nearly 90% for other people, I can only speak for myself.

1 0

Unpack primitive types by default in data
by Johan Tibell 01 Mar '12

01 Mar '12

Hi all, I've been thinking about this some more and I think we should definitely unpack primitive types (e.g. Int, Word, Float, Double, Char) by default. The worry is that reboxing will cost us, but I realized today that at least one other language, Java, does this already today and even though it hurts performance in some cases, it seems to be a win on average. In Java all primitive fields get auto-boxed/unboxed when stored in polymorphic fields (e.g. in a HashMap which stores keys and fields as Object pointers.) This seems analogous to our case, except we might also unbox when calling lazy functions. Here's an idea of how to test this hypothesis: 1. Get a bunch of benchmarks. 2. Change GHC to make UNPACK a no-op for primitive types (as library authors have already worked around the lack of unpacking by using this pragma.) 3. Run the benchmarks. 4. Change GHC to always unpack primitive types (regardless of the presence of an UNPACK pragma.) 5. Run the benchmarks. 6. Compare the results. Number (1) might be what's keeping us back right now, as we feel that we don't have a good benchmark set. I suggest we try with nofib first and see if there's a different and then move on to e.g. the shootout benchmarks. I imagine that ignoring UNPACK pragmas selectively wouldn't be too hard. Where the relevant code? Cheers, Johan

8 29

New STM?
by wren ng thornton 01 Mar '12

01 Mar '12

Hello all, I had some patches committed to STM a while back[1], and for some reason I was expecting them in the new GHC release. Does STM only ship with the Platform? If not, then any idea when the next version of STM will be released? [1] http://hackage.haskell.org/trac/ghc/ticket/5104 http://www.haskell.org/pipermail/cvs-libraries/2011-April/012914.html -- Live well, ~wren

2 2

Understanding the -A and the -H flags
by Johan Tibell 29 Feb '12

29 Feb '12

Hi! I'm trying to understand the interaction between the -A and -H RTS flags. The documentation at http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/runtime-control.html says that if you use -H (with or without an argument) it implicitly implies some value of -A. However, it's not clear to me what value -A will get and how that value is related to the value of -H. For example, if I set the suggested heap size to 1G, using -H1G, surely the size of the nursery (-A) won't be "whatever is left over," but something more reasonable e.g. the size of the L2 cache? Perhaps it would make sense to document the actual algorithm used to set -A given -H (with and without argument.) Cheers, Johan

3 6