March 2016 - Haskell-Cafe

implicit call stacks and calling function
by Evan Laforge 08 Mar '16

08 Mar '16

I noticed this when I started using the new implicit call stacks feature. I didn't bring it up because I figure it probably had a good reason and was too late to change anyway, but the recent talk about HasCallStack reminded me and I'm curious. When you do GHC.Stack.getCallStack you get a [(String, SrcPos)]. The SrcPos is the position of the calling function, but the String is the callee function. So you can't get the name of the calling function. Instead, you get the name of the function with the call stack annotation. That's not so useful because in say a logging function, I'm interested in the caller's name. I don't need the name of the logging function, it's just something boring like "info" or "warn"! When I switched from a custom preprocessor that sort of implemented SRCLOC_ANNOTATE, it was definitely nice to lose the custom local hackery, but not so nice to lose the caller's name. For tests I used an unsafe mutable global via unsafePerformIO, otherwise failed tests can't report the name of the failing test, but the hack doesn't work for logging. Is there a reason it was done the way it was, or a way to get the name of the calling function?

2 3

1-to-many preprocessor in stack/Cabal builds
by Andrey Sverdlichenko 08 Mar '16

08 Mar '16

Hi, I'm writing a package which uses custom preprocessor for creating some of the source files. It takes one IDL file as input and writes several .hs modules, depending on IDL contents. I need to compile this modules with a few normal ones and link them as a library, preferably with generated modules exposed. It doesn't look like a complex task and never was in with make/etc, but I run into some problems now. Obviously, cabal supports 1-to-1 preprocessors to create one Haskell module from one source file (alex, happy, etc), but I can't find anything for 1-to-many preprocessors. So, I decided to use hookedPrograms and hooks and do it myself. The call to preprocessor in the postConf hook worked just fine and created source files and module list. Cabal pre-* hooks seems to be right place to read this module list and use it, but are presenting two problems: can only modify other-modules, not exposed-modules, which is tolerable, and there is no access to build configuration. The latter is fatal, I need to know build dir to read module list. So I have to change action hooks. As the additional annoyance, there is absolutely no way to modify configuration once and for all, I have to override every single hook with the same "read module list and change config" wrapper. So, I have buildHook, copyHook and regHook replaced with wrappers which change PackageDescription parameter and call original function. Library is built and installed, but somewhere between build and copy actions there is still a message "Warning: modules not listed in foo.cabal for library component (add to other-modules)". I can't identify where it comes from. I'm using stack 1.0.4 to build this library, but all the problems seems to be cabal-related. Here is minimal example of what I ended up with: https://github.com/rblaze/cabal-hooks-sample Now I wonder if I missed an easier way to handle this code generation. If not, at least how to get rid of warning about missing modules between build and copy actions?

2 3

Re: [Haskell-cafe] HasCallStack - runtime costs?
by Johannes Waldmann 08 Mar '16

08 Mar '16

Eric wrote earlier: > If you import a function with a HasCallStack constraint > there's no way to disable the overhead ... > For non-recursive functions like head and tail, > the overhead is probably not large enough to be noticeable. Now I'm confused: should this mean that head and tail are "functions with a HasCallStack constraint"? If I ask ghci for their type, it just says head :: [a] -> a and that's also what's in the source https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0… but the Callstack explanation in the user manual does show a different version of head https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/users_guide/glasgow_… I am not particularly concerned about head and tail here but generally about how to find out whether my code is taking a performance penalty. I think the documentation (user manual Section 9.31) is rather brief about the semantics. It speaks about solving "HasCallStack" constraints - but they could also be propagated? There is secondary documentation like https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack but it does not tell what is actually implemented, or I don't see it. - J.W.

3 2

Tagged instances for Aeson overlapped
by Dmitry Olshansky 08 Mar '16

08 Mar '16

