On Fri, Jan 04, 2008 at 01:13:11PM -0800, Dave Whipp wrote: > From that > perspective, it's unfortunate a C<for> loop always iterates arrays in the > order of their indices.
But it doesn't, in hyper context. In Perl 6, C<for> and C<map> are really the same thing, and both respond to hyper context. > As I see it, parallelism is easy: it's synchronization that's hard. > Specifically, it's hard to get exactly the right scoping of constraints. > And it seems to me that "hyper" addresses the parallelization aspect but > not synchronization. Concurrency.pod (S17) defines a few basic mechanisms, > but it's not obvious that they're really "easy", or sufficiently > declarative. There seem to be synchronization scopes analogous to "state" > and to hypotheticals, but not "my", "our", "temp", and "has". (I'm not sure > exactly what primitives are needed: we could discover that by doing more > parallel programming ... which won't happen unless it's easy) My only feeling on the matter currently is that C<temp> and C<let> are probably evil when used on anything shareable, whereas lexicals and contextual vars are probably better behaved. But I'm quite certain people will be playing with the declarative parallelism we've already put in via hyperops, junctions, and feeds, not to mention transactions to manage cooperating events. > The way humans seem to work is that they'll say "I'll do this and this > separately, but I won't worry about that unless something goes wrong". We > employ a mixture of course grain threading, fine grain locking, exceptions, > and recoverable transactions; that we juggle dynamically. That's pretty > hard to do when writing a program, which is why I want to place the burden > on the language designer, not the language user. Sure, my hope is that we can delegate locking entirely to the innards of the implementation and never mention it at all on the language level. STM may or may not be the solution to that. Exceptions are also evil when it comes to concurrency; that's why we've gone to great pains to allow unthrown exceptions to be returned as data when failures occur. You really, really don't want your hyperops throwing exceptions just because one value in a million was bogus. >> With Perl 6 we're trying to make the opposite mistake. > > I fear you may be successfully underemphasizing one dimension to the > detriment of others :-). But considering that you do a pretty good job most > of the time, I'm not too worried. Well, I don't profess to be omniscient, or even prescient. All I can point out is that I'm also trying very hard to make a language that can mutate away from Evil and towards Good, however they choose to define themselves in the cybersphere this year. And that is why grammars must do completely fair longest-token matching across all base and derived grammars (maybe even in parallel :). It is a mistake to privilege either the old over the new or the new over the old, to the extent that they can coexist. In ecological terms, I hope Perl 6 will have a very wide gene pool. Larry
