- Haskell-Cafe - Haskell.org

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

05 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 05 Jan '12

05 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 05 Jan '12

05 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 04 Jan '12

04 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

Re: [Haskell-cafe] Solved but strange error in type inference
by oleg＠okmij.org 04 Jan '12

04 Jan '12

One should keep in mind the distinction between schematic variables (which participate in unification) and universally quantified variables. Let's look at the forall-elimination rule G |- e : forall a. A -------------------- E G |- e : A[a := t] If the term e has the type forall a. A, we can use the term at some specific type t. Often the type checker doesn't know which specific type t to choose. Therefore, the type checker inserts a schematic type variable X (think of Prolog logic variable), to defer the decision. Further down the type-checking road, more information becomes available and it will become clear what concrete type t to use. Like in Prolog, a logic variable denotes a guess, or a promise, to be forced later (there is a deep connection between laziness and logic variables). So, the forall-elimination rule becomes G |- e : forall a. A -------------------- E G |- e : A[a := X] Let's look at the forall-introduction rule G |- e : A [a := aeigen] -------------------- I where aeigen \not\in G G |- e : forall a. A To type-check that a term e has a polymorphic type (which happens when the user gave a type signatures which contains type variables, implicitly quantified), the type-checker generates a fresh, unique _constant_ (called eigenvariable) and type-checks the term with the constant substituted for the type variable. If the term type-checks, it does have the polymorphic type. (One may ask why this fresh constant is called eigen_variable_ if it doesn't actually vary. That is a very good question, answered in http://okmij.org/ftp/formalizations/inductive-definitions.html#eigenvariabl… ). GHC calls these eigenvariable rigid variables. The upshot: eigenvariabes are constants and can't be changed by unification. Schematic variables are variables and can be substituted by unification. Quantified type variables are replaced by schematic variables when _using_ a polymorphic term. Quantified type variables are replaced by constants (or, rigid variables) when _type-checking_ a term. The earlier example: f :: a -> a f x = x :: a can be alpha-converted [recall, ScopedTypeVariable extension is off] as f :: a -> a f x = x :: b First the type-checker generates beigen. To check if 'f' can indeed be given the type signature a -> a, GHC generates the eigenvariable aeigen and type-checks (\x::aeigen -> x :: beigen) :: aeigen The problem becomes obvious. The error message is very precise, describing the precise location where type variables are bound. Couldn't match type `a' with `b' `a' is a rigid type variable bound by the type signature for f :: a -> a at /tmp/e.hs:2:1 `b' is a rigid type variable bound by an expression type signature: b at /tmp/e.hs:2:7 In the expression: x :: b In an equation for `f': f x = x :: b Again, read `rigid type variable' as eigen-variable. In OCaml, type variables are schematic variables (in many contexts). For example: # let f1 (x:'a) = (x:'b);; val f1 : 'a -> 'a = <fun> # let f2 (x:'a) = x + 1;; val f2 : int -> int = <fun> The function f2 is not polymorphic at all, although it may appear so from the use of the type variable 'a. But in other contexts OCaml does work like GHC: # module F : sig val f5 : 'a -> 'a end = struct let f5 x = x + 1 end;; Error: Signature mismatch: Modules do not match: sig val f5 : int -> int end is not included in sig val f5 : 'a -> 'a end Values do not match: val f5 : int -> int is not included in val f5 : 'a -> 'a Further, OCaml has now a specific construct to introduce rigid type variables (which appear as type constants). # let f4 (type a) (x:a) = (x:a) + 1;; Characters 25-26: let f4 (type a) (x:a) = (x:a) + 1;; ^ Error: This expression has type a but an expression was expected of type int

1 0

GHC compilation issue: Working around bug #4374?
by Sanket Agrawal 03 Jan '12

03 Jan '12

