plaidfinch / comonadsheet

A library for expressing "spreadsheet-like" computations with absolute and relative references, using fixed-points of n-dimensional comonads.

hi, i'm finch.

comonadsheet's Issues

Building on ghc 7.10: "Not in scope : [...] 'NestedCount'"

Just for kicks I updated ghc to 7.10 and base to 4.8. Possibly for good reason, ComonadSheet, Tape, IndexedList, and NestedFunctor had build-depends restrictions ">= 4.7 && < 4.8". I changed them and everything but ComonadSheet builds fine manually. I've made sure that they were installed globally, etc, and that I can include them in other code in other projects.

However, when building ComonadSheet, I get the following output. Short version is NestedCount isn't visible where it should be.

I'm hunting for where NestedCount is defined and will submit a pull request or two if it all goes well.

Details: OS X 10.10, ghc 7.10.1.

Dead package?

Hi Kenneth; I recently watched your talk on ComonadSheet and loved it!

I'm learning a lot about fixed points, and I'm currently working on a problem which could make great use of this library; any chance that this will ever be resurrected? If not, any tips for possible replacements? Thanks!

Hope things are going well!

Representation of indices can lead to nonsense

Consider multidimensional spreadsheets. This applies to all higher-dimensional spreadsheets, but we'll examine Z2 here.

We have the following type for two-dimensional zippers:

newtype Z2 c r a = Z2 { fromZ2 :: Z1 r (Z1 c a) }

As such, the column (c) index of each inner Z1 c a is independent. This means that we can do the following:

> let x = pure () :: Z2 Int Int ()
> let y = wrapZ2 (modify zipR) $ x
> col y
1
> col $ zipU $ y
0

This enables us to break an expected invariant of movement in spreadsheets:

> index $ go (atCol 0) y
(0,0)
> index $ go below . go (atCol 0) . go above $ y
(-1,0)

Proposed solution:

Use a new non-indexed list zipper type, and have Z1, Z2, etc. defined in terms of the product of an n-tuple with an n-nested unindexed zipper. This means that there will be a single canonical value for each dimension's index, which means that it will be impossible to break this kind of invariant. This will require significant refactoring, but seems doable.

Documentation on Hackage has broken links

Example

I mean, I don't feel entitled to anything since this is free and also a really incredible library, but fwiw the haddock documentation would be a little more convenient than reading through the source.

CombineRefs can be more thoroughly exclusive.

At present, you have

data RefType = Relative | Absolute

type family Combine a b where
   Combine Relative Absolute = Absolute
   Combine Absolute Relative = Absolute
   Combine Relative Relative = Relative

-- | Combine @Ref@s which can be meaningfully combined. Note the absence of the absolute-absolute case; there's no
--   good meaning for combining two absolute references, so it is statically prohibited.
class CombineRefs a b where
   combine :: Ref a -> Ref b -> Ref (Combine a b)
instance CombineRefs Absolute Relative where
   combine (Abs a) (Rel b) = Abs (a + b)
instance CombineRefs Relative Absolute where
   combine (Rel a) (Abs b) = Abs (a + b)
instance CombineRefs Relative Relative where
   combine (Rel a) (Rel b) = Rel (a + b)

It's possible to write a bogus instance

instance CombineRefs Absolute Absolute where
  combine (Abs _) (Abs _) = undefined

because Combine Absolute Absolute is not considered an invalid type, per se, but rather "stuck". It is inhabited only by bottom.

You can make this instance impossible by writing something like

class Sane (a :: RefType)
instance Sane Relative
instance Sane Absolute
class Sane (Combine a b) => CombineRefs a b where ...

While Combine Absolute Absolute has kind RefType, it is now impossible (without OverlappingInstances) to make it an instance of Sane (because the only instance that would include it would be instance Sane a), and therefore impossible to make the bogus instance.