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. Stuart