I am getting the compilation error below when building GHC 7.0.4 on RHEL5 (x86_64) – I configured make to point to ncurses and libgmp. I will appreciated pointers on how to work around the issue below. I don’t have root privileges. My apologies if this has already been discussed in this forum. I searched for the issue but could find only the GHC bug ticket below. GHC bug ticket: http://hackage.haskell.org/trac/ghc/ticket/4374 - it doesn’t have description on how to work around the bug. Compilation error: ----------------------- $ C_INCLUDE_PATH=/efs/dist/fsf/ncurses/5.6/common/include/ncurses:/home/saagrawa/scripts/misc/libgmp/include LIBRARY_PATH=/efs/dist/fsf/ncurses/5.6/exec/lib:/home/saagrawa/scripts/misc/libgmp/lib make ===--- updating makefiles phase 0 make -r --no-print-directory -f ghc.mk phase=0 just-makefiles ===--- updating makefiles phase 1 make -r --no-print-directory -f ghc.mk phase=1 just-makefiles ===--- updating makefiles phase 2 make -r --no-print-directory -f ghc.mk phase=2 just-makefiles ===--- updating makefiles phase 3 make -r --no-print-directory -f ghc.mk phase=3 just-makefiles ===--- finished updating makefiles make -r --no-print-directory -f ghc.mk all "inplace/bin/ghc-stage1" libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o `/usr/bin/find libraries/integer-gmp/dist-install/build -name "*_stub.dyn_o" -print` -shared -dynamic -dynload deploy -dylib-install-name /home/saagrawa/scripts/misc/ghc/7.0.4/lib/ghc-7.0.4/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so"` -no-auto-link-packages -package ghc-prim-0.2.0.0 -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so /efs/dist/fsf/gcc/4.4.3-build004/.exec/x86-64.rhel.5/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so] Error 1 make: *** [all] Error 2 $ ll /home/saagrawa/scripts/misc/libgmp/lib|awk '{print $9,$10,$11}' ### the libgmp lib folder has dynamic libraries libgmp.so.3.5.2* libgmp.so.3 -> libgmp.so.3.5.2* libgmp.so -> libgmp.so.3.5.2* libgmp.la* libgmp.a

1 1

Re: [Haskell-cafe] Experiments in Haskell Packaging
by Chris Dornan 03 Jan '12

03 Jan '12

Hi Ryan, Ryan Grant [mailto:rgrant@rgrant.org] said: > Are packages cabal-installed using --global? The packages that come with a compiler or Haskell Platform are installed --global. Every other package is installed with cabal, by default into the user's space. > Is it mostly reliant on cabal or cabal-dev? It works with cabal. I have not tested interworking with cabal-dev yet. (There is a big overlap in the functionality of course.) > How easily can I upgrade cabal? > http://stackoverflow.com/questions/5380888/cabal-install-and-debian The stackoverflow discussion seems a little confused in that 'cabal update' just updates the local cache of package headers from the server, not any of the installed packages. But I am using the latest version of cabal-install (0.10.2), compiled with cabal-1.10.1.0 library (from March rather than June's cabal-1.10.2.0). Users should never have to build their own cabal-install, but just keep up to date with the distro. If users should need to use their own private Cabal builds for whatever reason we will provide a wiki page showing them how to do it. > Can the idea be extended to OSX, as well? I see no reason why not. The idea behind my post was really to say that we should be doing this with all distros. I will be making the hub sources available through hackage/github when beta testing is complete (but sooner if demand dictates). Folks can install it on their own systems and hook in their own GHC and HP builds. Best of all folks can make it available in other Haskell distros. The interesting question is whether anyone else decides to structure their distros in the same way as the justhub distro. That is the real challenge! > How does this strategy relate to the Nix package manager? > http://nixos.org/nix/ In a sense the philosophy is similar because I am arguing that we shouldn't be updating distributions, just adding to them. In that sense it is a functional philosophy. But after that 30,000 foot observation the comparison diverges as far as I can see. Great questions! Thanks, Chris

1 0