Hello, I tried to compile my project with GHC 8 (from HEAD). And I got > • Overlapping instances for > aeson-0.11.1.0:Data.Aeson.Types.Class.ToJSON > ... > arising from a use of ‘serve’ > Matching instances: > two instances involving out-of-scope types > instance aeson-0.11.1.0:Data.Aeson.Types.Class.ToJSON b => > aeson-0.11.1.0:Data.Aeson.Types.Class.ToJSON > (Data.Tagged.Tagged a b) > -- Defined in ‘aeson-0.11.1.0:Data.Aeson.Types.Instances’ > instance forall k x (r :: k). > aeson-0.11.1.0:Data.Aeson.Types.Class.ToJSON x => > aeson-0.11.1.0:Data.Aeson.Types.Class.ToJSON > (Data.Tagged.Tagged r x) One of instances should be removed probably. I suppose that instance for removing should be instance in Data.Tagged. But version in Aeson should be PolyKinded. What do you think? Best regards, Dmitry

2 2

Trouble on Travis CI with recent cabal versions
by Sven Panne 07 Mar '16

07 Mar '16

For my OpenGLRaw project, I'm using a .travis.yml generated by Herbert's https://github.com/hvr/multi-ghc-travis and the corresponding https://launchpad.net/~hvr/+archive/ubuntu/ghc PPA. Recently things broke on Travis CI, and there are a few strange things: * The cabal-install-head package seems to be based on cabal 1.23, which is older than cabal-install-1.24. Is this intended? * The OpenGLRaw package has no test suite, and this seems to be OK for cabal-install-head ( https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/114109605#L929) while cabal-install-1.24 fails in the "cabal test" step ( https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/114109606#L1022) This is a regression: I think that "cabal test" for a package without a test suite should be a no-op, at least that used to be the case. * Why does "cabal test" say "Re-configuring with test suites enabled. If this fails, please run configure manually." when "cabal configure" has already been run (including --enable-tests)? This looks like a bug... Cheers, S.

1 0

Type-level list "elem" inference
by amindfv＠gmail.com 07 Mar '16

07 Mar '16

