> So you shouldn't use it at all.
I wouldn't if I saw any hints :)
> The way the lazy language works, any function that is defined outside
> of the lazy world (and is not a struct constructor) is considered
> eager, so arguments that are sent to it are forced
Yes, that's pretty clear.
> (That's something to know to do the code splitting that Matthias is talking about.)
Going back to this, I often find that I want to use laziness as an
interface. That is, I build a system as a collection of components,
written in a strict language because of familiarity/performance/ease
of reasoning (especially in non-pure language)/etc, which are glued
with lazy streams to make calculations demand-driven. This is known as
generators and I think is a popular simple model.
In this case I don't want any module to live completely in the lazy
world, I only want a lazy interface.
> Right -- on the strict side you'd want to use forces when needed.
As an aside, why strict take has arguments in reversed order compared
to lazy take?
> The internal representation of sequences should change[...]
Sequence protocol as exposed by make-do-sequence is probably the most
complicated sequence protocol I've seen. Is it documented somewhere
why standard sequence/iterator divide is not used? In that case
sequence is stateless (or memoized) and iterator is statefull, but
usually short-lived. Also, each sequence can provide multiple
iterators, such as reverse or memoizing. The latter allows programmer
to decide what he wants in a particular case.
> I thought that there was some warning there... I'll add one.
Thanks.
Eugene