- Glasgow-haskell-users

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
by Joachim Breitner 24 Dec '11

24 Dec '11

Hi, Am Samstag, den 24.12.2011, 08:28 +1100 schrieb Erik de Castro Lopo: > Joachim Breitner wrote: > > > ghc-stage2: panic! (the 'impossible' happened) > > (GHC version 7.4.0.20111219 for powerpc-unknown-linux): > > Cant do annotations without GHCi > > {libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} > > base:GHC.Exts.ForceSpecConstr{d rbL} > > Thats related to the problem of GHCi being broken on powerpc. Somewhat: vector uses annotations, annotation need GHCi, GHCi is disabled (because broken) on powerpc, vector is bundled by accident in GHC (and will be removed in the final release, unless I am mistaken), and the real vector package is patched in Debian to handle this (http://patch-tracker.debian.org/patch/series/view/haskell-vector/0.9-2/no_a…) My hope is that ghc will in the future ignore annotations on non-GHCi-arches (http://hackage.haskell.org/trac/ghc/ticket/4268) Once vector is unbundled, I expect the build to succeed on powerpc. I guess the other weird-arch builds would have failed at this point as well, if they had not failed due to the various other reasons earlier; I hope these get fixed in the final release. Maybe Debian should offer GHC to run buildbots (http://hackage.haskell.org/trac/ghc/wiki/Builder) on at least some of our weird arch machines, so that these problems will be noticed. earlier. But I’m not sure if the DSA team allows such a thing, as we’d be running code that is not under our control. Is someone in the Haskell team interested in finding that out? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Show and Integral
by Serge D. Mechveliani 23 Dec '11

23 Dec '11

Sorry, I have forgotten to copy to the List my last note on this subject. The on-line spec of Haskell-2010 shows Eq Show \ / Num | Real | Integral Hence, for x :: Integral a => a, it is correct to apply (show x). And ghc-7.4.0.20111219 does not allow this (show x). So, it breaks the standard, and people say, this is deliberate. I witness such a break for the first time, and this looks so strange! Well, I also diskile the edge Show / Num in the standard. But it is better to implement Show as dummy for appropriate types, -- so far, -- and to wait for the next standard. Am I missing something? Regards, ------ Sergei mechvel(a)botik.ru

1 0

Re: Unit unboxed tuples
by Christian Höner zu Siederdissen 23 Dec '11

23 Dec '11

Hi, I have to second that. I recently "fell" over that problem when writing instances for certain kinds of tuples. In libraries, such as "tuple" there is a special 'OneTuple' constructor but I'd really appreciate a more uniform fix -- but don't know of one either... Gruss, Christian * Ganesh Sittampalam <ganesh(a)earth.li> [23.12.2011 15:39]: > On 23/12/2011 13:46, Ian Lynagh wrote: > > On Fri, Dec 23, 2011 at 01:34:49PM +0000, Simon Peyton-Jones wrote: > >> > >> Arguments Boxed Unboxed > >> 3 ( , , ) (# , , #) > >> 2 ( , ) (# , #) > >> 1 > >> 0 () (# #) > >> > >> Simple, uniform. > > > > Uniform horizontally, but strange vertically! > > It's worth mentioning that if you want to write code that's generic over > tuples in some way, the absence of a case for singletons is actually a > bit annoying - you end up adding something like a One constructor to > paper over the gap. But I can't think of any nice syntax for that case > either. > > Cheers, > > Ganesh > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

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