Re: [SPOILER] Re: New Quiz: "What does this code do?" (1-December-2006)

Jay Savage writes:
>It certainly seemed that you didn't quite "get" the concept of
>local-vs.-lexical variables. To wit:

To you.  I started out with saying "you said local -- did you mean
dynamic or lexical?" (more or less)

Assuming from that that I didn't understand the difference seems to be
missing the point.

> > However, it seems that at least in modern perls, $1 is -lexically-
>> scoped.  That seems new.  But good:
>Ronald and I attempted to set you straight.

Easy enough, since I had simply drawn incorrect assumptions from my
oversimplified tests -- because Ronald seemed to be saying that the
nature of the variable (rather than that of the operation) was the
reason it wasn't being overwritten.  I didn't regressively test the
other side of the question (ie, whether a value was visible inside a
subroutine prior to any operations being performed) for two reasons:

1. The (as it turned out, ambiguously stated) point on the table was
   that the nature of the variable (ie, dynamic vs lexical) was the
   cause of the operation now being safe.

2. It simply hadn't occured to me that a line-operation (as opposed to
   a block operation) would do implicit localization -- because I'd
   never (to my memory) encountered an operation in perl that did that
   before.  Is there another one?  local() localizes a dynamically
   scoped variable, of course.  But aside from, now, the match
   operator and its relatives, I don't think I've seen this kind of
   "localizing inside the block as a side effect" behavior before.

>In your private email you said that one, you mistyped and didn't catch
>it, and two, you were assuming a 'different contextual meaning to
>"locally scoped"," as it somehow relates to the context of s//&sub/e.

Not mistyped, so much as that my assumptions changed from the point at
which I wrote the first clause to the later parts of my response.  I
contradicted myself later, which was intentional -- but I didn't
remember what I'd written earlier, so didn't correct it.

>attention- to the erring phrase--and as for the second, I'd certainly
>advise against using standard jargon like "localized" and "local
>scope" in non-standard ways.

I'm actually not familiar with "local scope" except as jargon for
"dynamic scope" -- but made the assumption that Ronald was using it in
a non-standard way.  So it goes. :)

>But it looks like we're all on the same page now. $1 is dynamically
>scoped. s/(.)/⊂ $1/e is probably a safe construct, even if &sub
>performs its own match.

Yeah.  Neat. (tests).  Works, too.

>That doesn't, though, mean it's good practice
>because it may not be backwards-compatible; it relies on undocumented
>and unguaranteed behavior of m//.

Hmm. Mabye.

As of 5.8.5, perlre says this:

  The numbered match variables ($1, $2, $3, etc.) and the related punctu-
  ation set ($+, $&, , , and $^N) are all dynamically scoped until
  the end of the enclosing block or until the next successful match,
  whichever comes first.  (See "Compound Statements" in perlsyn.)

Which on careful analysis (ie, mine, just now :^) would appear to match
the  described and tested for behavior -- that, the dynamic scope of
numbered match variables expires at the end of their enclosing block,
making subroutine calls comparatively safe.

As such, the behavior -is- documented -- and can be relied upon when
coding for modern perls.


-- 
       Joshua Kronengold (mneme@(io.com, labcats.org)) |\      _,,,--,,_  ,)
--^--   "Did you know, if you increment enough, you   /,`.-'`'   -,  ;-;;'
 /\\    get an extra digit?"  "I knew," weeps Six.    |,4-  ) )-,_ ) /\     
/-\\\   "We knew. But we had forgotten."	     '---''(_/--' (_/-'