Back to Questions
1.4k
views7
comments
LazyList
f#

Why is the LazyList collection no longer in the core set of collections

.

Hi there

The recommendation is to use the Seq type and module instead.

Thanks

Don

By on 8/22/2008 9:29 PM ()

May I ask why it is the recommendation? To my knowledge the only real difference between a LazyList and a Seq is that one caches its results and the other one streams. LazyLists also lend themselves very well to tail recursive algorithms as you can hand the rest of a list to be processed to your recursive call. I know you can make the argument that most if not all use cases of recursion can be covered by all higher order functions provided in the Seq module, but the Devils Advocate in me is looking for a much stronger reason to use Seq instead of LazyList.

By on 8/23/2008 8:17 AM ()

To my knowledge the only real difference between a LazyList and a Seq is that one caches its results and the other one streams.

Yes, but Seq has the Seq.cache function, and you can often use it to replace a LazyList. I don't know if there's a stronger reason.

Laurent

By on 8/23/2008 3:02 PM ()

Seq (IEnumerable) is a unifying notion on the .NET platform. All collection types (List, Array, ResizeArray, System.Collections.Generic.* and every .NET collection written by any other programmer) supports the IEnumerable<T> interface.

Thus Seq is a fundamental tool in the F# programmer's arsenal.

Thanks

don

By on 8/24/2008 12:53 PM ()

FWIW, my reply wasn't meant to mean you shouldn't use a a thunking sequence when appropriate - they use cases for thiunking sequences you mention are valid. :-)

However I hope my reply rxplained why "Seq" tends to be the first port of call for on-demand streaming data for the F# programmer, and why we've given it priority in the F# library. If you feel that, in the balance, it is important that the library support both types, we'd be glad to take that feedback and look at the issue again. Note we've also received strong feedback that the presence of both concepts in the library with their existing naming leads to confusion, though there are always tradeoffs of this kind in library design.

Kind regards & thanks

Don

By on 8/24/2008 1:16 PM ()

Thanks for the valuable insight on the differences between Seq and Lazy List. However I do have one other question to ask, If LazyList's accomplish their caching by thunking how does Seq.cache function accomplish its ability to cache results. I gather from your last response that it might accomplish its caching differently. I will dive into the source included in the dist but in case I dont find it would you mind sharing how seq.cache accomplishes its caching.

By on 8/25/2008 2:41 PM ()

Hi again

As you've probably found out by now, Seq.cache caches the sequences in a ResizeArray (protected by locks in case there are multiple iterators). A thunking lazy list effectively caches in a linked list. The former is considerably more memory efficient but has different data lifetime properties: if you "let go" of the sequence but still retain any live iterators then the whole ResizeArray is still live: it's all-or-nothing. With a linked list you can let go of the head and retain a pointer to a suffic and the initial elements will be collected.

Some problems (e.g. computing an infinite sequence of primes) can have very nice solutions using the lazy list approach. However in practical coding with data streamed from data sources such as files or databases, Seq.cache is usually sufficient if any caching is needed at all, or else some other caching strategy (e.g. buffer-at-most-100-elements or the like) works well.

By on 8/28/2008 5:11 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper