[Haskell-cafe] Re: [Haskell] ANN: random-access-list-0.1

Isaac Dupree isaacdupree at charter.net
Thu Jun 12 09:47:50 EDT 2008

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 


More information about the Haskell-Cafe mailing list