I rather like this version. It avoids needlessly holding onto the entire list from the start, unlike the original version, which is leakier, and avoids the unnecessary strictness problem of the second version.

We should definitely keep the original in a comment as a description of the meaning of the operator, with an explanation of the change, though, as the road here is rather convoluted, and to Andreas' point it is far easier to understand even if it has undesirable garbage collection properties.

-Edward

On Tue, Jun 5, 2018 at 3:00 AM, Chris Wong <lambda.fairy@gmail.com> wrote:

The proposed definition has one drawback: it is strict in its second argument.

It should be possible to make it lazy in its second argument while keeping the single-pass behavior, though. Something like this?

ZipList xs <|> ZipList ys = ZipList $ go xs ys 0
where
go [] ys n = drop n ys
go (x:xs) ys n = x : (go xs ys $! n + 1)
On Tue, Jun 5, 2018, 15:36 박신환 <ndospark320@naver.com> wrote:
Current definion of (<|>) for ZipLists:
ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)

doesn't work if the left argument is infinite. It should be:

ZipList []     <|> ys             = ys
xs             <|> ZipList []     = xs
ZipList (x:xs) <|> ZipList (_:ys) = ZipList (x : (ZipList xs <|> ZipList ys))
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries