- Glasgow-haskell-users

“Ambiguous type variable in the constraint” error in rewrite rule
by Tsuyoshi Ito 16 Jul '12

16 Jul '12

Hello, Why does GHC 7.4.1 reject the rewrite rule in the following code? > module Test where > > import Data.Monoid > import Control.Monad.Writer.Strict > > f :: Monad m => a -> m a > f = return > > g :: Monoid w => a -> Writer w a > g = return > > {-# RULES > "f->g" f = g > #-} On the line containing the rewrite rule, GHC shows the following error message: Test.hs:13:12: Ambiguous type variable `w0' in the constraint: (Monoid w0) arising from a use of `g' Probable fix: add a type signature that fixes these type variable(s) In the expression: g When checking the transformation rule "f->g" Interestingly, the code compiles if the rewrite rule is replaced with the following SPECIALIZE pragma: > {-# SPECIALIZE f :: Monoid w => a -> Writer w a #-} I find this strange because if I am not mistaken, this specialization is handled by using a rewrite rule of the same type as the one which GHC rejects. The following ticket might be related, but I am not sure: Subclass Specialization in Rewrite Rules http://hackage.haskell.org/trac/ghc/ticket/6102 Best regards, Tsuyoshi

2 3

Type error when deriving Generic for an associated data type
by Bas van Dijk 13 Jul '12

13 Jul '12

Hi, I'm hitting on an issue when deriving Generic for an associated data type: {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DeriveGeneric #-} import GHC.Generics class Foo a where data T a :: * instance Foo Int where data T Int = Bla deriving Generic Couldn't match type `Rep (T Int)' with `M1 t0 t1 (M1 t2 t3 U1)' Expected type: Rep (T Int) x Actual type: M1 t0 t1 (M1 t2 t3 U1) x In the pattern: M1 (M1 U1) In an equation for `to': to (M1 (M1 U1)) = Bla In the instance declaration for `Generic (T Int)' The GHC trac seems to be down. Is this a known issue? Cheers, Bas

3 3

How to describe this bug?
by Sönke Hahn 13 Jul '12

13 Jul '12

Hi! I've discovered a strange bug that violates simple equational reasoning. Basically, something similar to this: let a = f x in a == f x evaluates to False. I'd like to report this on ghc-trac, but I realised, that I don't know a good name for behaviour like this. Is there one? "Broken referential transparency", perhaps? Thanks, Sönke

10 20

GHC ARM builds?
by Austin Seipp 13 Jul '12

13 Jul '12

With 7.4.2, the patches for full ARM linker support were merged and released. Are there any official builds of GHC for Linux/ARM yet? I have a PandaBoard ES I'd be willing to contribute for builds and/or testing/development, but I don't know where to get a GHC for bootstrapping. It's also worth asking if there's any page documenting needed prerequisites/expected build environment. If not it should be added to the wiki (I don't see any as of right now.) -- Regards, Austin

4 5

Imported foreign functions should be strict
by Favonia 12 Jul '12

12 Jul '12

Hi all, Recently I am tuning one of our incomplete libraries that uses FFI. After dumping the interface file I realized strictness/demand analysis failed for imported foreign functions---that is, they are not inferred to be strict in their arguments. In my naive understanding all imported foreign functions are strict! Here's a minimum example (with GHC 7.4.2): {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign.C foreign import ccall unsafe "sin" sin' :: CDouble -> CDouble where in the interface file the function sin' will have strictness U(L) (meaning Unpackable(Lazy)). Regards, Favonia

3 3

[Fwd: Memory corruption issues when using newAlignedPinnedByteArray, GC kicking in?]
by Nicolas Trangez 11 Jul '12

11 Jul '12

All, I sent this mail to Haskell Cafe earlier today, and was pointed [1] at this list. As such... Any help/advice would be greatly appreciated! Thanks, Nicolas [1] http://www.haskell.org/pipermail/haskell-cafe/2012-July/102242.html -------- Forwarded Message -------- > From: Nicolas Trangez <nicolas(a)incubaid.com> > To: haskell-cafe(a)haskell.org > Cc: Roman Leshchinskiy <rl(a)cse.unsw.edu.au> > Subject: Memory corruption issues when using > newAlignedPinnedByteArray, GC kicking in? > Date: Tue, 10 Jul 2012 19:20:01 +0200 > > All, > > While working on my vector-simd library, I noticed somehow memory I'm > using gets corrupted/overwritten. I reworked this into a test case, and > would love to get some help on how to fix this. > > Previously I used some custom FFI calls to C to allocate aligned memory, > which yields correct results, but this has a significant (+- 10x) > performance impact on my benchmarks. Later on I discovered the > newAlignedPinnedByteArray# function, and wrote some code using this. > > Here's what I did in the test case: I created an MVector instance, with > the exact same implementation as vector's > Data.Vector.Storable.Mutable.MVector instance, except for basicUnsafeNew > where I pass one more argument to mallocVector [1]. > > I also use 3 different versions of mallocVector (depending on > compile-time flags): > > mallocVectorOrig [2]: This is the upstream version, discarding the > integer argument I added. > > Then here's my first attempt, very similar to the implementation of > mallocPlainForeignPtrBytes [3] at [4] using GHC.* libraries. > > Finally there's something similar at [5] which uses the 'primitive' > library. > > The test case creates vectors of increasing size, then checks whether > they contain the expected values. For the default implementation this > works correctly. For both others it fails at some random size, and the > values stored in the vector are not exactly what they should be. > > I don't understand what's going on here. I suspect I lack a reference > (or something along those lines) so GC kicks in, or maybe the buffer > gets relocated, whilst it shouldn't. > > Basically I'd need something like > > GHC.ForeignPtr.mallocPlainAlignedForeignPtrBytes :: Int -> Int -> IO > (ForeignPtr a) > > Thanks, > > Nicolas > > [1] https://gist.github.com/3084806#LC37 > [2] https://gist.github.com/3084806#LC119 > [3] > http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-Fo… > [4] https://gist.github.com/3084806#LC100 > [5] https://gist.github.com/3084806#LC81 > >

2 2

Re: How to describe this bug?
by Tyson Whitehead 10 Jul '12

10 Jul '12

On July 10, 2012 10:39:41 Colin Adams wrote: > Sure they would be better modelled that way, but the whole point of using > floating point arithmetic is to sacrifice accuracy for performance, is it > not? True. I just find it interesting that some types have a builtin Nothing value. Some further examples are pointer (where NULL is Nothing) and clamped/saturation arithmetic (where min and max values are Nothing). It would be nice if somehow they could be unified at the top level without the performance penalty associated with a genuine Maybe value. Another possibility might be to consider NaN to encode bottom in Float#. When you constructed Float from Float# with a NaN it would give bottom. Would the existance of unboxed lifted types be a problem? Cheers! -Tyson

1 0

Modified layout for lambda-case
by Tyson Whitehead 09 Jul '12

09 Jul '12

It seems my suggestion isn't getting too much traction. It occurs to me this may be because I jumped right into layout rules and didn't first give some simple motivating examples to get the idea across. SHORT VERSION: Assume '\' is a grouping construct. I proposed always interpreting ... \x -> do (3a) ... as ... \ { x -> do { ... } } (3b) and never as ... \ { x -> do { }; ... } (3c) or ... \ { x -> do { } } ... (3d) This would be apposed to our current situation of all these being possible depending on if the second line starts past (3c), at (3b), or before (3d) 'x'. We loose nothing is at best empty groups do nothing (let and where) and at worst are errors (do and case) as in the above. LONGER VERSION: What I was suggesting was to change the layout rule that gives you empty groupings. Currently nonsensical nested empty where and let clauses like let { x = ... where { }; ... } (1a) do { let { }; ... } (2a) can be expressed using layouts let x = ... where (1b) ... do let (2b) ... because each new grouping has to be indented further than the previous. This trips us up if we change '\' into a grouping construct as the common ... \x -> do (3a) ... will get interpreted incorrectly as ... \ { x -> do { } } ... (3d) It all seems silly though. At best empty grouping does nothing (let and where) and at worst is an error (do and case). Why then not always go with ... \ { x -> do { ... } } (3b) That is, if a line ends in a grouping clauses and the next line is further indented, then what follows is the associated grouped statements. It's also easier to read. Further indented lines following a grouping clause are associated with that clause. No need to identify other potential grouping clauses and check relative indentation levels. Cheers! -Tyson

1 0

More infinite simplifier bugs?
by Ron Alford 07 Jul '12

07 Jul '12

So a while back Simon added a tick counter to the simplifier: http://hackage.haskell.org/trac/ghc/ticket/5448 Are there any known bugs that can cause the simplifier to run out of memory /without/ hitting the tick counter limit? I have code that /used/ to run (at least after hacking around the previous simplifier bug): https://github.com/ronwalf/Planning With GHC 7.4.[12], it exhausts all the RAM on my machine (4GB). Compiling with -O0 fixes the problem. I can start bisecting my code to find the problem if nothing comes to mind. -Ron Alford (who seems to be good at killing the simplifier)

2 2

Creating stubs statically
by Paolo Capriotti 05 Jul '12

05 Jul '12

As explained in detail here: http://www.haskell.org/pipermail/ffi/2012-June/001867.html, it may be useful to have a form of foreign declaration that creates a static stub for a haskell function without exporting a symbol. Here is a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/7048. It is not particularly clear how such a declaration would look like syntactically. In the ticket I proposed the following: foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback but please do suggest better alternatives. It would also be useful to see some use cases of this new form of declaration. Library binding authors: would this be a welcome addition for you? BR, Paolo

2 1