December 2011 - Glasgow-haskell-users

build-depends
by Serge D. Mechveliani 22 Dec '11

22 Dec '11

Dear GHC team, ghc-7.4.0.20111219 puts the following problem of build-depends. docon.cabal of the DoCon project has build-depends: haskell2010, containers And ghc-7.4.0.20111219 reports DExport.hs:28:8: Could not find module `Random' It is a member of the hidden package `haskell98-2.0.0.1'. Perhaps you need to add `haskell98' to the build-depends in your .cabal file. Then, build-depends: haskell2010, haskell98, containers causes "Parse of field 'build-depends' failed". Then, build-depends: haskell98, containers causes VecMatr.hs:49:8: Could not find module `Data.List' It is a member of the hidden package `base'. Perhaps you need to add `base' to the build-depends in your .cabal file. It is a member of the hidden package `haskell2010-1.1.0.1'. Perhaps you need to add `haskell2010' to the build-depends in your .cabal file. Adding haskell2010 will cause "Parse of field 'build-depends' failed." Adding base will cause DExport.hs:26:8: Ambiguous module name `Prelude': it was found in multiple packages: base haskell98-2.0.0.1 Please, what is a reasonable way out ? Regards, ------ Sergei mechvel(a)botik.ru

3 3

Prelude in 7.4.0.20111219
by Serge D. Mechveliani 22 Dec '11

22 Dec '11

