4 ms·
Actually Haskell does have some dependently typed features (and is being extended constantly). The reason it isn't used in that particular package is a mystery
by nightski 12y ago
Actually Haskell does have some dependently typed features (and is being extended constantly). The reason it isn't used in that particular package is a mystery, except that a lot of these things are very new and Haskell is an evoloving ecosystem. That particular package simply may not have a release that uses all the latest GHC features.
Repa for instance does provide type errors based on dimensionality of matrices. This is a package on Hackage.
See http://www.haskell.org/haskellwiki/Numeric_Haskell:_A_Repa_Tutorial http://www.haskell.org/haskellwiki/Numeric_Haskell:_A_Repa_T...
- seanmcdirmid 12y agoDimensionality is easy, its the lengths of these dimensions that are hard. E.g. you can multiply n by k, k by m matrices to get an n by m matrix, but anything else is a type error. In Bling, I had Matrix<LN,LK> * Matrix<LK,LM> => Matrix<LN,LM>, where LN,LK,LM are type parameters up to around 10 (L0, L1, ..., L10, enough to do 3D graphics, mostly, but wouldn't work for HPC where lengths are much longer and diverse). Looking at the linked page, extent isn't a part of a matrix's type signature, so it would be checked dynamically, correct?
- freyrs3 12y ago> you can multiply n by k, k by m matrices to get an n by m matrix, but anything else is a type error. This is exactly how Repa works, it uses a Peano encoding of the extent of dimensions to make invalid array operations inexpressible.
- seanmcdirmid 12y agoOk. This isn't obvious at all by looking at the documentation, also since extent doesn't seem to appear in the type signature of a matrix instance.
- deleted 12y ago[deleted]
- seanmcdirmid 12y agoAh, this is exactly the approach I took in C# (though with a small range of branded types to stand in for numbers). Thanks for clearing this up!