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 <syntaxgli...@gmail.com>wrote: > Job Vranish <job.vran...@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. >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe