__color__,__group__,ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter
3,Active Tickets,58,"Adapters for slicing, tupling etc.",None,,,enhancement,,new,2011-08-20T00:51:04Z+0100,2011-08-28T11:51:29Z+0100,It should be possible to get a vector by tupling two arbitrary vectors and so on.,rl
4,Active Tickets,15,"Add ""generalised scan""",None,0.7,,enhancement,,new,2010-05-04T09:49:22Z+0100,2011-08-20T00:45:36Z+0100,"In any case, vector could well provide an operation like this:

{{{
cant_think_of_a_name :: Vector v a => Int -> (v a -> a) -> v a
}}}

The function would take the initialised prefix of the vector (starting with empty) and produce the next element. This would require a bit of hackery underneath but the interface would be safe and pure. Would something like this be useful?

See http://www.haskell.org/pipermail/glasgow-haskell-users/2010-May/018816.html

Note that we can't `unsafeFreeze` the vector until we are done because that would break GC for boxed vectors. Also, we can't recycle the vector because `a` could be a thunk with references to the intermediate `v a`.",rl
3,Active Tickets,87,Add a varient of unfoldrN,None,,,enhancement,,new,2012-11-30T05:07:13Z+0000,2012-11-30T05:07:13Z+0000,"I suggest we either add a variant of unfoldrN or make an API-breaking change to the current one.  The variant (placeholder name for now) would have a signature:

    unfoldrN' :: Storable a => Int -> (b -> Maybe (a, b)) -> b -> (Vector a,b)

In otherwords, we provide the resulting type `b` after applying the function N time (or fewer, if it returns Nothing).",tommd
3,Active Tickets,67,Add allocation statistics to benchmarks,None,,,enhancement,,new,2011-11-27T15:54:13Z+0000,2011-11-27T15:54:13Z+0000,The fix for #66 doesn't change the performance of any of the benchmarks. We probably should also run them with `+RTS -s` and compare the results.,rl
4,Active Tickets,94,Add ifoldM' and friends,None,,,enhancement,,new,2013-05-14T14:41:26Z+0100,2013-05-14T14:41:26Z+0100,"As there are ifoldl and ifoldl' in Data.Vector.Unboxed, could you provide ifoldM and ifoldM' as well?",mekp
3,Active Tickets,88,Add mapMaybe and catMaybes,None,,,enhancement,,new,2012-11-30T16:44:41Z+0000,2013-05-04T11:57:27Z+0100,"I often want to use a vector analogue of mapMaybe from Data.Maybe. Working around it is typically awkward because it requires a use of fromJust.

I'll attach a patch that implements mapMaybe and a related function, catMaybes.",akio
4,Active Tickets,62,Add strict versions of accum and friends,None,,,enhancement,,new,2011-09-07T08:06:20Z+0100,2011-09-07T08:06:20Z+0100,,rl
3,Active Tickets,84,Add strict versions of mapM and friends,None,,,enhancement,,new,2012-11-16T17:50:55Z+0000,2012-11-16T17:51:05Z+0000,"I had a big space leak due to using mapM and I had to roll my own `mapM'` that goes via lists. It would be nice if the library included `mapM'` and `forM'`, as they're hard to write outside the library due to having to go through the streaming machinery.",tibbe
3,Active Tickets,60,Add support for additional implementations of fusible functions,None,,0.10,enhancement,,new,2011-08-23T22:47:22Z+0100,2012-01-24T18:30:06Z+0000,"The prime example is `replicate`: if it doesn't fuse, we really want it to use `basicSet` rather than `unstream`. There are many other functions like this. We don't really want to rely on rules for this because that would require an additional simplifier phase to work reliably. Rather, we'd want to implement `replicate` roughly like this:

