- Glasgow-haskell-users

API for looking-up/retrieving Haddock comments?
by Herbert Valerio Riedel 08 Aug '12

08 Aug '12

Hello, I've been wondering if there have been attempts to provide some library/API or similiar facility (other than pointing your web-browser to the static Haddock HTML report) for looking up Haddock comments associated with Haskell symbols? As an obvious application: When coding in dynamic languages (e.g. Python, Elisp, or GNU R to name a few), I've learned to appreciate the ability to lookup up documentation interactively from the tab-completing REPL w/o having to "switch context/focus" to different application (as I currently do: I have to switch from GHCi to a web-browser and first locate the appropriate package/module and then find the symbol I'm interested in). cheers, hvr

3 4

New INLINE pragma syntax idea, and some questions
by Brandon Simmons 07 Aug '12

07 Aug '12

I've been wondering for some time about the details of how GHC uses syntax with inlining, and how other transformations come into play in the process (I recently asked a question on SO if anyone wants some karma: http://stackoverflow.com/q/11690146/176841) I know this is a big topic and there's probably a lot more out there I should read. In particular I don't fully understand why these sorts of contortions... http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-Li… ...are required. It seems like a programmer has to throw "equational reasoning", separation of concerns, and all the little elegant bits about the language out the window just to indicate something boring to the compiler. Disclaimer: The following is less a proposal meant to be taken seriously, and more me trying to better understand things. Could the following be used as syntax for indicating inlining? Rather than relying on the syntactic LHS, instead let that be specified in the type signature... foldl :: (a -> b -> a) -> a -> [b] -> {-# INLINE #-} a foldl f z [] = z foldl f z (x:xs) = foldl f (f z x) xs ...indicating, in this case, that foldl should be inlined when "fully-applied" means its first three arguments (I guess that's the intent of the original version linked above?). Then (waves hands) the compiler could do the necessary transformations that the programmer had to do to foldl above. Maybe what I'm proposing is actually a separate NORECURSIVE_TRANSFORM pragma or something. An alternative if including the pragma in the type sig. isn't sound, is to allow it in the function definition left-hand side, after the bindings we would like applied before inlining. Brandon

3 3

thread blocked indefinitely in an MVar operation in unsafePerformIO
by Marco Túlio Gontijo e Silva 31 Jul '12

31 Jul '12

Hi. I'm having a problem calling logM from hsLogger inside unsafePerformIO. I have described the problem in Haskell-cafe, so I'll avoid repeating it here: http://www.haskell.org/pipermail/haskell-cafe/2012-July/102545.html I've had this problem both with GHC 7.4.1 and 7.4.2. Do you have any suggestion? Greetings. -- marcot http://marcot.eti.br/

2 2

next release
by Евгений Пермяков 30 Jul '12

30 Jul '12

When one should expect next major release (7.6.1) ? There is no any date noted in trac and it seems there is no any fixed, but may be someone can give reasonable estimate in months? I found traces of some features I wish to use in snapshots, so I interested in.

1 0

Building GHC on NetBSD/amd64
by iquiw 30 Jul '12

30 Jul '12

Hi, I am trying to build GHC on NetBSD/amd64. First, I built GHC-6.12.3 by porting from OpenBSD/amd64. After that, trying to build several versions (6.12.3, 7.0.4, 7.4.2) of GHC by the stage2 compiler. Build itself succeeded and compiling by the ghc seems no problem so far. However, ghci (all versions) crashes always by segmentation fault. --------------------------------------------------------------------- $ ghci GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. zsh: segmentation fault (core dumped) /usr/local/ghc-7.4.2/bin/ghci --------------------------------------------------------------------- backtrace by gdb shows only "s2xW_info ()". ktrace (kernel trace) output is as follows. --------------------------------------------------------------------- 4494 1 ghc CALL __sigprocmask14(3,0x7f7fffff49e0,0) 4494 1 ghc RET __sigprocmask14 0 4494 1 ghc CALL _lwp_self 4494 1 ghc RET _lwp_self 1 4494 1 ghc CALL __sigprocmask14(1,0x7f7fffff4970,0x7f7fffff49e0) 4494 1 ghc RET __sigprocmask14 0 4494 1 ghc CALL __sigprocmask14(3,0x7f7fffff49e0,0) 4494 1 ghc RET __sigprocmask14 0 4494 1 ghc CALL issetugid 4494 1 ghc RET issetugid 0 4494 1 ghc PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0xfffffffff610bfa5, trap=6) 4494 2 ghc RET __kevent50 -1 errno 4 Interrupted system call 4494 3 ghc RET ___lwp_park50 -1 errno 4 Interrupted system call 4494 1 ghc NAMI "ghc.core" --------------------------------------------------------------------- What should I check next? Thanks in advance.

2 1

Simplifying Core using GHC API
by Ranjit Jhala 30 Jul '12

30 Jul '12

Hi all, can anyone point me to the GHC API functions that I can use to trigger the various inlining simplifications? (i.e. to get the inlined CoreExprs that one gets with the -ddump-simpl flag?) Many thanks in advance!, Ranjit Jhala.

2 2

Access to the Parse Tree for Expressions
by Simon Fowler 30 Jul '12

30 Jul '12

