- Glasgow-haskell-users

Why I Want Global Field Names (By Default)
by Gershom Bazerman 07 Mar '12

07 Mar '12

The discussion on records has in some ways narrowed (which is good), but within that narrowed scope of disagreement become very contentious on global vs. local default scope for field names. Those in favor of information-hiding as a key feature have been pretty vocal so far, and while others have argued, I don't think the opposite approach has been strongly motivated. I want to put forward at least one such strong motivation for global field names (aka SORF-style) rather than locally declared field names as a default. Suppose we have some sort of persistence layer implemented with records mapped to, e.g., rows within database tables. In the underlying data, many columns in different tables could share the same name. Now we may want to implement the generation of these record data declarations with some sort of automatic code generation. Alternately, we may want to write these declarations by hand, and automatically populate and migrate the database. It doesn't really matter. For different columns with the same name, we necessarily want to refer to these with the same selector -- i.e. we're not interested in building a one-deep hierarchy where certain "address" selectors refer to the "address" within some columns, and other "address" selectors refer to others. Arguably, we might want such a thing, but with sufficient tables with sufficient columns, the complexity to the programmer in determining the right mappings could simply be not worth it. So, suppose we have a locally declared fields solution (such as DORF). Now, where do these fields live? Arguably, we want a module per record. Otherwise, we're forced to pull in the entire namespace of our database at once, when we only want a fraction in any given client module. Clearly, the field selectors shouldn't live in the module for each individual record -- this means that they're dispersed all over the place, and MyDb.Corporation must import MyDb.Person to get the "address" label or vice-versa, which introduces strange and spurious dependencies. The obvious solution is to create a MyDb.Labels module which holds all the shared field declarations. But now, we want to introduce a new table. This table uses some labels shared with other tables, but uses some labels which are new. To add this table, we then have to update our MyDb.Labels module. This then forces a recompilation of the Labels module. This in turn forces a recompilation of every module which depends on Labels -- at a minimum, every module representing any database table. This in turn again forces a recompilation of any module using any database table. For a project which actually uses the persistence layer widely and freely, this effectively means a recompilation of the entire project! For a sufficiently large project (and I have worked with such) this can be extremely time consuming. So, with any system limited to local field declarations, and with a minimal and reasonable set of design choices to allow field sharing where desired, we discover that it must necessarily have frequent full rebuilds for operations which *should* require compiling a couple of files at most. The above argument holds under a number of modifications. For a database/table layer, we can substitute a layer such as happstack uses. Or, we can substitute a query API to some service which returns results in JSON or XML (or even simply an XML parser layer). How might we amend such a system to avoid this terribly pessimal, bad, no-good behavior? Well, imagine we had a Labels module that declared every possible field in advance. Now, no matter what we wanted, it would already exist, the module would not need to be modified, and so a full recompile would not be triggered. Such a Labels module is clearly impossible to write in finite disk space, and compile in finite time. However, we can provide a simulation of precisely this functionality in the following way (using, e.g., hlists or the like) : data Heof; data La; instance Letter La; data Lb; instance Letter Lb; ... instance Label Heof instance (Letter a, Label b) => Label (a :* b) class Label f => Has r f t where... However, writing (undefined :: La :* Lb :* Lc :* Heof) for a label "abc" is a bit of a pain. Sugar can eliminate this a bit. With a bit more sugar, and new toys in GHC, we can simply write "abc" at the type level rather than the value level! Clearly though, "abc" is a very different sort of type than Bool or Int. It would be nice to statically state that certain places which can now take any type, can only take types like "abc". We want to restrict our types by their "type." This "type" given to types is called a _Kind_. We can then say that things like "abc" at the type level are of kind String. So, if we want to say that our Has class can only take fields like "abc" we can say the following: class Has (r :: *) (f :: String) (t :: *) where get :: r -> t Which is precisely the SORF proposal! From our above description, we can see a number of straightforward ways to recover optional representation hiding. The most obvious thing is simply to wrap records in newtypes. data PrivateRecord = PR {x :: Int} newtype PRInterface= PRI {unPRI :: PR} Now, if the module exports PRInterface and not PrivateRecord (and not unPRI), users can pass around PR values (wrapped in a newtype), but since those PR values don't have Has instances, then they can't get at the x directly and certainly can't modify it. (Standalone + newtype deriving lets you cheat here, but arguably you just want to make breaking abstraction explicit and painful -- impossible is surprisingly hard in Haskell anyway). However, we can do one better, and recover DORF and SORF behavior at once! class Label a class Label f => Has (r :: *) (f :: *) (t :: *) where get :: r -> t instance Label (a :: String) Now we have global field names "baked in" and by default (and indeed proper global names, as I've argued *must be* baked in to be usable). However, we also have the opportunity of declaring private field names: data MyPrivateLabel instance Label MyPrivateLabel Now, if you don't export MyPrivateLabel (or any type which contains MyPrivateLabel) then your abstraction is again safe! So this is a slight generalization of SORF, that solves (I think) the information hiding issue, giving easy use of either global or locally scoped labels. Sugar can be implemented as in Ian's proposal, or otherwise. If everyone finds this agreeable (and I can imagine no reason they wouldn't!) then that leaves us with only a very few semantic issues left. In fact, I think the *only* remaining issue is updates, where I think it would be useful to redirect some collective thought. Having solved all that, we can get back to what's really important -- debating syntax :-) Hope this is clarifying, Gershom

5 5

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