- Haskell-Cafe - Haskell.org

Type class for sequences with dependent types
by Robbert Krebbers 06 Jan '12

06 Jan '12

Hello, in a Haskell development I have to represent paths that have elements of alternating types. GADTs allow me to do this easily: data AltList :: * -> * -> * where Nil :: AltList a a ICons :: Int -> AltList Int b -> AltList () b UCons :: () -> AltList () b -> AltList Int b Since I have various kinds of these data structures I defined a type class for common operations on such data structures. class DepSequence l where nil :: l a a app :: l a b -> l b c -> l a c The instance for AltList is as follows: instance DepSequence AltList where nil = Nil Nil `app` k = k ICons i l `app` k = ICons i (l `app` k) UCons i l `app` k = UCons i (l `app` k) This all works nicely, however, I also want ordinary lists to be an instance of this class too. I tried the following: type IntListAlt a b = [Int] instance DepSequence IntListAlt where nil = [] app = (++) But GHC does not like this, it yields: Type synonym `IntListAlt' should have 2 arguments, but has been given none In the instance declaration for `DepList IntListAlt' The following alternative works, but it is quite ugly newtype IntList a b = IntList { getList :: [Int] } instance DepSequence IntList where nil = IntList [] app l k = IntList (getList l ++ getList k) and also does not give me a nil of type [Int] and an app of type [Int] -> [Int] -> [Int]. Does anyone know whether Haskell allows me to do this in a better way? Best, Robbert

3 3

Sudden monomorphism with -XTypeFamilies
by Rian Hunter 06 Jan '12

06 Jan '12

hello i'm getting inconsistent monomorphism behavior with the same code only depending on whether or not -XTypeFamilies is enabled: ---- {-# LANGUAGE TypeFamilies #-} snda :: a -> b -> b snda ba = id main = do let ma = (return () :: IO ()) mBox bb = snda ma bb mBox $ return (4 :: Int) mBox $ return "G" return () ---- in the preceding example, if -XTypeFamilies is enabled then "mBox" is monomorphic and the program will terminate early, otherwise, it's polymorphic and the program will complete successfully. i think i understand why this is the case but i couldn't find documentation on this inconsistency anywhere. is this expected behavior or is this a bug in GHC? thanks! rian

2 1

Re: [Haskell-cafe] Package Versioning Policy
by Christoph Breitkopf 06 Jan '12

06 Jan '12

Forgot the header, sorry. On Thu, Jan 5, 2012 at 5:54 PM, Christoph Breitkopf < chbreitkopf(a)googlemail.com> wrote: > Hello, > > I'm trying to figure out how to handle versioning of my IntervalMap > package. I've just read the package versioning policy: > http://www.haskell.org/haskellwiki/Package_versioning_policy > > I don't quite understand all the recommendations in the above document, > though: > > a) You are not allowed to remove or change the types of existing stuff. Ok. > > b) You are allowed to add new functions. But that can break compilation > because of name conflicts. Seems to be allowed on the grounds that this is > easy to fix in the client code. > > c) You are not allowed to add new instances. I don't get this - how is > this any worse than b)? > > I do understand that it is not generally possible to prevent breaking code > - for example if the client code depends on buggy behavior that gets fixed > in a minor version update. That seems unavoidable - after all, bugfixes are > _the_ reason for minor updates. > > Regards, > > Chris > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

3 6

Get a variable's type in quasiquote
by Jonathan Geddes 06 Jan '12

06 Jan '12

Cafe, I'm playing around with Template Haskell, specifically QuasiQuotes and I've run into something that I hope is not an inherent limitation in TH. Specifically I want to get the type of a variable whose name is used in a QuasiQuote. The code generated by the QQ should depend on the type of the variables that are to be antiquoted. For example let a = True in [qq | a |] should result in different code being generated by the qq than let a = 42 in [qq | a |] because the type of variable "a" is different. So far I've tried simple reification, but > quote = do >let varname = "someVariableKnownToExist" info <- reify $ mkName str

1 1

Versioning policy and dependencies
by Magnus Therning 06 Jan '12

06 Jan '12

Lately I've often thought that the versioning policy only addresses half of the problem: the API. While it completely neglects the "other side" of the package surface: the dependencies. I should probably mention that this springs from my work with packaging Haskell for ArchLinux and to be honest I'm not sure it's a worthwhile goal for the community to put much work into simplifying the work of distro packagers. Anyway, I think it is worthwhile thinking about and explicitly stating what the goals and non-goals of the versioning policy are. If the following statement would hold, then my work would become a bit easier: If I have a set of packages where all dependencies are satisfied, then it should be possible to update any of those packages to a new minor version (e.g. from X.Y.Z to X.Y.Z+1) without any further updates. I believe the following rules would help achieving that: - Use dependencies that are insensitive to changes in minor versions as far as possible. - Increase the major version if the lower bound of a dependency is adjusted up to a new major version. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

