obsidiansystems / dependent-map

Dependently-typed finite maps (partial dependent products)

dependent-map

This library defines a dependently-typed finite map type. It is derived from Data.Map.Map in the containers package, but rather than (conceptually) storing pairs indexed by the first component, it stores DSums (from the dependent-sum package) indexed by tag. For example

{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
module Example where

import Data.Constraint.Extras.TH (deriveArgDict)
import Data.Dependent.Map (DMap, fromList, singleton, union, unionWithKey)
import Data.Dependent.Sum ((==>))
import Data.Functor.Identity (Identity(..))
import Data.GADT.Compare.TH (deriveGCompare, deriveGEq)
import Data.GADT.Show.TH (deriveGShow)

data Tag a where
  StringKey :: Tag String
  IntKey    :: Tag Int
  DoubleKey :: Tag Double
deriveGEq ''Tag
deriveGCompare ''Tag
deriveGShow ''Tag
deriveArgDict ''Tag

x :: DMap Tag Identity
x = fromList [DoubleKey ==> pi, StringKey ==> "hello there"]

y :: DMap Tag Identity
y = singleton IntKey (Identity 42)

z :: DMap Tag Identity
z = y `union` fromList [DoubleKey ==> -1.1415926535897931]

addFoo :: Tag v -> Identity v -> Identity v -> Identity v
addFoo IntKey (Identity x) (Identity y) = Identity $ x + y
addFoo DoubleKey (Identity x) (Identity y) = Identity $ x + y
addFoo _ x _ = x

main :: IO ()
main = mapM_ print
  [ x, y, z
  , unionWithKey addFoo x z
  ]

dependent-map's Issues

Performance comparison?

How does this compare to Map from containers and HashMap from unordered-containers in terms of performance?

Allow containers-0.7

This version of containers, shipped with GHC-9.10, can also be used with older compilers. It would be nice to allow it, API changes seem to be minimal.

git tag for 0.3 is missing

support for constraints

I've added support for constraint in DSum and DMap.

type family DSumC a :: Constraint
data DSum (tag :: * -> *) (f :: * -> *) where
  (:=>) :: DSumC a => !(tag a) -> (f a) -> DSum tag f

data DMap (k :: * -> *) (f :: * -> *) where
  Data.Dependent.Map.Internal.Tip :: DMap k f
  Data.Dependent.Map.Internal.Bin :: DSumC v =>
                                     !Int -> !(k v) -> (f v) -> !(DMap k f) -> !(DMap k f)
                                     -> DMap k f

I'm needing this at my work to make a more useful map operation

Data.Dependent.Map.map ::
  (forall v. DSumC v => f v -> g v) -> DMap k f -> DMap k g

where I can do something on the v while changing the containing type

I'm not sure it is worth the bump (useful for anyone else) as I guess it will break all code around . But I'd like to know opinions before not submitting the pull request.
My stab has just deleted the Read instances, I couldn't solve the issues for that.
Hope it is interesting for someone else, because if it's not I will just use a list of modified definition of DSum with a lookup based on GOrdering which suffices for my needs (read-only , small set)

Btw, thanks a lot for this code, which I find a great approach to tackle modular software aspects

Document key bias

Data.Map always uses the keys from left arguments in preference to right ones. I can't tell what the rules are here, if there are any. I think this should either be specified or documented as unspecified. Either is fine.

Poly-kinded DMap

The error I'm getting is

        The first argument of ‘DMap’ should have kind ‘* -> *’,
          but ‘NComponent a’ has kind ‘N -> *’
        In the type signature for ‘components’:
          components :: Expr a -> DMap (NComponent a)

It was a surprise for me that DMap is not poly-kinded. Perhaps obsidiansystems/dependent-sum#3 is somewhat related.

Unmaintained

I just wanted to ask if this package is still maintained, I submitted issue #16, almost a year ago, and I didn't have any answer yet.

Thanks you, and best regards.

Bad documentation on DMap

There are a few errors on the Haddock docs for DMap.

1. Data.Dependent.Tag doesn't seem to exist.
2. The documentation refers to some f which I guess is supposed to be the k type parameter of DMap.

Stop using hedge algorithms

The master branch of containers has switched from hedge algorithms to divide-and-conquer algorithms (often with pointer equality optimizations). These algorithms have recently been proven asymptotically optimal and my tests indicate that they're a good deal faster than the hedge algorithms. As an extra bonus, they're considerably simpler and harder to mess up. I suggest you use them here as well.

Add mergeA

Data.Map has a general mergeA operation to merge two maps; I don't see any obvious obstacle to having a similar one here.

Example code from README.md doesn't compile

The example code showed in the README.md doesn't compile under the GHC version 7.10.3.

Give several errors as:

Couldn't match type ‘Char’ with ‘[Char]’
Expected type: [String]
Actual type: [Char]
In the second argument of ‘(:=>)’, namely ‘"hello there"’
In the expression: Baz :=> "hello there"
In the first argument of ‘fromList’, namely
‘[Foo :=> pi, Baz :=> "hello there"]’
/home/osboxes/Documents/Haskell-Workshop/app/Main.hs: 6, 19

No instance for (Num [Int]) arising from the literal ‘42’
In the second argument of ‘singleton’, namely ‘42’
In the expression: singleton Bar 42
In an equation for ‘y’: y = singleton Bar 42
/home/osboxes/Documents/Haskell-Workshop/app/Main.hs: 15, 20

Couldn't match type ‘v’ with ‘[v]’
‘v’ is a rigid type variable bound by
a type expected by the context: Foo v -> [v] -> [v] -> [v]
at app/Main.hs:15:7
Expected type: Foo v -> [v] -> [v] -> [v]
Actual type: Foo [v] -> [v] -> [v] -> [v]
In the first argument of ‘unionWithKey’, namely ‘addFoo’
In the expression: unionWithKey addFoo x z

Add test suite

The easiest way to get started will probably be to build a clone of most of Data.Map using

newtype Map k v = Map (DMap (Const k) (Const v))

and then just copying large chunks of the Data.Map test suite out of containers.

The same approach should also help get benchmarks started.

Consider changing the Monoid instance

Pretty much everyone hates the Monoid instance for Data.Map. If you're not too terribly opposed to potentially breaking existing code to make future users happy, you can avoid the problem here.

class Semigroup1 f where
  (<<>>) :: f a -> f a -> f a

instance (GCompare k, Semigroup1 f) => Monoid (DMap k f) where
  mappend = unionWith (<<>>)

Why is Prelude.filter reexported from Data.Dependent.Map?

It doesn't seem to belong to that module imo