Dear GHC developers, This is on ghc-7.4.0.20111219. Compiling --------------------------------------------------- {-# OPTIONS -fno-warn-duplicate-exports #-} module DExport (module DPrelude, module Categs, module SetGroup, module RingModule, module Z, module DPair, module Fraction, module Permut, module VecMatr, module Pol, module Residue, module LinAlg, module GBasis, module Partition, module AlgSymmF, module Complex, module Prelude, module List, module Ratio, module Random ) where import Complex import List hiding (minimum, maximum, sort, sortBy) import Prelude hiding (minimum, maximum, ) import Ratio ... --------------------------------------------------- ghc-7.4.0.20111219 reports (unlike ghc-7.0.1): ---------------------- runghc Setup.hs build Building docon-2.12... Preprocessing library docon-2.12... DExport.hs:26:8: Ambiguous module name `Prelude': it was found in multiple packages: base haskell98-2.0.0.1 ---------------------- Please, what is the best way out? Regards, ------ Sergei mechvel(a)botik.ru

2 1

Erratic failure to specialize function
by Alexey Khudyakov 18 Dec '11

18 Dec '11

Hello! I've found a puzzling performance problem with code which uses vector library and relies heavily on GHC to perform inlining and specialization. In some cases compiler refuses to specialize function and just copies there generic version which is slow. Here is smallest test case I've manages to make: file 'test.hs' > import Criterion.Main > import qualified Data.Vector.Unboxed as U > import Boundary > > sample :: U.Vector Double > sample = U.replicate 10000 0 > > main = defaultMain > [ bench "eta" $ nf variance sample > , bench "lambda" $ nf (\x -> variance x) sample > ] file 'Boundary.hs' > {-# LANGUAGE FlexibleContexts #-} > module Boundary where > import qualified Data.Vector.Generic as G > > variance :: (G.Vector v Double) > => v Double -> Double > variance vec = G.sum vec > {-# INLINE variance #-} Here is benchmarking results: benchmarking eta - mean: 220.8042 us benchmarking lambda - mean: 24.31309 us If variance is moved to the test.hs file or eta reduced or written as lambda: varance = \vec -> G.sum vec difference goes away. What causes such behavior?

3 2

Proposal to incorporate Haskell.org
by Don Stewart 16 Dec '11

16 Dec '11

Hello everyone. The haskell.org committee[1], in the interest of the long-term stability of the open source Haskell community infrastructure, has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. The committee's proposal is that haskell.org incorporate as an entity under the Software Freedom Conservancy umbrella organization (the same group that Darcs joined recently): http://sfconservancy.org/ If we proceed with this move, haskell.org will be a legal entity, and registered as a non-profit, allowing us to more directly accept (US tax-deductible) donations, and to invest in assets that benefit the Haskell open source community. We welcome your feedback on the proposal attached below. -- Don Stewart (on behalf of the Haskell.org committee) ------------------------------------------------------------------------ = A proposal for the incorporation of Haskell.org = In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: in particular, on hosting haskell.org itself. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, haskell.org doesn't currently exist as a legal entity, meaning that these assets have had to be held on our behalf by other entities, such as Galois and various universities. This leads to tricky situations, with no-one being sure who should decide how the haskell.org assets can be used. To solve these problems, we propose that haskell.org applies to become a member project of the Software Freedom Conservancy (SFC) <http://conservancy.softwarefreedom.org/>. The SFC is a non-profit organization that provides free financial and administrative services to open source projects. Additionally, it has 501(c)(3) status, meaning donations from the US are tax-deductible. The SFC would hold haskell.org's money and other assets, and would be able to accept donations on behalf of haskell.org. The haskell.org committee, as described here [2], will make decisions on spending assets and other decisions related to governing the non-profit. Before proceeding, we are inviting input from the community in the form of specific objections or queries regarding the plan. We've tried to answer some of the most likely questions: Q: Does this mean that my Haskell project must now be covered by a copyleft licence such as GPL? A: No, but Haskell projects using haskell.org resource should use an Open Source licence <http://www.opensource.org/licenses/alphabetical>. Q: Will it still be possible to use community.h.o to host non-open-source material, such as academic papers? A: An overall minority of such content, as is the current situation, is not a problem. Q: Will it still be possible to have job ads on the haskell.org mailing lists and website? A: Yes. Q: Will this affect our ability to host the Haskell Symposium <http://www.haskell.org/haskell-symposium/> and Industrial Haskell Group<http://industry.haskell.org/> webpages within haskell.org? A: No. Q: What will be the relationship between haskell.org and other organizations such as the Haskell Symposium and Industrial Haskell Group? A: Those organisations will continue to exist as separate entities. Q: If an umbrella non-profit organisation "The Haskell Foundation" was created, would haskell.org be able to join it? A: Yes. It's likely that in such a scenario, the Haskell Foundation would become the owner of the haskell.org domain name, with the cost divided between the members. The entity that is part of the SFC would be renamed "community.haskell.org" in order to avoid confusion. [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation

4 5

Record update for Higher-ranked or changing type via Has/get/set [was: Records in Haskell]
by AntC 13 Dec '11

13 Dec '11

> Firstly, thank you to SPJ for putting some detailed design into 'Overloaded record fields' [SPJ 1]. What I'm showing here draws heavily on the techniques he demonstrates. I wasn't happy with several parts of the design proposal; especially not with the amount of not-yet-available type machinery it involved (explicit type application, anonymous types, the kind system, String types). But then SPJ wasn't happy himself with the limitations on Record update for polymorphic fields: "This problem seems to be a killer: if record-update syntax is interpreted as a call to `set', ...". It's (too) easy to chuck rocks - the "glaring weakness" of (Haskell's record system) is still a swamp despite a pile of rocks (to mix my metaphors). This posting (as a .lhs) is the result of exploring within the "narrow issue: namespacing for record field names". I've used GHC + recent type extensions (v7.2.1). Findings in short: - I've followed SPJ with a `Has' class, and methods `get' and `set'. - I seem to have a way to update Higher-ranked fields, - and change the type of the record, - and even update Existentially-quantified fields (to a limited extent) - which should please the object-oriented oriented. I'd appreciate some feedback: - Have I misunderstood the results? - Are there still unacceptable limitations? (Certainly the error messages are impenetrable when you go wrong.) - The `Has' class, instances and type functions are ugly - can we be more elegant? (I expect the instances to be generated systematically from the data decl. So usually the application programmer won't have to see them. I like SPJ's 'Syntactic sugar for Has' to pretty-up Has constraints.) Disclaimer: - I'm keeping close to SPJ's objective of improving the situation w.r.t. name clashes for record fields. [SPJ 2] - I'm _not_ claiming this is a design for 'first class record types' /extensible records/record polymorphism. - I'm _not_ making a proposal for 'Records in Haskell'. (Not yet: if this is approach is deemed 'workable', then I have a design in mind.) - I'm _not_ envisaging anything like 'first-class labels'. (I think that idea is probably not the right objective, but that's a debate for another day.) The basic idea: - Field selection uses dot notation as reverse-application, applying a field selector via Has/get and resolving the instance to the record type and field, that is: r.fld ==> fld r, ==> get (undefined :: Proxy_fld) (r@DCons{fld}) = fld (I've used (.$) = flip ($) to fake the syntax for dot notation.) - Record construction and pattern matching with explicit data constructors works as with -XDisambiguateRecordFields - Record update uses H98 syntax, to be compiled to Has/set and resolving the instance to the record type and field with explicit data constructor: r {fld = val} ==> set fld val (r@DCons{..}) ==> DCons{fld = val, ..} -- using Puns and WildCards (I've used (.=) = set to fake the syntax for update: r.$(fld.=val).) - Of course, I can't use the field name itself, because that would clash with the H98 selector. Instead: _fld = undefined :: Proxy_fld -- for the update syntax fld_ = get (undefined :: Proxy_fld) -- for the (overloadable) -- selector function The approach uses a 'loose coupling' between the type arguments of Has/get/set, with type functions to control the linkage. (Some could be Associated Types -- a matter of taste?) The recipe needs: > {-# OPTIONS_GHC -XDisambiguateRecordFields -XNamedFieldPuns -XRecordWildCards #-} > {-# OPTIONS_GHC -XTypeFamilies #-} > {-# OPTIONS_GHC -XRankNTypes -XImpredicativeTypes -XGADTs -XEmptyDataDecls #-} > {-# OPTIONS_GHC -XMultiParamTypeClasses -XFlexibleInstances -XUndecidableInstances #-} > module HasGetSet where SPJ's example of a higher-ranked data type -- imported so that we have clashing declarations of `rev' > import HRrev > {- data HR = HR {rev :: forall a.[a] -> [a]} -} > data Tab a b where -- a different data type with a HR field `rev' > Ta :: {tag :: String, rev :: forall a_.([a_] -> [a_]), flda :: a } > -> Tab a b > Tb :: (Num n, Show b) => {tag :: String, fldn :: n, fldnb :: n -> b} > -> Tab a b > -- Existential fields (GADT syntax) overloadable definitions for field `rev': > data Proxy_rev -- phantom, same role as SPJ's String kind "rev" > _rev = undefined :: Proxy_rev > rev_ r = get (undefined :: Proxy_rev) r build some syntax to fake the dot notation, and assignment within record update > (.$) = flip ($) > infixl 9 .$ >-- (fld .= val) r = set fld val r -- sadly, this doesn't quite work > infix 9 .= -- so define (.=) as a method in Has test rig for higher-rank rev, per SPJ's example, and demos > testrev r = (r.$rev_ $ [True, False, False], r.$rev_ $ "hello") > -- dot notation would bind tighter than func apply > rHR0 = HR{} -- `rev' is undefined, to show we can update it > rHR1 = rHR0.$(_rev.=reverse) -- equivalent to rHR0{rev = reverse} > -- testrev rHR1 ==> ([False,False,True],"olleh") > rHR2 = rHR1.$(_rev.=(drop 1 . reverse)) > -- testrev rHR2 ==> ([False,True],"lleh") > rTab0 = Ta{tag="tagged"} -- `rev' is undefined, to show we can update it > rTab1 = rTab0.$(_rev.=reverse) > -- testrev rTab1 ==> ([False,False,True],"olleh") > rTab2 = rTab1.$(_flda.='a').$(_rev.=(reverse . take 3)) > -- rTab1 :: Tab a b ; rTab2 :: Tab Char b > -- testrev rTab2 ==> ([False,False,True],"leh") here's the mechanism -- declarations for Has/get/set, and type families > class Has r fld t where > get :: fld -> r -> GetTy r fld t > set, (.=) :: fld -> (forall a_.SetTy r fld t a_) -> r -> SetrTy r fld t > -- (fld .= val) r = set fld val r -- } sadly, neither of these work > -- (.=) = set -- } (trying to define a default) > type family GetTy r fld t :: * -- the type to get at `fld' in `r' > type family SetTy r fld t a_ :: * -- type to set at `fld' in updated `r' > type family SetrTy r fld t :: * -- the type to set for updated `r' The instance for field `rev' to be a Higher-ranked type. > instance (t ~ ([a_]->[a_])) => Has HR Proxy_rev t where > -- the constraint needs -XUndecidableInstances > get _ HR{rev} = rev > set _ fn HR{..} = HR{rev = fn, ..} > (_ .= fn) HR{..} = HR{rev = fn, ..} > type instance GetTy r Proxy_rev t = t > -- that is ([a_] -> [a_]) from the instance constraint > type instance SetTy r Proxy_rev t a_ = ([a_] -> [a_]) > -- that is ([a_] -> [a_]) from `set's forall a_ > type instance SetrTy r Proxy_rev t = r > -- updating `rev' doesn't change the type the above type instances apply for any record with field `rev', so also type `Tab' > instance (t ~ ([a_]->[a_])) => Has (Tab a b) Proxy_rev t where > -- the constraint needs -XUndecidableInstances > get _ Ta{rev} = rev > set _ fn Ta{..} = Ta{rev = fn, ..} > (_ .= fn) Ta{..} = Ta{rev = fn, ..} > data Proxy_flda -- `flda's type is a parameter to the data type > _flda = undefined :: Proxy_flda > flda_ r = get (undefined :: Proxy_flda) r > instance Has (Tab a b) Proxy_flda t where -- note no constraint on `t', > -- might be different to `a' for update > get _ Ta{flda} = flda > set _ x Ta{..} = Ta{flda = x, ..} > (_ .= x) Ta{..} = Ta{flda = x, ..} > type instance GetTy (Tab a b) Proxy_flda t = a > -- this is where we constrain `t' for the get > type instance SetTy (Tab a b) Proxy_flda t a_ = t -- type to set is whatever we're given > type instance SetrTy (Tab a b) Proxy_flda t = Tab t b -- set the result type: substitute `t' for `a' and Has/get/set for the other fields of Tab, including the Existential > data Proxy_tag > _tag = undefined :: Proxy_tag > tag_ r = get (undefined :: Proxy_tag) r > instance (t ~ String) => Has (Tab a b) Proxy_tag t where > -- constraint on `t', because tag is always a String > get _ Ta{tag} = tag > get _ Tb{tag} = tag > set _ x Ta{..} = Ta{tag = x, ..} > set _ x Tb{..} = Tb{tag = x, ..} > (_ .= x) Ta{..} = Ta{tag = x, ..} > (_ .= x) Tb{..} = Tb{tag = x, ..} > type instance GetTy (Tab a b) Proxy_tag t = String > type instance SetTy (Tab a b) Proxy_tag t a_ = String > type instance SetrTy (Tab a b) Proxy_tag t = Tab a b > -- changing the tag doesn't change the record's type > data Proxy_fldn -- } the Existential fields must be set together > data Proxy_fldnb -- } possible approach for multiple update > _fldn = undefined :: Proxy_fldn > _fldnb = undefined :: Proxy_fldnb > -- no point in a 'getter' function: the types would escape > instance (t ~ (tn, tn -> b'), Show b', Num tn) > -- needs -XUndecidableInstances > => Has (Tab a b) (Proxy_fldn, Proxy_fldnb) t where > -- the use case is: r{fldn = n, fldnb = nb} > -- get _ Tb{fldn, fldnb} = (fldn, fldnb) -- No! types would escape > set _ (n, nb) Tb{..} = Tb{fldn = n, fldnb = nb, ..} > (_ .= (n, nb)) Tb{..} = Tb{fldn = n, fldnb = nb, ..} > type instance GetTy (Tab a b) (Proxy_fldn, Proxy_fldnb) t = t > -- that is: (tn, tn -> b') from the instance constraint > type instance SetTy (Tab a b) (Proxy_fldn, Proxy_fldnb) t a_ = t > type instance SetrTy (Tab a b) (Proxy_fldn, Proxy_fldnb) (tn, tn -> b') > = Tab a b' > -- changing the fields changes the type demo > nb' Tb{fldn, fldnb} = fldnb fldn -- test rig > rTab3 = Tb{tag="tagged", fldn = 6 :: Double, fldnb = negate} > -- nb' rTab3 ==> -6.0 :: Double > rTab4 = rTab3.$((_fldn, _fldnb).=(5::Int, (6 +))) > -- rTab3{fldn = 5, fldnb = (6 +)} > -- nb' rTab4 ==> 11 :: Int Notes/difficulties: - Language options needs -XUndecidableInstances because the approach "uses a functional-dependency-like mechanism (but using equalities)" [SPJ 1] to 'improve' type inference for some instances. Since this _doesn't_ use FunDeps, can it safely exceed Paterson Conditions? - The inability to declare (.=) = set is curious/irritating. (Neither as a free-standing function, nor a method of Has with a default implementation. And even declaring (.=) with a type signature identical to `set'. From the error messages, GHC can't match the forall'd `a_'.) If you've managed to read this far: thank you! Refs: [SPJ 1] http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [SPJ 2] http://hackage.haskell.org/trac/ghc/wiki/Records

1 0

Revert a CAF?
by wren ng thornton 09 Dec '11

09 Dec '11

So, I have an optimization/internals question. Does the GHC API have any hooks for being able to revert a CAF to the original expression, thus discarding the previously computed result? The reason I'm wanting this is that I have a particular CAF which is an infinite list. Unfolding that list takes a fair deal of work, so we want to share it whenever possible; however it doesn't take an overwhelming amount of work, so if we know we've evaluated more of the list than necessary (for a long while), it'd be nice to be able to revert the evaluation in order to save on memory overhead (e.g., by calling relax :: IO()). I could hack something together based on unsafePerformIO and top-level IORefs, and it's clear that this is in fact a safe thing to do, but I'm worried about the semantic issues inherent in unsafePerformIOed top-level IORefs (e.g., the fact that their scope isn't particularly well defined: is it per library instance? per runtime?...). Unfortunately, for what I'm doing, it isn't really feasible to just leave the IO type in there nor to pass around the infinite list so we can use scoping rules to decide when to free it. (Feel free to offer alternative suggestions to handling this situation too.) -- Live well, ~wren

5 6

Superclass Cycle via Associated Type
by Nicolas Frisby 07 Dec '11

07 Dec '11

(Sorry I'm so late to this dialogue.) In http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020593.html, SPJ asks > The superclasses are recursive but > a) They constrain only type variables > b) The variables in the superclass context are all > mentioned in the head. In class Q => C a b c > fv(Q) is subset of {a,b,c} > > Question to all: is that enough? I just recently came upon my own desire for this capability, but I'm pretty sure my reply to SPJ's question is "No." I'd like to extend Sat's modeling capabilities to also cover superclass constraints. > type family Super a > class Sat (Super a) => Sat a where dict :: a This seems to necessitate recursive dictionaries — I'm not familiar enough with the dictionary-implementation details to understand how much of an understatement that might be. All I can say is that my own intuitions about those things don't yet deem this technique infeasible. Let's take a reification of Ord as an example. > data EmptyD a = EmptyD > type instance Super (EmptyD a) = EmptyD a > instance Sat (EmptyD a) where dict = EmptyD > > data EqD a where EqD :: Eq a => EqD a > type instance Super (EqD a) = EmptyD a > instance Eq a => Sat (EqD a) where dict = EqD > > data OrdD a where OrdD :: Ord a => OrdD a > type instance Super (OrdD a) = EqD a > instance Ord a => Sat (OrdD a) where dict = OrdD Now GHC can derive Sat (EqD a) from Sat (OrdD a). I'd bet this could be cleaned via Constraint Kinds [1] — if not totally subsumed by them: > type family Super a :: Constraint > class Super a => Sat a where dict :: a > > data OrdD a where OrdD :: Ord a => OrdD a > type instance Super (OrdD a) = Ord a > instance Ord a => Sat (OrdD a) where dict = OrdD With these definitions, there'd be an isomorphism between Sat (OrdD a) and Ord a. I don't know how difficult it would be for GHC to wield that isomorphism. At this point, though, perhaps Constraint Kinds simply deprecate Sat? [1] does, after all, define "one reified dictionary to rule them all". ----- [1] - http://blog.omega-prime.co.uk/?p=127

1 0

GHC HEAD build error
by Bas van Dijk 07 Dec '11

07 Dec '11

Hello, I'm trying to build GHC HEAD but get the following error: "inplace/bin/ghc-stage1" -H64m -O0 -fasm -Iincludes -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -optc-O2 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o rts/HeapStackCheck.cmm:159:305: parse error on input `(' The bug is in the GC_GENERIC macro on line 99: Capability_interrupt(MyCapability()) != 0 :: CInt However, I can't spot the problem. Bas

3 3

Re: [Haskell-cafe] More liberal than liberal type synonyms
by Dan Doel 07 Dec '11

07 Dec '11

On Wed, Dec 7, 2011 at 5:48 AM, Dmitry Kulagin <dmitry.kulagin(a)gmail.com> wrote: > I am still pretty new in Haskell, but this problem annoys me already. > > If I define certain monad as a type synonym: > > type StateA a = StateT SomeState SomeMonad a > > Then I can't declare new monad based on the synonym: > > type StateB a = StateT SomeOtherState StateA a > > The only way I know to overcome is to declare StateA without `a': > > type StateA = StateT SomeState SomeMonad > > But it is not always possible with existing code base. I'm afraid my proposal doesn't make this work. You could perhaps define StateB, but when you expand in a type you get: StateB a = StateT SomeOtherState StateA a which has a partially applied StateA, and is rejected. The only way to make this work is to eta reduce StateA manually, or make GHC recognize when a synonym can be eta reduced in this way (which might be both possible and useful as a separate proposal). My extension fell within the liberal type synonym space, which says that if you have: F G where F and G are both synonyms, and G is partially applied, then it is okay as long as expansion of F (and any subsequent expansions) cause G to become fully applied. My extension of this is just to allow partial application inside aliases as long as it meets these same criteria. The reason to disallow partially applied type aliases is that they make inference pretty much impossible, unless you only infer them in very limited circumstances perhaps. And if you can't get inference of them, you probably need to start having explicit annotations to tell the type checker what you want to happen, which has some of its own complications with the way quantifiers work in GHC and such. It'd cascade into some thorny issues. Hopefully that covers all the other subsequent stuff folks have been talking about. -- Dan

1 0

More liberal than liberal type synonyms
by Dan Doel 06 Dec '11

06 Dec '11

Greetings, In the process of working on a Haskell-alike language recently, Ed Kmett and I realized that we had (without really thinking about it) implemented type synonyms that are a bit more liberal than GHC's. With LiberalTypeSynonyms enabled, GHC allows: type Foo a b = b -> a type Bar f = f String Int baz :: Bar Foo baz = show because Bar expands to saturate Foo. However, we had also implemented the following, which fails in GHC: type Foo a b = b -> a type Bar f = f (Foo Int) (Foo Int) type Baz f g = f Int -> g Int quux :: Bar Baz quux = id That is: type synonyms are allowed to be partially applied within other type synonyms, as long as similar transitive saturation guarantees are met during their use. I don't know how useful it is, but I was curious if anyone can see anything wrong with allowing this (it seems okay to me after a little thought), and thought I'd float the idea out to the GHC developers, in case they're interested in picking it up. -- Dan

1 0