- Glasgow-haskell-users

Re: thoughts on the record update problem
by Gershom B 08 Mar '12

08 Mar '12

On Thu, Mar 8, 2012 at 4:52 PM, Greg Weber <greg(a)gregweber.info> wrote: > syntax we would like. Does that make sense? I take it that you agree > that we should separate the discussion of semantics from > implementation: this is a perfect example of why. If we can describe semantics without concern for the possibility/needs of implementation, then I've got some _great_ proposals I'd like to make! --Gershom

1 0

thoughts on the record update problem
by Barney Hilken 08 Mar '12

08 Mar '12

There are actually four problems with overloaded record update, not three as mentioned on the SORF page. This is an attempt to solve them. The SORF update mechanism. ------------------------------ SORF suggests adding a member set to the class Has which does the actual updating just as get does the selecting. So set :: Has r f t => t -> r -> r and r {n1 = x1, n2 = x2} is translated as set @ "n2" x2 (set @ "n1" x1) The Problems. ----------------- 1. It's not clear how to define set for virtual record selectors. For example, we might define data Complex = Complex {re :: Float, im :: Float} instance Has Complex "arg" Float where get r = atan2 r.im r.re but if we want to set "arg", what should be kept constant? The obvious answer is "mod", but we haven't even defined it, and there are plenty of cases where there is no obvious answer. 2. If the data type has one or more parameters, updates can change the type of the record. Set can never do this, because of its type. What is more, if several fields depend on the parameter, for example data Twice a = Twice {first :: a, second :: a} any update of "first" which changes the type must also update "second" at the same time to keep the type correct. No hacked version of set can do this. 3. The Haskel implementation of impredicative polymorphism (from the Boxy Types paper) isn't strong enough to cope with higher rank field types in instances of set. 4. The translation of multiple updates into multiple applications of set is not the same as the definition of updates in the Haskel report, where updates are simultaneous not sequential. This would be less efficient, and in the case of virtual record selectors, it wouldn't be equal, and is arguably incorrect. Point 3 could possibly be fixed by improving the strength of the type system, but SPJ says this is a hard problem, and no-one else seems ready to tackle it. Points 1, 2 & 4 suggest that any solution must deal not with individual fields but with sets of fields that can sensibly be updated together. The Proposed Solution. -------------------------- This is an extension to SORF. I don't know if the same approach could be applied to other label systems. 1. Introduce a new form of class declaration: class Rcls r where r {n1 :: t1, n2 :: t2} is translated as class (Has r n1 t1, Has r n2 t2) => Rcls r where setRcls :: t1 -> t2 -> r -> r setRcls is used internally but hidden from the user. 2. Instances of record classes can use a special form of default. So data Rec = Rec {n1 :: t1, n2 :: t2} instance Rcls Rec is translated as instance Rcls Rec where setRcls x1 y1 (Rec _ _) = Rec x1 y1 provided all the fields in the class occur in the data type with the correct types. In general, the definition of the update function is the same as the Haskel98 translation of update, solving problem 4. 3. The syntax of record updates must be changed to include the class: r {Rcls| n1 = x1, n2 = x2} is translated as setRcls x1 x2 r Updating a subset of the fields is allowed, so r {Rcls| n1 = x1} is translated as setRcls x1 (r.n2) r 4. Non default instances use the syntax: instance Rcls Rec where r {Rcls| n1 = x1, n2 = x2} = ...x1..x2.. which is translated as instance Rcls Rec where setRcls x1 y1 r = ...x1..x2.. in order to allow virtual selectors. This solves problem 1, because updates are grouped together in a meaningful way. An extended example is given below. 5. Record classes can have parameters, so class TwiceClass r where r a {first :: a, second :: a} data Twice a = Twice {first :: a, second :: a} instance TwiceClass Twice translates as class TwiceClass r where setTwiceClass :: a -> a -> r b -> r a data Twice a = Twice {first :: a, second :: a} instance TwiceClass Twice where setTwiceClass x y (Twice _ _) = Twice x y which allows updates to change the type correctly. This solves problem 2. 6. Problem 3 *almost* works. The translation of class HRClass r where r {rev :: forall a. [a] -> [a]} is class Has r "rev" (forall a. [a] -> [a]) => HRClass r where setHRClass :: (forall a.[a] -> [a]) -> r -> r which is fine as far as updating is concerned, but the context is not (currently) allowed by ghc. I have no idea whether allowing polymorphic types in contexts would be a hard problem for ghc or not. None of my attempted work-rounds have been entirely satisfactory, but I might have missed something. Comments ------------- 1. This makes the "special syntax for Has" pretty useless. When you have a set of labels you want to use together, you usually want to use update as well as selection, so it's better to define a record class, and use that. 2. The record classes can also be used for controlling the scope of polymorphic functions. For example, if you want to use a label "name" with the assumption that it refers to the name of a person, define a class class Person r where r {name :: String} and only create instances where the assumption is correct. Any functions polymorphic over the class Person can only be applied to instances you have declared. You can later use the same label for the name of a product class Product r where r {name :: String} but it's a different class with its own instances and the type checker will complain if you apply Person code to Product types. 3. It feels a bit odd to have the class which controls selection functions (Has) automatically defined, once for all, but the classes which control update functions must be defined by the programmer, and instances declared manually. However, I haven't found any way to make any kind of multiple Has class work. Example -------------- The following example illustrates some of the things that are possible with this approach. We want to represent complex numbers as pairs of Floats: data Complex1 = Complex1 {real :: Float, imag :: Float} in order to update records, we define a class: class Cartesian c where c {real :: Float, imag :: Float} instance Cartesian Complex1 but we also want to access complex numbers by modulus and argument, so we define virtual selectors: class Polar c where c {mod :: Float, arg :: Float} instance Has Complex1 "mod" Float where get (Complex1 x y) = sqrt (x * x + y * y) instance Has Complex1 "arg" Float where get (Complex1 x y) = atan2 y x instance Polar Complex1 where _ {Polar| mod = r, arg = th} = Complex1 (r * cos th) (r * sin th) Note that we can update x and y by {Cartesian| real = x, imag = y} or r and theta by {Polar| mod = r, arg = theta} but we cant mix them: there is no way to simultaneously update x and theta, unless we define a new class to do that. We can change the representation to cache mod and arg without changing the classes: data Complex2 = Complex2 {real :: Float, imag :: Float, mod :: Float, arg :: Float} now both update functions are virtual, though none of the selectors are: instance Cartesian Complex2 where _ {Cartesian| real = x, imag = y} = Complex2 x y (sqrt (x * x + y * y)) (atan2 y x) instance Polar Complex2 where _ {Polar| mod = r, arg = th} = Complex2 (r * cos th) (r * sin th) r th Alternatively, we might want to use whichever representation was last updated: data Complex3 = Complex3a {real :: Float, imag :: Float} | Complex3b {mod :: Float, arg :: Float} now everything is virtual: instance Has Complex3 "real" Float where get (Complex3a x y) = x get (Complex3b r th) = r * cos th instance Has Complex3 "imag" Float where get (Complex3a x y) = y get (Complex3b r th) = r * sin th instance Cartesian Complex3 where _ {Cartesian| real = x, imag = y} = Complex3a x y instance Has Complex3 "mod" Float where get (Complex3a x y) = sqrt (x * x + y * y) get (Complex3b r th) = r instance Has Complex3 "arg" Float where get (Complex3a x y) = atan2 y x get (Complex3b r th) = th instance Polar Complex3 where _ {Polar| mod = r, arg = th} = Complex3b r th Sorry this is so long! Barney.

3 9

Records in Haskell: Type-Indexed Records (another proposal)
by Matthew Farkas-Dyck 08 Mar '12

08 Mar '12

Hello all. I wrote a new proposal for the Haskell record system. It can be found at http://hackage.haskell.org/trac/ghc/wiki/Records/TypeIndexedRecords Records are indexed by arbitrary Haskell types. Scope is controlled as scope of key types. No fieldLabel declarations needed (as in DORF). Cheers, strake

2 4

Interpreting the strictness annotations output by ghc --show-iface
by Johan Tibell 08 Mar '12

08 Mar '12

Hi, If someone could clearly specify the exact interpretation of these LLSL(ULL) strictness/demand annotations shown by ghc --show-iface I'd like to try to write a little tool that highlights the function argument binding in an IDE (e.g. Emacs) with this information. Anyone care to explain the syntax? Cheers, Johan

5 15

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