On 19/09/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> This solution lacks the elegance of the lazy loading approach, but
> has the best responsiveness. These implementations tend to be overly
> complex for what they do, and hence not worth the maintenance costs.
> The gain is that the user only has to wait for the first message,
> and if the throughput of the system is higher than the user's input,
> there is no responsiveness loss because something is always ready
> for the user to get at.
> Ideally we could have the lazy list approach have some kind of way
> to modify the lazyness so that it's something in between -
> background eagerness - the lazy list is resolved in the background,
> accumilating to @messages. When @messages is filling up quickly the
> background resolution thread might get a lower priority. when
> @messages is empty, the receiver side has to block.

Initial reaction: I like it!

It's one of those "I always subconsciously wanted to do this, but
never knew it" ideas.

Essentially, if lazy means "don't force items until I ask for them",
and strict means "everything must be forced up-front", then async
relaxes both restrictions, saying "I don't need this list to be forced
up-front, but I also don't care if they end up forced before I use
them--just make each access as quick as you can".

Obviously, applying this to an /infinite/ list might be a bad idea
(unless you could specify a finite buffering limit)...

> Note: I have an idea of how easy I want this to be, but not how I
> want to do it.
> I think that a nice solution is to allow an optional named adverb to
> gather which defaults to lazy:

More generally, it would be nice to have a sub &async_force (or
whatever) that takes a lazy list and produces an asynchronously
pre-forced one. Shortcuts for common cases (like gather/take) would be
nice too, though.


Reply via email to