So I've got some code that looks like: {-# LANGUAGE DataKinds, UndecidableInstances, TypeFamilies, KindSignatures, TypeOperators #-} import Data.Proxy import GHC.TypeLits type family IsSubset (as :: [Symbol]) (bs :: [Symbol]) where IsSubset as bs = IsSubsetPrime as bs bs type family IsSubsetPrime (as :: [Symbol]) bs bs' where IsSubsetPrime as '[] bs' = 'False IsSubsetPrime '[] bs bs' = 'True IsSubsetPrime (a ': as) (a ': bs) bs' = IsSubsetPrime as bs' bs' IsSubsetPrime (a ': as) (b ': bs) bs' = IsSubsetPrime (a ': as) bs bs' This lets me write functions like: foo :: (IsSubset '["foo", "bar"] args ~ 'True) => Proxy args -> Int foo args = undefined I've also got a type family: type family IsElem (a :: Symbol) (bs :: [Symbol]) where IsElem a (a ': bs) = 'True IsElem a (b ': bs) = IsElem a bs IsElem a '[] = 'False This lets me write functions like: bar :: (IsElem "foo" args ~ 'True) => Proxy args -> Int bar args = undefined The problem comes when I want to use "bar args" in the definition of "foo args" -- even though it's clear to me that ["foo","bar"] being a subset of args implies that "foo" is an element of args, I haven't written "IsElem" or "IsSubset" in a way that it's clear to the compiler. Is there a way to write IsElem and IsSubset so they "compose"? Thanks! Tom

2 1

PolyKind for Fixed and HasResolution from Data.Fixed
by Никита Тимофеев 07 Mar '16

07 Mar '16

Hi all! If we define HasResolution and Fixed like that: class HasResolution (a :: k) where resolution :: p a -> Integer newtype Fixed (a :: k) = Fixed Integer We can do something like that: instance KnownNat a => HasResolution a where resolution = natVal 2.3 :: Fixed 1 -- Timofeev N.D.

1 0

Accuracy of Data.Number.Fixed
by Lyle Kopnicky 07 Mar '16

07 Mar '16

This does not seem right to me: Prelude Data.Number.Fixed> read "4.00" :: Fixed (EpsDiv10 (EpsDiv10 Eps1)) 4.00 Prelude Data.Number.Fixed> read "4.01" :: Fixed (EpsDiv10 (EpsDiv10 Eps1)) 4.00 Prelude Data.Number.Fixed> read "4.02" :: Fixed (EpsDiv10 (EpsDiv10 Eps1)) 4.03 Prelude Data.Number.Fixed> read "4.03" :: Fixed (EpsDiv10 (EpsDiv10 Eps1)) 4.04 Prelude Data.Number.Fixed> read "4.04" :: Fixed (EpsDiv10 (EpsDiv10 Eps1)) 4.05 Maybe I am misunderstanding the purpose of this library. I guess that "two digits" of precision means that it is accurate within +/- 0.01? I think that this library is meant for doing arbitrary-precision transcendental operations. But it would not be good as a model for something like currency. It's using ratios as an internal representation, and I'm not sure what ratios it's choosing, but I think I'd choose, say, 401/100 for the "4.01" representation. I guess it's picking a slightly smaller factor than that. The non-reversibility of read/show is somewhat disconcerting. I think I prefer the Decimal library for currency. Regards, Lyle

3 4

HasCallStack - runtime costs?
by Johannes Waldmann 06 Mar '16

06 Mar '16

Dear Cafe, the new (8.*) call stack feature https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/users_guide/glasgow_… is certainly nice for debugging during development. But how costly is it at runtime? I notice a 5 percent slowdown. That's not a problem if there's an easy way to switch this off for production (without changing the code). Related: how to make code that uses it, compile with older ghcs that don't have it. I made this hack: do not import GHC.Stack.Types, but instead {-# language CPP, MultiParamTypeClasses #-} #if (__GLASGOW_HASKELL__ < 710) {-# language NullaryTypeClasses #-} #endif module Stack ( HasCallStack ) where #if (__GLASGOW_HASKELL__ >= 800) import GHC.Stack.Types #else class HasCallStack instance HasCallStack #endif When I compile with 8.rc2, and change ">= 800" to ">= 900", I am getting the 5 percent speedup mentioned above. But does it really do what I hope it does (remove all runtime overhead that call stacks may have)? When I compile with 7.10.3, I am getting 5 .. 10 percent faster again. My code does nothing fancy (w.r.t. types and libraries), it just uses Data.IntMap heavily. And it has some class Semiring s where zero :: s one :: s plus :: HasCallStack => s -> s -> s times :: HasCallStack => s -> s -> s - J.W.

3 4

Re: [Haskell-cafe] HasCallStack - runtime costs?
by Johannes Waldmann 06 Mar '16

06 Mar '16

Thanks, Eric. > If you import a function with a HasCallStack constraint > there's no way to disable the overhead But then this means that each library should avoid these constraints? Or not, because this rightly scares away users from calling nontotal functions? > ... with a couple special rules for > building dictionaries in GHC's constraint solver. then activation of these special rules could be a compiler switch? Though it'd probably create a mess with separate compilation/linking. But switching via CPP will do the same. > class Semiring s where > plus :: HasCallStack => s -> s -> s > times :: HasCallStack => s -> s -> s > I'm curious, why do plus and times take a CallStack? because I want to (be able to) debug implementations. simplified example: {-# language ConstrainedClassMethods #-} import GHC.Stack.Types class C a where p :: a -> Int q :: HasCallStack => a -> Int instance C () where p x = error "huh" q x = error "huh" Calling q gives more information: *Main> p () *** Exception: huh CallStack (from HasCallStack): error, called at CS.hs:10:9 in main:Main *Main> q () *** Exception: huh CallStack (from HasCallStack): error, called at CS.hs:11:9 in main:Main q, called at <interactive>:44:1 in interactive:Ghci1 it, called at <interactive>:44:1 in interactive:Ghci1 I did not see another way than to change the type of the method in the class. (Which looks terrible of course.) - J.

2 1