TSa wrote:
IIRC, $Larry has mentioned a Pipe type which to me seems to be just the generic type where you configure the buffer/queue size. In multi-threaded (or connected processes) applications the buffer size needs tuning to balance responsiveness with throughput. Thus your gather proposal could just be a :buffer($size) adverb/trait in the slurpy list declaration and some auto-threading behaviour of the pipe operators ==> and <==.
Would the named adverbs for gather work in other contexts as well? Would you suggest this mechanism for specifying the buffering behavior for IO operations?
Tim Bray recently wrote about wanting a language that would be smarter about IO buffering by default. Will perl6 be such a language?
From "Radical New Language Idea" (http://www.tbray.org/ongoing/When/200x/2005/09/13/Buffering)
"I had this program that was running slow and fixed the problem by fixing the I/O buffering. If I had a quarter for every time I’ve done this over my career, I’d have, well, two or three bucks. I think the language-design community ought to take notice. Currently, they cook up new languages so object-oriented that each individual bit has a method repertoire, languages so concurrent that threads execute in incommensurable parallel universes, languages so functional that their effects are completely unobservable... How about a radical new language where the runtime system is hyperaggressive about ensuring that all of its I/O primitives are by default buffered unless the programmer specifically requests otherwise? I’ve heard that there’s something called “COBOL” that has this capability, I’ll have to check it out."
Apologies if I've misunderstood things so badly as to make my questions senseless, or worse yet, irrelevant.
/au
