You can clone with
HTTPS or Subversion.
There is a dependency on the time library to for the toDiffTime and fromDiffTime functions. The functions are trivial enough that the dependency probably isn't justified. I propose removing the dependency.
(We could keep the functions with the same name but relax the types to any Real/Frac instead of DiffTime. The intent would hopefully be clear, but not enforcing it with the type is a bit iffy.)
I'm also not a big fan of those functions. I think it is a good idea to take them out, and I would suggest that we also take out the temperature ones too.
They are pragmatically useful enough, but it feels like they are at a significantly different level of abstraction than the rest of the module that they live with.
With a lot of these things, the question is how granular do we want the packaging to be. Do we want one dimensional-extras that brings in ad, time, vector (for #23), etc. Or do we want dimensional-time, dimensional-ad, dimensional-torsor, ...
I can see merits to both approaches, so I haven't bothered choosing yet. In fact I am thinking of making a road map diagram after work that lists out all the things I want so I can have something to go on when deciding where to put them.
I did start making a package for linear algebra that is a dimensional-dk flavored variant of the work that Adam Vogt and I had been doing. I am pretty sure he wants to take a different direction because he wants better "reverse-direction" type inference, but to me it feels like it very quickly becomes too complicated, and you end up stuck with types that you can't quite prove to the compiler are the ones you want. But I am having trouble getting either of my machines to have both hmatrix and ghc 7.8 on them at the same time, so it is slow going at the term level.
Remove time dependency. Issue #30.
I don't feel strongly about one -extras versus many packages. For development convenience we could have a -experimental (which, if published on hackage, people could rely on at their own risk). Once we feel areas are reasonably mature we could pull them into their own package with minimized dependencies (e.g. -time).
Would now be a good time to start looking closer at your linear algebra package (assuming I could find the time), or is it still in too much flux?
Good idea, let's make an -experimental one so we can get things down on "paper" even if they are half-baked. Do you want to or should I?
I think it would be a decent time to look at the (types of) the linear algebra package. Adam's DimMat that we were working on shows that the term-level side of this can work, I just can't seem to successfully install GHC 7.8 and hmatrix on the same machine. Adam is putting a lot of emphasis on bidirectional type inference, which in my opinion isn't really necessary and is very complicated. (I might be wrong.) However the general idea is right.
I've been making a dimensional-dk flavored version at (name subject to change if you want) https://github.com/dmcclean/dimensional-dk-linalg.
I would say the place to start is definitely https://github.com/dmcclean/dimensional-dk-linalg/blob/master/Numeric/LinearAlgebra/Dimensional/DK/Shapes.hs (which GitHub makes a hash of syntax highlighting, because it doesn't understand the DataKinds rule about ' as a prefix to distinguish type constructors from data constructors). Then the .Internal module shows how the term-level operations can be typed, using the .Shapes module for all the type manipulations.
Not even close to practical use yet, but see if you think the types are heading in the right direction.
(Term-level development of this is probably mostly on hold until 7.8 proper gets released, focusing on other things where I can get more traction.)
I've created the https://github.com/bjornbm/dimensional-dk-experimental repo and added you as a collaborator which should give you commit/push rights. I'm relinquishing my editorial privileges on this one so feel free to experiment away! :)