{{{
unstreamOrElse :: Stream a -> v a -> v a
{-# INLINE_STREAM unstreamOrElse #-}
unstreamOrElse s x = x

{-# RULES

""stream/unstreamOrElse""
  stream (unstreamOrElse s x) = s

  #-}

replicate n x = unstreamOrElse (Stream.replicate n x)
                               (new (Mutable.replicate n x))
}}}

We'll probably also want `streamOrElse`:

{{{
streamOrElse :: (Stream a -> b) -> (v a -> b) -> v a -> b
{-# INLINE_STREAM streamOrElse #-}
streamOrElse f g = g

{-# RULES

""streamOrElse/unstream""
  streamOrElse f g (unstream s) = f s

""streamOrElse/unstreamOrElse""
  streamOrElse f g (unstreamOrElse s x) = f s
}}}

There are ways to keep the number of rules manageable (e.g., by making `streamOrElse` and `unstreamOrElse` the only streaming combinators.",rl
4,Active Tickets,59,Bits instances for vectors,None,,,task,,new,2011-08-20T00:56:47Z+0100,2011-08-28T11:50:49Z+0100,,rl
3,Active Tickets,9,break and span don't fuse,None,0.5,0.10,enhancement,,new,2010-04-18T18:09:38Z+0100,2012-01-24T18:30:24Z+0000,,rl
3,Active Tickets,24,Conversion between different types of vectors,None,,,task,,new,2010-06-13T21:15:59Z+0100,2011-08-18T00:01:48Z+0100,"Problems which require conversion between different types of vectors arise from time to time and they are not described in documentation.

I think most important is conversion between unboxed and storable vectors. Unboxed vectors are more convenient to work with (Tuples!) and with storables one could hook into FFI. Conversion between these types should be covered in documentation. In this case O(1) conversion is of course preferable.

Currently there are two method for vector conversion.
{{{
convert1 = fromList . toList 

convert2 v = generate (length v) (v !) 
}}}

So please provide either function for conversion between vectors or describe this in documentation.
",Khudyakov
3,Active Tickets,90,Data.Vector.Generic.create/Data.Vector.Generic.Mutable.new are not referentially transparent,None,,,defect,,new,2013-01-14T21:14:47Z+0000,2013-01-14T21:14:47Z+0000,"For example:
{{{
> Data.Vector.Generic.create (new 3) :: Data.Vector.Unboxed.Vector Int
fromList [991908,60686641,75487896]
> Data.Vector.Generic.create (new 3) :: Data.Vector.Unboxed.Vector Int
fromList [57033696,56765093,956800]
}}}",blarsen
3,Active Tickets,64,Define specific Show and Read instances for vectors of Chars and Word8s that show and read like Strings,None,,,enhancement,,new,2011-10-14T14:55:39Z+0100,2011-10-16T22:10:27Z+0100,"When working with vectors of `Chars` and `Word8s` (think `ByteStrings`) it is very handy for debugging and working in a REPL if they are shown and read as `Strings`. Note that traditional `ByteStrings` also have this behavior.

As a reaction to my `vector-bytestring` package a few people on reddit and on the haskell-cafe mailinglist proposed turning the `ByteString` type synonym into a newtype with the desired `Show` and `Read` instance. I don't really like this but I agree with the need for a specific instance.

The attached patch adds the specific instances to vector.",basvandijk
4,Active Tickets,74,expose the bytearray in primitive vectors,None,,,enhancement,,new,2012-01-13T13:26:20Z+0000,2012-01-27T23:04:50Z+0000,"This is based on our discussion regarding vector / primitive performance. Right now, in some tight loop, I see a 20% performance dropoff due to the offset being always calculated. Hence I use bytearrays directly. They are, on the other hand terribly inconvinient in some cases.

I propose a method
{{{
expose :: Vector -> ByteArray
}}}
that exposes the underlying array directly for faster indexing operations.
In addition / alternatively I'd like an operation
{{{
unsafeBaseIndex :: Vector -> elm
}}}
that works like unsafeIndex but never incorporates the offset.

The reasoning is that there are cases where we always know the offset to be zero and no slicing would ever happen.

Benchmarks on vector / primitive will follow.",choener
4,Active Tickets,4,"Fix ""too large"" tests for enumFromTo specialisations",None,0.6,,defect,,new,2010-04-18T18:00:30Z+0100,2010-10-21T10:05:37Z+0100,See comments in Data.Vector.Fusion.Stream.Monadic,rl
3,Active Tickets,92,foldl' within Foldable instance seems broken,None,,,defect,,new,2013-02-23T17:35:27Z+0000,2013-02-23T17:35:27Z+0000,"When I run this piece of code:

{{{
import qualified Data.Vector as V
import qualified Data.Foldable as F
size=10^8
main = do
    print $ (V.foldl (+) 0 $ (V.enumFromN (0::Double) size) :: Double)
    print $ (V.foldl' (+) 0 $ (V.enumFromN (0::Double) size) :: Double)
    print $ (F.foldl (+) 0 $ (V.enumFromN (0::Double) size) :: Double)
    print $ (F.foldl' (+) 0 $ (V.enumFromN (0::Double) size) :: Double)
    putStrLn ""done.""

}}}

The first three numbers print almost instantly, but the last number takes forever to print.  The profiler is telling me that the garbage collector is going off like mad.  Shouldn't F.foldl' be the exact same thing as V.foldl'?",MikeIzbicki
3,Active Tickets,96,forM_ in unboxed module generates temporary vector,None,0.7,,defect,,new,2013-06-07T02:48:46Z+0100,2013-06-07T02:48:46Z+0100,"I discovered this when debugging some performance issues. Data.Vector.Unboxed.forM_ generates temporary vector in each iteration, and copies contents to it which causes slowdown in the code that use it for a mutating loop. 
I think the example code below reproduces it - in the core, newByteArray seems to be generated for forM_:

{{{
{-# LANGUAGE BangPatterns #-}

import Data.Vector.Unboxed.Mutable as MU
import Data.Vector.Unboxed as U hiding (mapM_)
import Control.Monad.ST as ST
import Control.Monad.Primitive (PrimState)
import Data.Int

type MVI1 s  = MVector (PrimState (ST s)) Int

gridWalk ::  MVI1 s -> Int -> ST s ()
gridWalk fp !k = do
   {-#SCC cmp #-} MU.unsafeWrite fp k k
{-#INLINE gridWalk #-}

findSnakes :: Vector Int32 -> Vector Int32 -> MVI1 s ->  Int -> Int -> (Int -> Int -> Int) -> ST s ()
findSnakes a b fp !k !ct !op = U.forM_ (U.fromList [0..ct-1]) (\x -> gridWalk fp (op k x))
{-#INLINE findSnakes #-}

f :: Vector Int32 -> Vector Int32 -> Int
f a b = runST $ do
  fp <- new 10
  findSnakes a b fp (0) 10 (+)  
  return 5
{-#INLINABLE f #-}

main = print $ f (U.fromList [0]) (U.fromList [0])

}}}

In the optimized core, this is seen (create new vector, and copy the contents there):

{{{
$j =
                \ (x1 :: Int#) ->
                  case newByteArray# (*# x1 4) (sc1 `cast` ...)
                  of _ { (# ipv, ipv1 #) ->
                  case (copyMutableByteArray# sc4 (*# sc2 4) ipv1 0 (*# sc3 4) ipv)
                       `cast` ...
}}}

I had to work around this issue of temporary generation by writing a loop myself.

Tested with GHC 7.6.1, vector 0.10


",sanketr
4,Active Tickets,63,GHC infinite loop when building vector program,None,0.7,,defect,,new,2011-10-12T15:17:18Z+0100,2012-02-15T13:08:12Z+0000,"As [http://www.haskell.org/pipermail/glasgow-haskell-users/2011-October/021057.html reported] on the glasgow-haskell-users mailinglist, when benchmarking my new [http://hackage.haskell.org/package/vector-bytestring vector-bytestring] package I discovered
that building the following program causes GHC to go into, what seems
to be, an infinite loop:

{{{
import Data.Vector (Vector)
import qualified Data.Vector.Generic as VG

main = print $ VG.foldl f z (VG.fromList [] :: Vector Int)

f = flip (:)
z = []
}}}

I build it with:

`$ ghc --make vectorGHCloop.hs -O2`

It compiles fine without the `-O2` or if you specify
`-fno-enable-rewrite-rules`. So it's probably a loop in a rule
somewhere.

Note that the program also builds fine when I change the 'f' and 'z' to:

{{{
f = (+)
z = 0
}}}

I use `vector-0.9` and `ghc-7.2.1`. 

Daniel Fischer replicated it with `vector-0.7.1` and `ghc-7.2.1` (^^C'ed after six minutes).
Compilation finishes (unsurprisingly) with `-fno-spec-constr` or with
`{-# NOINLINE f #-}`.

It compiles fine with `vector-0.7.0.1` and `ghc-7.0.4`.
",basvandijk
3,Active Tickets,80,Improve Data instance,None,,,defect,,new,2012-07-23T14:49:29Z+0100,2012-07-23T14:49:29Z+0100,"The current Data instance for vectors doesn't define toConstr and gunfold. This breaks some libraries, most notable uniplate. We should define the Data instance like this:

{{{
instance ... => Data (Vector a) where
  gunfold k z c
    | constrIndex c == 1 = k (z fromList)
    | otherwise = error ...

  toConstr v = v `seq` vConstr

  dataTypeOf _ = vType

vConstr = mkConstr vType ""fromList"" [] Prefix
vType = mkDataType ""Vector"" [vConstr]
}}}
",rl
2,Active Tickets,11,Improve interface to mutable vectors,None,0.7,,enhancement,,new,2010-04-22T17:28:37Z+0100,2011-08-18T00:04:57Z+0100,Mutable vectors should support much the same operations as immutable ones.,rl
2,Active Tickets,82,"Merge ""Unfolding"" section into ""Construction"" in the docs",None,,0.10,defect,,new,2012-09-18T08:36:42Z+0100,2012-09-18T08:36:42Z+0100,,rl
1,Active Tickets,54,Missing NFData instances for vector types,None,0.7,0.10,enhancement,,reopened,2011-05-23T09:06:27Z+0100,2013-02-27T05:01:00Z+0000,Please provide `NFData` instances for the various `Data.Vector` types,hvr
3,Active Tickets,89,Only try annotations if available,None,,,defect,,new,2013-01-12T18:33:15Z+0000,2013-01-12T18:33:15Z+0000,"Or just take them out.

Currently I have to take them out manually to cross-compile for Blackberry.",singpolyma
3,Active Tickets,51,optimization of fst . unzip . zip,None,0.7,,enhancement,,new,2011-03-02T15:11:08Z+0000,2011-08-21T20:11:10Z+0100,"Hi,

lets assume this:
{{{
f n = map (\(a,b) -> (a+1,b+1)) . zip (enumFromN 0 n) (enumFromN 0 n)
g = fst . unzip

main = print . sum . g . f $ 100
}}}

In this case i would like to have {{{sum . g . f}}} reduce to {{{sum . enumFromN 0}}} but this does not happen. Is it in any way possible to get the optimizer to ""cut out"" unused code paths? The map operation in ""f n"" is basically a placeholder for something complicated.

If this is possible to optimize correctly, it becomes possible to nicely describe some complicated code paths.",choener
4,Active Tickets,8,partition should support recycling,None,0.5,,enhancement,,new,2010-04-18T18:09:08Z+0100,2010-10-21T10:13:07Z+0100,See comments in Data.Vector.Generic,rl
4,Active Tickets,83,"PhaseChange class, Mutable data family",None,,,enhancement,,new,2012-09-21T20:20:58Z+0100,2012-10-14T17:17:08Z+0100,"Hello,

How receptive would you be towards a change to primitive and/or vector somewhere along the line of the following?

{{{
class PhaseChange a where
    data Mutable a :: * -> *
    unsafeThaw :: a -> ST s (Mutable a s)
    unsafeFreeze :: Mutable a s -> ST s a
    copy :: Mutable a s -> ST s (Mutable a s)

-- all of these ST s could be PrimMonad m (or MonadST m) instead
thaw :: PhaseChange a => a -> ST s (Mutable a s)
thaw = copy <=< unsafeThaw

freeze :: PhaseChange a => Mutable a s -> ST s a
freeze = unsafeFreeze <=< copy

...other functions, such as 'modify' from vector...

instance PhaseChange ByteArray where
    data Mutable ByteArray s = MutableByteArray (MutableByteArray# s)
    ...

type MutableByteArray = Mutable ByteArray

instance PhaseChange (Array a) where
    data Mutable (Array a) s = MutableArray (MutableArray# s a)
    ...

type MutableArray s a = Mutable (Array a) s

-- forall Vectors
instance PhaseChange (Vector a) where
    data Mutable (Vector a) s = MVector !(MutableArray s a) !Int !Int
    ...

type MVector s a = Mutable (Vector a) s
}}}

Advantages: There would be a uniform interface for interacting with types which can be converted between mutable and immutable forms, with operations available which can be defined purely in terms of it (such as 'modify'); the various Arrays and Vectors would implement it, but relevant third parties would also be able to.

Disadvantages: It would not be possible to partially apply the !MutableArray and MVector types. This would totally break the MVector class and the Mutable type family, which would have to be redesigned to accomodate (presumably using the new Mutable data family instead). To be honest I didn't realize this when I started writing, and I wouldn't be surprised if it's a deal breaker. An other possibility would be to have a separate !PhaseChange1 class for * -> * types, which I think would solve this problem, but didn't work so well when I last tried it for reasons I can't remember (albeit that was still with the MPTC formulation, see below).

Motivation: I have a phasechange package on Hackage[1], which implements the same concept as above except currently with an MPTC and TFs with bidirectional equality constraints (so, basically FDs). I realized that the whole thing would be a lot more simple and straightforward if instead of the whole TFs machinery I had a simple Mutable data family like above, but that would require instances to adapt to the class, instead of vice versa like now. Hence this ticket. If vector doesn't want to adapt then I would have to choose between the more appealing formulation and the Vector instances. If by chance it does want to adapt then I can work on preparing a patch. (Motivation for the phasechange package: I'm slowly working on bindings for Qt, and its various data types would be represented on the Haskell side in both mutable and immutable forms, which would implement this interface.)

[1] http://hackage.haskell.org/package/phasechange",illissius
4,Active Tickets,79,"Please provide memory-footprint ""complexity"" information in Haddock documentation",None,,,enhancement,,new,2012-06-16T09:06:01Z+0100,2012-06-18T23:12:26Z+0100,"I've been surprised lately by the base-overhead of `Data.Vector.Vector`, as I assumed it to be somewhere near 4+N words, but it was actually more like 9+N words or so for N < 128, which is a lot on 64bit archs.

IMHO, it's helpful to be aware of the cost-model in advance, instead of having to find out the hard way via heap-profiling... :-)",hvr
4,Active Tickets,65,Provide a invidual-item update action in mutable vector API,None,,0.10,enhancement,,new,2011-10-27T15:56:15Z+0100,2012-03-15T17:49:53Z+0000,"One of the operations I've caught myself defining is an `update` action for modifying an invididual item in a vector, i.e.: 
{{{
#!hs
import qualified Data.Vector.Unboxed.Mutable as VUM

update vec idx op = VUM.write vec idx . op =<< VUM.read vec idx
}}}

Could such a convenience operation (unless it's already there) be added to the mutable vector APIs?",hvr
3,Active Tickets,91,Replace handwritten instances of Typeable with deriving when GHC is higher than 7.6,None,,,defect,,new,2013-01-18T04:39:34Z+0000,2013-02-12T11:51:44Z+0000,"Jose Pedro Magalhaes posted below message to cvs-ghc.

{{{
I'm attaching a patch to the vector package to make it derive Typeable
instances instead of defining them manually. GHC HEAD will soon ignore
handwritten Typeable instances, so this replacement is necessary.
}}}

  http://www.haskell.org/pipermail/cvs-ghc/2012-November/078644.html",shelarcy
4,Active Tickets,93,scanl1 etc. fail on empty vector,None,,,defect,,new,2013-04-30T01:58:46Z+0100,2013-04-30T01:58:46Z+0100,"The following program throws an exception:

{{{
import Data.Vector as V

main = print $ V.scanl1 (&&) V.empty
}}}

But I think it should print ""fromList []"". scanl1 from Data.List behaves this way, for example.

{{{
Prelude Data.List> scanl1 (&&) []
[]
}}}",akio
5,Active Tickets,12,Simplify Eq and Ord instances,None,,,task,,new,2010-04-22T17:55:42Z+0100,2010-04-22T17:55:42Z+0100,"We can simplify them when we drop support for GHC 6.12.

This is what they should look like:

{{{
instance (..., Eq a) => Eq (Vector a) where
  {-# INLINE (==) #-}
  (==) = Data.Vector.Generic.eq

instance (..., Ord a) => Ord (Vector a) where
  {-# INLINE compare #-}
  compare = Data.Vector.Generic.cmp
}}}

This works fine with 6.13 but result in atrocious code with 6.12 which
essentially ignores the INLINE pragma. The workaround is this:

{{{
instance (..., Eq a) => Eq (Vector a) where
  {-# INLINE (==) #-}
  xs == ys = Stream.eq (G.stream xs) (G.stream ys)

  {-# INLINE (/=) #-}
  xs /= ys = not (Stream.eq (G.stream xs) (G.stream ys))

instance (..., Ord a) => Ord (Vector a) where
  {-# INLINE compare #-}
  compare xs ys = Stream.cmp (G.stream xs) (G.stream ys)

  {-# INLINE (<) #-}
  xs < ys = Stream.cmp (G.stream xs) (G.stream ys) == LT

  {-# INLINE (<=) #-}
  xs <= ys = Stream.cmp (G.stream xs) (G.stream ys) /= GT

  {-# INLINE (>) #-}
  xs > ys = Stream.cmp (G.stream xs) (G.stream ys) == GT

  {-# INLINE (>=) #-}
  xs >= ys = Stream.cmp (G.stream xs) (G.stream ys) /= LT
}}}

Ugly, but it works. This also requires the package (but not necessarily the
clients!) to be compiled with -fno-method-sharing.
",rl
4,Active Tickets,95,Some tuple elements not unboxed in certain cases,None,0.7,,defect,,new,2013-06-07T02:12:27Z+0100,2013-06-07T02:12:27Z+0100,"For the code below, the append function doesn't unbox the third element of the tuple.


{{{
{-# LANGUAGE BangPatterns #-}
module Test
where
import Data.Vector.Unboxed.Mutable as MU
import Control.Monad.ST as ST
import Control.Monad.Primitive (PrimState)

data Snakev s = S {-# UNPACK #-}!Int
                                !(MVector (PrimState (ST s)) (Int,Int,Int))

append :: Snakev s -> (Int,Int,Int) -> ST s (Snakev s)
append (S i v) x = if i < MU.length v then MU.unsafeWrite v i x >> return (S (i+1) v)
                   else MU.unsafeGrow v (2 * (MU.length v)) >>= (\y -> MU.unsafeWrite y i x >> return (S (i+1) y))

gridWalk :: Snakev s -> Int -> ST s (Snakev s)
gridWalk snakesv !k  = do
   append snakesv (k,k,k)

}}}

If the tuple is of two elements, it is not unboxed at all. For three and four element tuples that I tried, the last element is always unboxed unless explicitly forced through a bang pattern like !@x(_,_,!_). The core for `append` wrapper function has this function signature:


{{{
$wa
  :: forall s.
     Int#
     -> MVector (PrimState (ST s)) (Int, Int, Int)
     -> Int#
     -> Int#
     -> Int
     -> State# s
     -> (# State# s, Snakev s #)

}}}

Not sure if this is GHC bug, or something specific to vector library implementation. So, I am filing it here first. I noticed that I need unsafeGrow function in else block to reproduce the issue. 

I am using version 0.10, with ghc 7.6.1",sanketr
4,Active Tickets,5,Specialise enumFromThenTo,None,0.6,,enhancement,,new,2010-04-18T18:01:11Z+0100,2011-08-17T23:55:17Z+0100,Downgrading since nobody has complained about this so far.,rl
4,Active Tickets,3,Support recycling in zipWith*,None,0.5,,enhancement,,new,2010-04-18T17:54:26Z+0100,2010-04-21T03:10:35Z+0100,,rl
2,Active Tickets,78,takeWhile and dropWhile always copy,None,0.7,,defect,,new,2012-02-24T08:05:17Z+0000,2012-03-12T22:51:51Z+0000,The docs say that they don't.,rl
3,Active Tickets,81,unstreamM is not exposed,None,,,enhancement,,new,2012-08-13T17:41:37Z+0100,2013-02-27T05:13:38Z+0000,It's not possible to write custom monadic functions subject to stream fusion without it. (e.g. zipWith3M). Are there any reasons not to expose it?,Khudyakov