[ruby-talk:00772] Re: Ugly behavior using /<r1>/ .. /<r2>/ construct.

Hi,

In message "[ruby-talk:00768] Ugly behavior using /<r1>/ .. /<r2>/ construct."
    on 99/08/30, [e-mail] <[e-mail]> writes:

|Is there any difference between these two:
|
|	(1) if /^start/ .. /^stop/; p "GOTCHA"; end
|	(2) if /^start/ ... /^stop/; p "GOTCHA"; end
|
|There seems no difference! But `...' should behave a little bit
|different than `..', shouldn't it?

It does.  Believe me.

From syntax.html:

  If range expression appears in conditional expression, it gives
  false until left hand side returns true, it stays true until right
  hand side is true.  .. acts like awk, ... acts like sed.

This behavior is inherited from Perl.  See perlop.pod

  In scalar context, ".." returns a boolean value.  The operator is
  bistable, like a flip-flop, and emulates the line-range (comma) operator
  of B<sed>, B<awk>, and various editors.  Each ".." operator maintains its
  own boolean state.  It is false as long as its left operand is false.
  Once the left operand is true, the range operator stays true until the
  right operand is true, I<AFTER> which the range operator becomes false
  again.  (It doesn't become false till the next time the range operator is
  evaluated.  It can test the right operand and become false on the same
  evaluation it became true (as in B<awk>), but it still returns true once.
  If you don't want it to test the right operand till the next evaluation
  (as in B<sed>), use three dots ("...") instead of two.)  The right
  operand is not evaluated while the operator is in the "false" state, and
  the left operand is not evaluated while the operator is in the "true"
  state.

|I would assume, that the then case would not entered for a line that
|matches `/stop/' using `...'.

Comparing current `...' behavior out of conditions, it is bit
natural.  But exclusive `...' behavior is rather new, lot newer than
sed style `...' in conditions.  So I'm hesitating to change the
behavior, mostly because of compatibility.

|Furthermore the subpattern capturing doesn't work well. Please consider
|following code:
|
|	if /^title(\s+(.*))?/ .. /^end/
|	   print "title=#$2\n";
|	end
|
|Here the variable `$2' will *never* have any other value than `nil'. I
|assume, that this is because `$_' will be matched against both regexps.
|As the second regexp doesn't match the first time the first one match,
|`$2' will be reset to `nil'.
|
|My proposal would be, that in such `..' construct, the variables `$n'
|should only be set to the captured subpattern of the *matched* regexp.
|The one that *doesn't* match, should not reset them! Only if both
|doesn't match, they should be reset to `nil'.
|
|What do you think?

Let me take time to think about it.  Suggestion, comments are welcome.

                                                        matz.