Give examples of things which are SemiOrderedContainer's but not OrderedContainer's

[ndmitchell]

As it stands, things like cons, snoc and sortBy are all in SemiOrdered, but seem to require ordering... Examples of where Set's (for example) live would be useful.

[ndmitchell]

Note that null and length are in different classes, which looks very dodgy.

[ndmitchell]

Maybe the key point about the more powerful contain is that it is indexed by some separate key?

[vincenthz]

Ordered is just that the contained preserve the order of element relatively to their insertion, it doesn't mean sorted. I couldn't find a less confusing name

Semi is loosely related to the semigroups thing, for example NonEmpty list. I got the idea to distinguish operations that could remove data and make container empty from mono-traversable, i.e. it could be useful in the future..

I think Set and Map wouldn't be represented by any of those containers: order are not preserved, and can't have duplicated value. I need to put all those characteristics-per-containers down on papers to make sure they are properly abstracted.

I also agree null and length are currently dodgy; Need to think how Foldable plays a part in all this.

[ndmitchell]

Perhaps you are biting off more than you can chew? Having an abstraction over Vector/MVector/UVector/MUVector/List/Chunks/String is really handy, and they are all truly isomorphic. In contrast, the division you've picked here sounds like it needs more thought and practical use before it turns into a real API...

[vincenthz]

yes, definitely biting more than chewable, but need to have dreams :-)

I think to think of some reasonable segmentations between different containers, trying to not go overboard, and yet think of something that has some added value.

[ndmitchell]

Is Foundation going to have a Map/Set data types? If not, having types to abstract over them seems weird, since you are really just abstracting over contiguous 0..N Int indexed data structures - for which a nice API is pretty trivial.

[vincenthz]

I think Map/Set/Hashtable would be useful to have built-in

[ndmitchell]

Notes from the train:

Indexed k v


instance Indexed 


class Indexed c k v | c -> k v where


instance Indexed (Array a) Int a where

instance Indexed String Int Char where

lookup :: c k v -> k -> Maybe v


zip :: (Indexed c1, Indexed c2, Indexed c3, Key c1 ~ k1) => c -> c -> c


zip :: (Indexed c1 k v1, Indexed c2 k v, Indexed c3 k (v1, v2)) => c1 -> c2 -> c3


zipWith :: (Indexed c1 k v1, Indexed c2 k v2, Indexed c3 k v3) => (v1 -> v2 -> v3) -> c1 -> c2 -> c3


replicate :: Indexed c Int a => Int -> a -> c

replicate :: Indexed 

append :: Indexed c Int a => c -> c -> c


keys :: 

values


elems :: c -> [v]

class Indexed c k v where
    fromIndexed :: c -> [(k,v)] -- each k is unique
    toIndexed :: [(k,v)] -> c
    ...
    take :: Ord k =>
    replicate :: Enum key => 
    lookup :: Eq k => 
    find
    length 
    singleton
    sortBy :: Ord k => 
        let (ks,vs) = unzip $ toIndexed c
        in zip ks $ sortBy f vs
    reverse :: Ord k => 
    union :: 


instance NotSequential 
    union
    intersection

    mapWithkey 

    intersect 


instance Sequential [v] v

-- NO -- instance Indexed [(k,v)] k v where

[_]

class Indexed c Int k => Sequential c v where
    fromSequence :: c -> [v]
    toSequence :: [v] -> c
    ...
    append -- mappend
    snoc
    cons


take :: (NatIndexed c v) => Int -> c k v -> c k v
take n = toIndexed . List.take n . sortOn fst . fromIndexed


append :: (Sequential c v) => c -> c -> c

take 2 "abc" = "ab"



drop :: Ord k =>