Sean Leather wrote: >> Why not use the dlist library: >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist >> >> With something like (untested code): >> >> > xs +++ ys = shows xs `append` shows ys >> > x .++ ys = showChar x `cons` shows ys >> > xs ++. y = shows xs `snoc` showChar y >> > >> > ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')' >> > > I think you're missing the fromList parts among other things.
Ah yes, dlist uses a newtype instead of an alias so `shows` isn't enough. There's also the question of where exactly to hide the (Show a => a -> DList Char) conversions if you want to be more succinct than the (++) route. > That's an interesting idea. It appears to use the same idea as ShowS, but > more generally with lists and not just strings. The difference-list approach to solving the appending problem is classic. There's a variant for unification-based logic languages as well. Both are functional takes on the imperative approach of keeping a tail pointer. Dons just took the time to package it up for us all :) > I think there's an added benefit to not having to remember the the type of > the value being appended. It's one of the more convenient things about many > dynamically typed languages. So, I would still vote for the class-based > method, so that I can use (.+.) for both Char and everything else. Sure. If you're planning on releasing the code, I'd suggest a different spelling of (.+.) though. The (.X.) pattern for a family of operators is pretty common, so it's good to avoid it for modules that want to be used in combination with many others. YMMV and all that. -- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
