[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
returns
-Isaac
More information about the Haskell-Cafe
mailing list