On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
So, in summary, its good to have a clean abstraction for all the HCCCT things. But I think it is a mistake to push them too close. Each of the HCCCT things might be implemented as facades over the underlying othogonal concepts of data management and execution management (hmm, we mustn't forget IO and other resource managers).
Yeah, that.
What I STRONGLY SUGGEST WE AVOID is a situation where _some_ of those interfaces are object-based, using <new Thread:> or similar, and others of those are trait or keyword based, such as <coro foo> or <sub foo is coroutine>, and others are implicit and invisible (closures).[*]
I think that's where we _might_ be headed, and we should turn that burro 'round.
MikeL
[*] I would even be ~somewhat~ willing to debate whether Perl5's ability to implicitly create closures, in absence of any marker to specify that you _meant_ to do that, might be a slight misfeature. In that I've seen people accidentally create closures -- a damn hard bug to find, sometimes -- when they would have been better served by Perl throwing var-not-found errors, and requiring a specific keyword to create an actual closure. Somewhat willing. Maybe. Sortof.
