Re: Right place for discussions?

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

On Fri, May 15, 2009 at 07:21:38PM -0500, John M. Dlugosz wrote:
  
Looking at recent traffic, there is more on tickets and checkins, so any  
actual forum messages are lost among them.  Should discussion be  
separate? 



Generally discussion of specs should be on perl6-langauge, though
of course, having a wider audience there, the s2n ratio tends to be
a bit lower.  This mailing list is certainly still appropriate for
abstract discussions of exactly how a particular feature might be
implemented, despite the flood of automated traffic.

Larry
  
Hmm., I seem to have gotten my wires crossed.  I just re-subscribed to 
change my email address, and did so by copy/paste the address in the 
Welcome message I had before.  How odd.  I'll switch back to -language.  
I must have been subcribed to both, or a consolidation feed, before.


--John

Re: Contextual Variables

[John M. Dlugosz]

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.


--John

Re: Contextual Variables

[Larry Wall]

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