On Fri, May 15, 2009 at 08:04:49PM -0500, John M. Dlugosz wrote: > Larry Wall larry-at-wall.org |Perl 6| wrote: >> On Fri, May 15, 2009 at 07:16:45PM -0500, John M. Dlugosz wrote: >> >>> Reading through S02, I see that contextual variables has changed in >>> the last year. It appears that contextual and global variables have >>> been unified. So, the + twigil is no more? >>> >>> I assume the point is that any supposed "global" can be overridden in >>> dynamic context, rather than having to know which you planned to and >>> which you didn't. Normal code should use $*x, not $GLOBAL::x or >>> whatever. >>> >>> Is that it, or is there more I need to be filled in on? >>> >> >> That's it, you've nailed it in one. Though perhaps we could mention >> here that part of the motivation is to push context info down the >> dynamic stack to the point where we minimize shared state between >> threads. And also, knowing whether a particular context var is >> rw or not means we know whether we can just make a copy into our >> current thread with value semantics, or we have to manage a lock >> around the shared container. Well, that's the hope... >> >> Larry >> >> > Hmm, so being read-only implies it won't change and can be cached > locally, as opposed to "YOU can't change it along this access path". > Don't we have separate readonly and rw variables aliasing the same > underlying value now? I think you're confusing const and volatile.
Oh, undoubtedly... :) But at least we only have to manage changes from the lexical alias, and that might be amenable to analysis. Or maybe we can enhance the declaration syntax to something approximating single-assignment semantics, so the lexical alias is also not allowed to modify it. There are various ways to push it; I consider the current notation to be an approximation of what we'll end up with. But regardless of the details, it's still the case that minimizing the scope of contextuals will *tend* to prevent accidental thread interaction, and trying to get rid of accidental interactions in the name of parallelizability is one of the strong reasons for many of the design decisions in Perl 6. Even if we've flubbed it in spots. :) Certainly, we've at least got the design to the point where if you recontextualize within a thread, you don't have to look outside the thread for something more global, and that's something... Larry
