Henning Thielemann wrote:

On Wed, 11 Jun 2008, Isaac Dupree wrote:

"extractHead" is an ugly name for a nevertheless standardish-meaning function... what is it usually called? uncons? headTail? (Data.Sequence, which is meant to be left-right symmetric, calls it "viewr"... except your version doesn't have the Maybe, it's partial instead, fails on empty lists)

I like the 'viewL' and 'viewR' kind of functions, they are safer than 'head' and 'tail', 'init' and 'last'. But since in most cases I used 'viewL' in connection with 'maybe', the continuation style functions

switchL :: b -> (a -> Seq a -> b) -> Seq a -> b
switchR :: b -> (Seq a -> a -> b) -> Seq a -> b

I think you got L and R backwards? it's a little confusing to me, but following Data.Sequence I think they're meant to match whether repeated L or R makes a foldl or a foldr.

are even more convenient. They replace 'case' on those structures where you do not have access to the constructors.

on the other hand, they look harder to use with the upcoming (in GHC 6.9/6.10) "view patterns", a simple example being

foo (viewr -> Nothing) = ...
foo (viewr -> Just (a, as)) = ...

equivalent to

foo s = case viewr s of
  Nothing -> ...
  Just (a, as) -> ...

(for view patterns, it's also proposed but not implemented to have special syntax for Maybe and/or tuples to make it even more convenient for these purposes... I'm not sure if it'd be a good idea either)

I also mentioned the continuation style functions for Data.Map's maybe-returning in the discussion... they're most convenient if you want to destruct them right away, but harder to apply combinators to (e.g. Maybe monad. which doesn't work for Data.Sequence because they use their own custom view datatype -- was that a bad choice for them? "Maybe" of a tuple has an extra laziness-spot that shouldn't really be there, though) Anyway, people didn't seem to respond to that idea of continuation-style returning, not sure why. On the other hand, also, the only thing defending the function from using the arguments in a way it shouldn't, is parametricity... less obvious than with algrebraic data returns

-Isaac
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to