Release plan for 0.13

[Shimuuar]

Here is list of issues that need to be fixed before 0.13 release. I only list breaking changes and omit things that could be added to 0.13.1, etc.

• Split streams into separate package Separate streams into a separate package #355
• Decide what is best way to expose constructors for vectors. It have been requested numerous times: Export data constructor for boxed vector #245, Nowhere seems to export the constructor to Storable vector #343, Feature Request: Make underlying representations accessible #171, add Vector (a,b) -> (Vector a, Vector b) et al to Unboxed Vector and MVector #63 (tangentially related), Vector.Unboxed doesn't export constructors, but Unboxed.Mutable does #49. It's of course totally unsafe. Still it's very useful to have on occasion
• Determine semantics of slice/grow/etc semantics of slice, now and future (plus near term bug fixes) #276, Semantics of grow/unsafeGrow #36. Likely it's going to be a documentation change but it's better to do this for 0.13 just in case.
• unfoldrN, unfoldrNM and fromListN are dangerous unfoldrN, unfoldrNM and fromListN are dangerous #301. Could require change to semantics of functions.
• The Bundle datatype seemingly doesn't need the field sVector The Bundle datatype seemingly doesn't need the field sVector #269. Not terribly important but certainly breaking
• decide semantics of maximumBy & friends

[lehins]

We'll hold off on #269 it might be useful to keep sVector afterall.

[lehins]

I'd like to communicate who's going to be working on which tickets so we don't start stomping on each other's feet.

I'll can tackle the #36 now, since I recently had to deal with those semantics.

I already mentioned it on a ticket, but I'll be happy to do the split described in #355

With regards to #276 I could take care of it too, since I was involved in that discussion and also fixed the original issue with slice in #257, however it would be great to get another pair of eye on the issue, so maybe someone else can pick it out.

#306 I suggested a solution: #301 (comment) which is the approach I've taken in massiv, so if someone would like to implement and document it, that'd be great.

With regards to exporting constructors, I'd go for adding these modules:

module Data.Vector.Internal
module Data.Vector.Primitive.Internal
module Data.Vector.Storable.Internal
module Data.Vector.Unboxed.Internal

that have {-# OPTIONS_HADDOCK hide, not-home #-}

An easy way would be to simply re-export constructors from there or the hard way of moving constructors with all the instances into those module in order to avoid orphans. Former seems a bit less intrusive. This one is also up for the taking.

[lehins]

On a second thought it might be a good idea to move all of the unsafe functions into their own modules, which would also include constructors.

module Data.Vector.Unsafe
module Data.Vector.Primitive.Unsafe
module Data.Vector.Storable.Unsafe
module Data.Vector.Unboxed.Unsafe

I do think that it would be a good way to promote distinction between safe and unsafe function usage. I never liked that functions like unsafeIndex are in scope by default. We could even use the Safe/Unsafe/Trustworthy Haskell extensions ;)

However, this would be a serious breaking change, so we would have to do it over multiple major releases. @Shimuuar and @Bodigrim if that is something you think is worthwhile to discuss we could start a separate issue and possibly kickoff a discussion on libraries?

[Bodigrim]

We could even use the Safe/Unsafe/Trustworthy Haskell extensions ;)

Please no %)

if that is something you think is worthwhile to discuss we could start a separate issue and possibly kickoff a discussion on libraries?

Yes, such change deserves a discussion on libraries and CLC.

[Shimuuar]

I like idea of Unsafe modules. Adding them is not a bit problem, deprecation and removal of unsafe functions is. Should we have one unsafe module for boxed/unboxed/storable/etc vectors? Or should we add two one for mutable and one for immutable API. I don't remember whether there're name clashes but usually mutable and pure vectors are imported in different namespaces. This is argument for two modules. I don't like clutter though. It's also possible to not bother with reexports for unsafe API and only export generic variants.

Then there's question of finding all unsafe functions. Some seemingly benign functions will happily trash memory given incorrect inputs (see #118) as example

[lehins]

@Shimuuar I've started a new issue for this topic: #361

Some seemingly benign functions will happily trash memory given incorrect inputs

This means that the functions is unsafe and should be named with unsafe prefix, so it's a bug. We definitely should find all such functions. But that is a separate task, albeit a relevant one.

[lehins]

It has been over a year since we planned a major release, I think it is time we get it done. It is ok if we can't get all of those features we wanted in, a lot has been accomplished sine 0.12 version.

I am setting a timeline two weeks from today to cut a release. @Shimuuar and @Bodigrim please speak up if you have any objections.

[Bodigrim]

No objections from my side.

[Shimuuar]

Strongly agree. 0.13 is long overdue

[lehins]

I've prepared a release here in #437

One thing that was not checked in the release plan was the exporting of constructors. I think this problem is solved now:

• Boxed and Storable vectors have conversion functions that allow going back and forth between internal representation
• Primitive was always exported
• Unboxe was also always exported, except from the hidden module Data.Vector.Unboxed.Base

I think we are good for a release. If no one has any comments I'll merge the PR and make a release this week.

[lehins]

vector-0.13.0.0 is out.