Dear all, I'm currently working on a project which would benefit from access to the parse tree - ideally, we would like to deconstruct an expression into its constituent types. Currently we are using the exprType function to return the type of an expression, but this is limited as it only works for one 'level', per se. An example would be as follows. Currently, if we were to type in "map", we would be given a result of type Type, which we could further deconstruct into the various subtypes, as so: map :: (a -> b) -> [a] -> [b] split into: (a -> b) [a] [b] This is sufficient for the basics of the project at the moment, but ideally, we would like to use the parse tree to analyse the structure of expressions and thereby the types of the corresponding sub-expressions. Take "foldr drop" for example; we can determine the different types for the different functions with exprType: foldr :: (a -> b -> b) -> b -> [a] -> [b] drop :: Int -> [c] -> [c] Now we can call exprType on the application "foldr drop": foldr drop :: (Int -> [c] -> [c]) -> [c] -> [Int] -> [c] which would be split, according to our current code, into: arg1: (Int -> [c] -> [c]) arg2: [c] arg3: [Int] result: [c] The problem here is that we are unable to separate the "drop" from the "foldr". The project we are working on involves composing and decomposing expressions, and it is important that we can decompose the type of "foldr drop" into the types of the sub-expressions "foldr" and "drop" recursively. Ideally, we would like to construct a data structure which is much more akin to a parse tree with type annotations, in this case: PTreeApp (PTreeExpr "foldr" [| (a -> b -> b) -> b -> [a] -> [b] |]) (PTreeExpr "drop" [| Int -> [c] -> [c] |]) [| (Int -> [c] -> [c]) -> [c] -> [Int] -> [c] |] where the types in semantic brackets are a structural representation (e.g. TypeRep.Type) of the given types. Looking at the code of exprType, a call is firstly made to hscTcExpr, which in turn makes a call to hscParseStmt to return the parse tree. This would seem to provide the functionality that we would require, in that it would give access to a type-checkable parsed statement, but it doesn't seem to be exported by HscMain. Is there another function, which is accessible through the API, that would support this or something similar? I am far from an expert using the GHC API, so apologies if I am doing something grossly wrong or have missed something blatantly obvious. Thank you for taking the time to read this. Kind regards, Simon

2 1

API function to check whether one type fits "in" another
by "Philip K. F. Hölzenspies" 23 Jul '12

23 Jul '12

L.S., I sent this to the cvs-ghc list, but was - correctly - redirected here. We're trying to write an alternative interactive front-end (alternative to ghci). This front-end is very type-driven; terms are composed not as characters on a prompt, but as applications of terms to terms. At every application of a term to another, we want to check whether the application is well typed and what type variables would have to change. Suppose I want to build the term flip fmap (+) :: Num n => ((n -> n) -> b) -> n -> b In our front-end, however, we do not need the flip; we leave unfilled holes with their type annotated, so the above would really look like this (where [[ and ]] denote a hole): fmap [[ (n -> n) -> b ]] (+) :: Num n => n -> b We start this off by asking for the types of these separate things, using GHC.exprType, giving: fmap: ForAllTy f (ForAllTy a (ForAllTy b (FunTy (TyConApp GHC.Base.Functor [TyVarTy f]) (FunTy (FunTy (TyVarTy a) (TyVarTy b)) (FunTy (AppTy (TyVarTy f) (TyVarTy a)) (AppTy (TyVarTy f) (TyVarTy b))))))) (+): ForAllTy a (FunTy (TyConApp GHC.Num.Num [TyVarTy a]) (FunTy (TyVarTy a) (FunTy (TyVarTy a) (TyVarTy a)))) (Note that 'Var' things are pretty printed to just show their name, whereas all the constructors of Type are displayed using show.) The thing that we really want to ask the GHC-API is whether (+) 'fits into' the second argument-hole of fmap, i.e. we want to know whether (type of +) ForAllTy a (FunTy (TyConApp GHC.Num.Num [TyVarTy a]) (FunTy (TyVarTy a) (FunTy (TyVarTy a) (TyVarTy a)))) fits into (type of second argument of fmap) ForAllTy f (ForAllTy a (FunTy (TyConApp GHC.Base.Functor [TyVarTy f]) (AppTy (TyVarTy f) (TyVarTy a)))) What I'm looking for is a function fitsInto :: TermType -> HoleType -> Maybe [(TyVar,Type)] I have found many functions in TcUnify / Unify / TcMatches that look somewhat like this, but in all cases they required extra arguments. When these extra arguments are filled with arbitrary values, the result is always Nothing or some sort of panic. Any pointers would be truly welcome. Regards, Philip

4 6

Why GHC doesn't warn about LHS nullary-constructor pattern bindings?
by Herbert Valerio Riedel 19 Jul '12

19 Jul '12

Hello, Recently, I was a bit suprised that GHC didn't warn about useless `where` definitions such as the following when using `-Wall` (and I couldn't find a respective warning GHC CLI flag which would have enabled reporting a warning in this case -- unless I missed it) module Foo where foo :: Int -> Int foo n = n + 1 where Nothing = Just n ...wouldn't it be a sensible thing for GHC to warn in such cases (i.e. when the LHS of a pattern binding is a nullary constructor), or is there a useful application for this construct? (In my original case, I ended up with such a "dead" construct after some "unsound" code refactoring, and it would have helped me catch my error earlier, if GHC would have pointed out that somethings fishy with my code)

4 3

Re: Call to arms: lambda-case is stuck and needs your help (fwd)
by Henning Thielemann 19 Jul '12

19 Jul '12

I want to vote, too. I am ok with all of case of \case \of \case of For me single arguments are enough. We already have this restriction for 'case' and I can work around it simply by wrapping arguments in pairs temporarily (cf. curry $ \case ...). I vote against LambdaIf, since if-then-else is already unnecessary and can be written by ifThenElse, and LambdaIf is just ifThenElse with different parameter order. I vote against MultiCaseIf since it can be simply achieved by ifThenElse b1 a1 $ ifThenElse b2 a2 $ ifThenElse b3 a3 $ a4 http://www.haskell.org/haskellwiki/Case

1 0