http://lampsvn.epfl.ch/trac/scala/ticket/1790

def toStream[A](ls: List[A]): Stream[A] = ls match {
case hd :: tail => hd :: toStream(tail)
case Nil => Stream.empty
}

Then you could use the zip() method on either Stream.

Another (possibly better) approach for zipWithIndex would be to make use of Range:

def zipWithIndex[A](ls: List[A]) = (0 until ls.length).toList zip ls

It’s a little less efficient, but you do get a List as a result, rather than a Stream.

But I had been thinking something more simple, I wanted to combine a List with a Stream, for example to associate the items in the List with their index (I know there is a zipWithIndex but let’s forget about that one for now).

val fibs = 0 :: 1 :: fibs.zip(fibs.tail).map { case (a, b) => a + b }

It’s all lazily evaluated, so once again, no infinite recursion. I’ll be the first to admit though that this is insanely weird.

A connection is indeed opened and closed for each invocation of ancestors(). This may seem wasteful, but any connection pool is going to optimize that away. It’s fairly standard practice with JDBC (at least, with the projects I have worked on) to have very short-lived Connection objects. This keeps your database model robust, since you don’t need to worry about carrying around resources and disposing of them after the fact.

As implied above, the finally clause is executed with the ancestors() method returns. This seems to happen after a recursion, but it doesn’t thanks to the laziness of infinite lists. The recursive invocation of ancestors() doesn’t happen until we actually request the nth element of the list. This also answers your second connection question, which was “why don’t we just close it once the list is done?” The answer is that we don’t know that the list will *ever* be “done”, it is theoretically unbounded. The best we could do is let whoever called ancestor() be responsible for closing the connection, but that would be moving a fair bit of semantic-dependent logic out of ancestors() and into the call-site.

Sure, I see the finally clause, but I don’t understand when it gets executed. Is a new connection opened (and closed) for each invocation of ancestors()? That sounds wasteful — more useful might be to close it when the infinite list is “done”. (Would that be when it has been traversed to the end, when it gets garbage collected, or perhaps something else?)

This is, of course, a distraction from your main point. But I need to mull some time on your comment about infinite lists being “packaged” recursion before I come to enlighenment on that topic.

See Google Collections – which is really Iterator centric – , there should be answers to all of those.

e.g. get(Iterator iterator, int position)

But I agree, Java developers should much more use Iterators than Lists, I guess 90% of the time they should use an iterator (“infinite list”) than a collection. That’s sad with Java.

Peace
-stephan

Right here:

    } else Stream.empty
  } finally {
    conn.close()
  }