Rod Adams writes:
> Dave Whipp wrote:
>
> >Rod Adams wrote:
> >
> >>I do not believe that you can create a 'lazy junction'. But I don't
> >>recall the topic coming up before, so we'll have to wait for Damian
> >>to come back unless someone else knows for certain.
> >
> >
> >My understanding is that all lists are conceptually lazy.
> >"any(2..Inf)" is perfectly valid.
> >
> >
> The list being fed into the junction can be lazy. But I believe that
> the list gets iterated over completely in the creation of the
> junction, so C< any(2..Inf) > is valid, but melts your processor
> similar to C< sort 2..Inf >.
Well, if we guarantee that .states never returns two of the same value,
then of course you can not call .states on an infinite junction.
And indeed, while it's possible to do this (taking the range to be an
arbitrary infinite list):
if any(2...) > 100 {...}
You'll melt if you do this:
if any(2...) < 2 {...}
We could make junctions smart about ranges, so that the latter can just
fail, but I argue that we can only do it well in the simplest of cases.
It's probably better not to allow infinite ranges in junctions.
On the other hand, if we give junctions well-defined semantics in terms
of their underlying lists (such as orderedness), then lazy junctions may
be just fine. There's a lot you can do with lazy lists, and there are a
lot of very nice idioms having to do with junctions, and I'd like to
find a way to make those two things not be mutually exclusive.
Luke
