Re: named captures assigning to local variables

If I may, have a proposal.  My apologies if this has already been 
discussed and rejected on ruby-dev.

I'm quite uncomfortable with the magic behavior (assigning named 
captures to local variables) of =~ when the left operand is a regexp 
literal.  Mainly because there is just no precedent for operators 
behaving differently when an operand is a literal versus when the 
operand is some other kind of expression.

My proposal (a patch is below) is to treat named capture assignment as a 
new form of assignment. That is: allow regexp literals as lvalues in 
assignment.  So instead of using =~, we use =.  The match is still 
performed with =~, but because we use the assignment operator it is 
clear that assignment is happening.  For example:

   /(?<firstchar>.)(?<secondchar>.)/ = 'foo'
   firstchar   # => 'f'
   secondchar  # => 'o'

This form of assignment can be called "regexp-based destructuring 
assignment".  (I learned the word "destructuring assignment" from the 
ECMAScript 4 spec; I don't know if other languages use it as well, but 
this seems to be a regexp-based form of destructuring assignment)

For simplicity, I suspect it is fine to limit this form of assignment to 
cases where there is a single lvalue and a single rvalue.  And it should 
probably be restricted to the = operator, not +=, -=, etc.

Also, I propose that the match be done by calling the =~ method on the 
right-hand side and passing the regexp.  This allows classes other than 
strings to implement =~ and participate in

If regexp-based destructuring assignment is popular, this could be 
extended to allow other kinds of literals as lvalues.  A scanf-style 
format string, extended with names could be implemented:

    "%<x>d %<y>d" = "1 2"   # Works like x,y=1,2

The patch below is a proof-of-concept.  It makes the 
firstchar/secondchar example above work and 'make test' still mostly 
passes (except for tests that are expected to fail, I think).
As a bonus, this destructring assignment now works even with regexp 
literals that include #{} expressions within them.

I don't know parse.y that well, so I don't know that I've covered all 
the cases or put this code in the right place, but, at least the simple 
case works.

I just really, really think that creating more magic behavior for =~ is 
not a good idea.

	David


Index: parse.y
===================================================================
--- parse.y     (revision 14354)
+++ parse.y     (working copy)
@@ -1781,6 +1781,16 @@
                         $$ = dispatch2(assign, $1, $3);
                     %*/
                     }
+                | regexp '=' arg
+                    {
+                   /*%%%*/
+                        $$ = reg_named_capture_assign($1->nd_lit,
+                                                     match_op($3, $1));
+                       /* what's the right thing below? */
+                   /*%
+                       $$ = dispatch3(binary, $1, ripper_intern("=~"), $3);
+                   %*/
+                    }
                 | lhs '=' arg modifier_rescue arg
                     {
                     /*%%%*/
@@ -2131,9 +2141,6 @@
                     {
                     /*%%%*/
                         $$ = match_op($1, $3);
-                        if (nd_type($1) == NODE_LIT && TYPE($1->nd_lit) 
== T_REGEXP) {
-                            $$ = reg_named_capture_assign($1->nd_lit, $$);
-                        }
                     /*%
                         $$ = dispatch3(binary, $1, ripper_intern("=~"), 
$3);
                     %*/



[e-mail] wrote:
> Thank you for the clarification, akr.  I'm embarassed to say that it 
> didn't occur to me to just read the documentation on this...
> I see that there appears to still be discussion on ruby-dev about this 
> feature.  I can't tell what the discussion is about, and I wondered if 
> there were still changes coming.  (In particular, I noted that Nobu was 
> proposing a Binding.of_caller method, and I wondered if that was going 
> to be used to move this feature out of parse.y and into re.c so that it 
> was not specific to literals.)
>   David
> Tanaka Akira writes:
>> In article <[e-mail]>,
>>   David Flanagan <[e-mail]> writes:
>>> This is just a request to have this explained on this list when it is 
>>> finished.  Right now, it seems only to work with regexp literals and 
>>> the =~ operator.  It doesn't work if you assign the regexp to a 
>>> variable and then use =~ with the variable.  And it doesn't work if 
>>> you use match() instead of =~.
>>
>> See the additional document of Regexp#=~.
>> http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/re.c?r1=14297&r2=14296
>>> Have you considered having the assignment depend on the quoting 
>>> syntax for the named capture?  (?<foo>) could assign to a variable 
>>> and (?'foo') could not do the assignment. That way those of us who 
>>> are uneasy with magic regexp stuff could avoid it if we don't want it.
>>
>> It is easy to disable the assignment.  Assign a regexp into
>> a variable.
>>   re = /.../
>>   re =~ str
>> Another (implementation) issue is that Oniguruma doesn't
>> distinguish (?<foo>) and (?'foo').
>> -- 
>> Tanaka Akira
> 
> 
> 
>