1 0

(no subject)
by Christoph Breitkopf 06 Jan '12

06 Jan '12

Hello, I'm trying to figure out how to handle versioning of my IntervalMap package. I've just read the package versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy I don't quite understand all the recommendations in the above document, though: a) You are not allowed to remove or change the types of existing stuff. Ok. b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code. c) You are not allowed to add new instances. I don't get this - how is this any worse than b)? I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates. Regards, Chris

2 1

Re: [Haskell-cafe] [Haskell-beginners] WinRT and Haskell
by Antoine Latter 05 Jan '12

05 Jan '12

On Thu, Jan 5, 2012 at 9:55 AM, AbdulSattar Mohammed <codingtales(a)gmail.com> wrote: > WinRT has a concept of projections that expose its API. Microsoft has > implemented projections for Native (C and C++), HTML/Javascript and .NET > (from Miguel de Caza's WinRT demystified > post: http://tirania.org/blog/archive/2011/Sep-15.html) There's no mention > of creating your own projections (or I have seen none). I don't see any > reason why we can't create our own projections. If it's possible a Haskell > projection could really help. > Yep, that's what I was thinking of. I'm pretty sure the C/C++ projections rely on compiler extensions for the MS C/C++ compiler, so I don't think we could use those directly from Haskell. Antoine > > On Thu, Jan 5, 2012 at 8:11 PM, Antoine Latter <aslatter(a)gmail.com> wrote: >> >> On Thu, Jan 5, 2012 at 5:12 AM, AbdulSattar Mohammed >> <codingtales(a)gmail.com> wrote: >> > I suppose this should go into the GUI mailing list, but it is filled >> > with >> > spam. So, WinRT does not depend on the .NET Framework. C++ applications >> > can >> > directly compile to x86 and be able to use WinRT. Do we have a room for >> > Haskell development there? >> > >> >> From what I understand, WinRT is a set of COM libraries - C++ can >> directly compile to it because the MS C++ compiler has special >> extensions to handle the COM resources in the library. >> >> There is a COM library for Haskell: >> >> http://hackage.haskell.org/package/com >> >> But I've never used it. >> >> The API is encoded in a special meta-data format, which is then used >> by C++, .NET and Javascript to create the language-specific APIs - it >> might be possible to generate Haskell bindings to the COM components >> from this metadata. >> >> Antoine > > > > > -- > Warm Regards, > > AbdulSattar Mohammed

1 0

Solved but strange error in type inference
by AUGER Cédric 05 Jan '12

05 Jan '12

Hi all, I am an Haskell newbie; can someone explain me why there is no reported error in @legSome@ but there is one in @legSomeb@ (I used leksah as an IDE, and my compiler is: $ ghc -v Glasgow Haskell Compiler, Version 7.2.1, stage 2 booted by GHC version 6.12.3 ) What I do not understand is that the only difference was a typing anotation to help the type inference, but I believed that this annotation was already given by the signature I give, so I am quite lost. Thanks in advance! ====================================================================== {-# OPTIONS_GHC -XScopedTypeVariables #-} -- why isn't this option always enabled... {-# OPTIONS_GHC -XGADTs #-} import Data.Word import qualified Data.Map as M import qualified Data.Set as S data Symbols nt t = NT nt -- ^ non terminal | T t -- ^ terminal deriving (Eq, Ord) type Sem s = [s]->s data Rule nt t s = Rule { refined :: nt , expression :: [Symbols nt t] , emit :: Sem s } type RRule nt t s = ([Symbols nt t], Sem s) data LegGram nt t s = Ord nt => LegGram (M.Map nt [RRule nt t s]) legSome :: LegGram nt t s -> nt -> Either String ([t], s) -- ^^^^^^^^^^^^^^ -- isn't this redundant? -- vvvvvvvvvvvvvv legSome ((LegGram g)::LegGram nt t s) ntV = case M.lookup ntV g of Nothing -> Left "No word accepted!" Just l -> let sg = legSome (LegGram (M.delete ntV g)) subsome :: [RRule nt t s] -> Either String ([t], s) subsome [] = Left "No word accepted!" subsome ((r,sem):l) = let makeWord [] = Right ([],[]) makeWord ((NT nnt):ll) = do (m, ss) <- sg nnt (mm, sss) <- makeWord ll return (m++mm, ss:sss) makeWord ((T tt):ll) = do (mm, sss) <- makeWord ll return (tt:mm, sss) in case makeWord r of Right (ll, mm) -> Right (ll, sem mm) Left err -> subsome l in subsome l legSomeb :: LegGram nt t s -> nt -> Either String ([t], s) -- but without it I have an error reported legSomeb (LegGram g) ntV = case M.lookup ntV g of Nothing -> Left "No word accepted!" Just l -> let sg = legSomeb (LegGram (M.delete ntV g)) subsome :: [RRule nt t s] -> Either String ([t], s) subsome [] = Left "No word accepted!" subsome ((r,sem):l) = let makeWord [] = Right ([],[]) makeWord ((NT nnt):ll) = do (m, ss) <- sg nnt (mm, sss) <- makeWord ll return (m++mm, ss:sss) makeWord ((T tt):ll) = do (mm, sss) <- makeWord ll return (tt:mm, sss) in case makeWord r of Right (ll, mm) -> Right (ll, sem mm) Left err -> subsome l in subsome l

8 45

buildDepends syntax and checks
by Shakthi Kannan 05 Jan '12

05 Jan '12

Hi, #1 I would like to know if there is any context grammar or syntax for the package dependencies that are allowed in buildDepends in each .cabal file? AnyVersion and WildcardVersion are consistent. But, I see quite a bit of variations in what is included in UnionVersionRange and IntersectVersionRange. For example: * Two WildcardVersions in a UnionVersionRange (fixed-point 0.5.0.1) [1] * UnionVersionRange and WildcardVersion in a IntersectVersionRange (hlint 1.6.12) [2] #2 Is there a way to cross-check if the defined dependencies are in fact correct, or is it left to the package owner to write them? #3 Some dependencies have an 'or' for the same package (bytestring 0.9) [3], like "base (<3) or array, base (≥3)", and the cabal file says: library if flag(split-base) build-depends: base >= 3, array else build-depends: base < 3 I use the a script [4] to convert the .cabal files to .json, then the .json lists both the build-depends! Appreciate any inputs in this regard! Thanks! SK [1] fixed-point 0.5.0.1 (see base). http://hackage.haskell.org/packages/archive/fixed-point/0.5.0.1/fixed-point… [2] hlint 1.6.12 (see uniplate). http://hackage.haskell.org/packages/archive/hlint/1.6.12/hlint.cabal [3] bytestring 0.9. http://hackage.haskell.org/package/bytestring-0.9 [4] Cabal2json.hs. http://shakthimaan.fedorapeople.org/SOURCES/Cabal2json.hs -- Shakthi Kannan http://www.shakthimaan.com

2 1

Composing analyses.
by Serguey Zefirov 05 Jan '12

05 Jan '12

I am trying to create a stack of analyses. There are basic analyses then there are derived analyses that create a DAG of analyses. I thought I can express their relationship through type classes, but I failed. I've attached the source of my failure. Main points are below: getAnalysisResult :: EnabledAnalysis a as => a -> M as Int getAnalysisResult _ = error "getAnalysisResult!!!" setAnalysisResult :: EnabledAnalysis a as => a -> Int -> M as () setAnalysisResult _ _ = error "setAnalysisResult!!!" -- |Analysis interface. What to require and what to perform. class (Analyses (RequiresAnalyses a)) => Analysis a where -- |What has to be done before our pass. type RequiresAnalyses a -- |Perform an analysis. perform :: (EnabledAnalysis a as, EnabledAnalyses (RequiresAnalyses a) as) => a -> M as () data AnalysisNotEnabled a -- |Check if analysis is enabled. class EnabledAnalysis a as instance (FAIL (AnalysisNotEnabled a)) => EnabledAnalysis a Nil instance (Analysis a, Analyses as) => EnabledAnalysis a (a :. as) instance (Analysis a, Analysis a', EnabledAnalysis a as) => EnabledAnalysis a (a' :. as) -- |Check if a group of analyses is enabled. class EnabledAnalyses as eas instance EnabledAnalyses Nil eas instance (EnabledAnalyses as eas, EnabledAnalysis a eas) => EnabledAnalyses (a :. as) eas -- Base analysis. data Base = Base instance Analysis Base where type RequiresAnalyses Base = Nil perform a = do x <- getAnalysisResult a setAnalysisResult a (x+1) -- And analysis derived from Base. data Derived = Derived instance Analysis Derived where type RequiresAnalyses Derived = Base :. Nil -- !!! this is the source of problems -- the type here is -- (EnabledAnalysis Derived as, EnabledAnalyses (Base :. Nil) as) => -- Derived -> M as () -- Looks like ghc does not expand RequiresAnalyses Derived. perform a = do x <- getAnalysisResult a y <- getAnalysisResult Base setAnalysisResult a (x+y) -- here I expanded RequiresAnalysis Derived manually. -- ghc thinks that "EnabledAnalyses (Base :. Nil) as" does not imply "EnableAnalysis Base as". -- it is weird. performDerived :: (EnabledAnalysis Derived as, EnabledAnalyses (Base :. Nil) as) => Derived -> M as () performDerived a = do x <- getAnalysisResult a y <- getAnalysisResult Base setAnalysisResult a (x+y) This is behavior of ghc 6.12.1, 7.0.4 and 7.2.1. Is it right behavior? The main question is: is it possible to combine computations like this? How should one do this? I thinking about abandoning type classes altogether. I think I can do it some other way. But out of curiosity - why is that?

1 0