Is there anything wrong with increasing the context stack? That's what I do when I run into an overflow, and so far I haven't had any problems with it.

Generally my uses of FixedList involve relatively short lists (vectors and such) so it usually isn't a problem. 

I could implement a more sophisticated way to keep track of the list lengths that doesn't have this problem, but I really like the simplicity of the current implementation.

- Job

On Sun, Mar 21, 2010 at 2:37 AM, Casey McCann <syntaxglitch@gmail.com> wrote:
Job Vranish <job.vranish@gmail.com> wrote:
> Its main advantages are:
>  Very easy to use.
>  Almost entirely Haskell98 (the non Haskell98 pieces are not critical, just
> nice)
>  The datatype is a member of  Foldable, Traverable, Applicative, Monad,
> etc...
>  Then length of the list is encoded in the type in a natural way.

Unfortunately, it's very easy to get a context reduction stack
overflow from GHC this way, which makes using such datatypes awkward
for anything but very short lists. Explicit type annotations will
often make things work, but at that point the type class isn't helping
you anyway. For example, assuming the default stack size:

import Data.FixedList

fixed18 :: FixedList18 Int
fixed18 = fromFoldable' [1..] -- this works

fixed20 = 20 :. 20 :. fixed18 -- this works

fixed22 :: FixedList22 Int
fixed22 = 22 :. 22 :. fixed20 -- this only works with a type annotation

show18 = show fixed18 -- this works

-- this doesn't work:
-- show20 = show fixed20

show20' :: FixedList20 Int -> String
show20' list20 = show list20

show20 = show20' fixed20 -- this does work

Using head and tail on longer lists fails likewise. I expect there's
some way to make it work without simply increasing the stack depth,
but I'm not sure how. Any thoughts?

- C.