From: HarryO <harryo@...>
Date: 2001-10-05T06:59:26+09:00
Subject: [ruby-talk:22104] Re: Infinite lists

In article <3bbb7159$0$236$edfadb0f@dspool01.news.tele.dk>, "MikkelFJ"
<mikkelj-anti-spam@post1.dknet.dk> wrote:

> I haven't looked at the Ruby / Perl way to address infinite lists.

There's no built-in way of handling them in Ruby, which is why I thought
it would be interesting to try.  They don't exist in Perl, either
(although, there are discussions about the concept going into Perl 6),
just some code I saw on a web page that was mentioned on this list a
while back.

That code may exist as a Perl module, in which case I guess it DOES exist
in perl now.

> But streams a.k.a. lazy streams are fundamental features of pure
> functional programming languages like Haskell and Clean. Laziness can be
> implemented by storing functions instead of values in a list, and this
> is probably what is done in the Ruby / Perl case.

Yes, that's basically what the perl code I saw was doing and it's pretty
much how I built it, too.  The difference between mine and the code in
the perl article is that they set the "next" field of the last entry in
the list to be a function that generated the next entry.  By comparison,
I keep that code in the Stream object itself and just know when to call
it (ie, I know when someone asks for an entry that's not yet in the list
and call that function the right number of times to add the intervening
entries).

I don't say that my approach is better.  It simply avoids testing the
type of the "next" field all the time, which is a string comparison,
rather than just checking the requested index against the current length
of the list.

> Streams can be used for parsers where subexpressions are merged together
> to larger expressions. The merge process is accomplished with something
> called a combinator. The parsers are called combinator parsers. This is
> not specific to parsers and prettyprinters - these are just favorite
> examples.

I don't quite understand what you're getting at there, but the reason I
bothered to write the code was that I could see that it was a
sufficiently generic concept that people may come up with all sorts of
uses for it, over and above the examples I saw in the article.

> There is a chapter in the clean book about combinator parsers.
> http://www.cs.kun.nl/~clean/

I hadn't heard about clean before, so I'm going to have a bit of a
learning curve before I can get into the use of streams, but it feels
like it could be well worthwhile.

Thanks for the comments.  I'm hoping to finish cleaning up ... no pun
intended :-) ... my code over the weekend and post it to RAA. At that
point, hopefully a couple of people may have a look at it and give me
some feedback on ways to improve both the interface and the
implementation.