> They can be useful for certain constructions, but they don’t really enable anything amazing that you can’t do otherwise, just with a slightly different algorithm.
One really nice property of laziness is dealing with data larger than RAM. A couple of months ago I wrote some ML processing of the wikipedia XML in Clojure. In about 5 lines, I had a lazy sequence of every <Article> tag from the XML. Then I can (map my-fn all-articles-from-wikipedia), without blowing the heap (the wikipedia XML was like ~10GB, zipped).
Yes, it's possible to do non-lazy, but this was cleaner and simpler.
One algorithmic advantage of lazy seqs is that (map foo (map bar (map baz my-big-seq))) makes only one pass over the data, as opposed to 3 when non-lazy.
+1 Allen, great example! I also have a side project where I am making multiple sweeps thought the wikipedia XML data. I did this in Ruby using a streaming XML parser, but I am going to try your approach.
Historical note: FSet was inspired by a language called Refine, which was in turn inspired by SETL, created in the late 1970s at NYU. As far as I know, SETL was the first language to have functional collection types (does anyone know for sure?).
Anyway, some of the operation names used in FSet -- 'with', 'less', and 'arb', for example -- can be traced back to SETL.
SETL also appears to have been the first language with what are now called "comprehensions" (it used the term "formers") to construct collections declaratively. For example,
{ x ** 2 : x in {1 .. 5} }
would produce a set of the squares of the integers from 1 through 5. (Does anyone know of an earlier language with these?)
A bit off topic, but I found the radioactive syntax highlighting and bold-everything in the code samples extremely distracting and hard to read. I would recommend sticking to dark-on-light code when it’s in the middle of dark-on-light text.
One really nice property of laziness is dealing with data larger than RAM. A couple of months ago I wrote some ML processing of the wikipedia XML in Clojure. In about 5 lines, I had a lazy sequence of every <Article> tag from the XML. Then I can (map my-fn all-articles-from-wikipedia), without blowing the heap (the wikipedia XML was like ~10GB, zipped).
Yes, it's possible to do non-lazy, but this was cleaner and simpler.
One algorithmic advantage of lazy seqs is that (map foo (map bar (map baz my-big-seq))) makes only one pass over the data, as opposed to 3 when non-lazy.