Use an external VectorSpace

[turion]

Following the philosophy that dunai has to be slim, VectorSpace should really be a dependency. If there is no slim package supplying us with vector spaces, we should fork one.

This is not an API change or API addition, and its not urgent.

[ivanperez-keera]

This is an API removal. It would impact the version major, and show go in release 0.3.

[ivanperez-keera]

By the way, this implementation of vector-space, which I wanted to use for Yampa in the past, also depends on void.

Of course there's linear, but that just depends on half the universe.

Are there any simpler alternatives? If not, I'm happy externalising dunai's vector-space and moving forward with this.

Since I'm not an expert in vector spaces, can I ask: what are the key differences between the two? If any of those differences actually "define" or are fundamental to this implementation, then they could help find a suitable name for this library.

[ivanperez-keera]

(Again, I'm happy depending on vector-space, so long as it does the job, is well maintained, and does not depend on TH.)

EDIT: Grammar

[turion]

I think linear is not the right package for us. vector-space sounds good. It depends on template-haskell at some point though: vector-space -> void -> semigroups -> tagged -> template-haskell.

Then I propose to fork vector-space without the dependency on void, and to use that in Dunai.

[turion]

Looking into this further, void doesn't even depend on semigroups for GHC >= 7.9. So an even more elegant solution would be to deprecate GHC < 7.9 and use vector-space and void.

[ivanperez-keera]

Ok. So, we can then delay this until 7.8 can be deprecated, and then this will naturally fall into place.

[turion]

What is needed to deprecate 7.8? Is there anything I can do? (E.g. porting existing apps to 7.10?) Should we open a separate issue?

[ivanperez-keera]

Unfortunately, no. But thanks. It's just a matter of patience.

[ivanperez-keera]

Following a discussion in http://mailman.cs.yale.edu/pipermail/yampa-users/2018-October/000478.html, it seems like we cannot depend on an existing vector-space/linear for now, but we can externalize Yampa's, find the common factor with dunai, and at least not have it in Dunai/Yampa.

See: https://github.com/ivanperez-keera/Yampa/tree/develop-externalvectorspace and https://github.com/ivanperez-keera/simple-affine-space

[ivanperez-keera]

I've been wanting to see this completed for a long time. I tried to tackle it a couple of times, but couldn't (that's why I suggested documenting it first).

The vector-spaces in Yampa have been externalized. If we could at least move whatever we have in Dunai that fits into simple-affine-spaces over there and remove our Data.VectorSpace module, that'd be great.

[ivanperez-keera]

This issue has been closed by picking one external package that was created from Yampa, and re-defining instances based on that.

The long term plan is still to use a different library, but I am unhappy about the use of TH in linear and vector-space. @Linearity is using linear, but @turion suggested vector-space. The former supports disabling TH, but then it depends on a lot of packages.

Therefore, and as a means to move forward, and to close another issue #172, I have picked. If things are really bad, we can always re-introduce what's missing (maybe re-introduce it in https://github.com/ivanperez-keera/simple-affine-space if possible).