Re: What should /\08/ match and do?

Abigail wrote:
> On Sat, Jun 05, 2010 at 08:58:12AM -0600, karl williamson wrote:
>> Abigail wrote:
>>> On Fri, Jun 04, 2010 at 07:45:36AM -0600, karl williamson wrote:
>>>> Abigail wrote:
>>>>
>>>> OK.  What about '\0a'  It doesn't warn currently.  It is analogous to 
>>>>  \08 but has a non-octal hex digit instead of a non-octal decimal 
>>>> digit.  Should it warn?
>>>
>>> IMO, no. It doesn't now, and it's too easy to generate false warnings.
>>> I also think it's very less likely to make a hexadecimal-instead-of-octal
>>> error, then a digital-instead-of-octal error. After all, for most people
>>> digital is what they've learned early in life. As Nick said, warning on
>>> \08 makes sense, as it may happen because someone added 1 to \07, forgetting
>>> about the octal issue. 
>>>
>>> Heck, we don't even warn (and we shouldn't start now, I may add) on /\xabc/.
>>>
>>>
>>> Abigail
>>>
>> OK.  I think we have agreement.  I'll recap to give people another  
>> chance to disagree, but first, am I overlooking something if I change  
>> the docs to say that using 3 digits always for \OOO causes the  
>> ambiguities to completely go away, including concatenation of strings to  
>> form larger patterns, as long as there are fewer than 64 (= \100)  
>> capture groups?
>>
>> So here's what I'm planning:
>>
>> Existing Behavior Changes
>>   [\8\9] will mean [89] instead of [89\000].  	
> 
> That sounds like a bug fix. Bug fixes are good.
> 
>>   The current wrong warning "Illegal octal digit
>>   ignored" will change to "Unrecognized escape"
> 
> For just \8 and \9 I presume? 

Yes

Or also for /\18/? It's not an unrecognized
> escape if it keeps its existing meaning of /\x{1}8/ (assuming no 18 set
> of preceeding capturing parenthesis.

My statement was just for character classes, so capturing parentheses 
aren't applicable.  \8 and \9 outside character classes currently 
correctly generate an unrecognized escape warning in double quoted 
strings; and in patterns and replacements are always interpreted as 
references to capturing groups, as currently documented.  I did not 
propose to change any of that.  See below for \18
> 
>>   \400 and above in one context now generates a
>>   deprecated message and is taken modulo \400.
>>   It wil will now mean \x{100} and above, with
>>   no warning.  This matches behavior in all other
>>   places except -0 on the command line.
> 
> Does this mean that chr (03000) =~ /\3000/, and that no longer (chr
> (0300) . "0") =~ /\3000/? I've no problem with this change in behaviour
> (I'd say that's what many people will expect in a post ASCII/LATIN-1
> world), but /\3000/ does not currently warn. Or are you just talking
> about \400 .. \777 ?

I should have said \400 - \777.  You need brackets to get more than 3 
digits, or this would break lots of existing code.
> 
> 
>>   \o{...} will now generate an octal constant
>>   instead of the literal o{...} and the
>>   "Unrecognized escape" warning on the 'o'
> 
> +1
> 
>>   \o not followed by a { will now be a syntax
>>   error instead of "Unrecognized escape" warning
>>   on the 'o'
>>
>> Additional warning message changes
>>   \08 \009 will generate a new message instead of
>>   the existing wrong "Illegal octal digit ignored".
>>   I'm thinking: "Too few digits in octal character
>>   constant; assuming you meant '\\%04d'".
> 
> Ah, that probably answers my question above. But too few digits? If one
> changes the 8 and the 9 to X and Y, it won't complain about the number 
> of digits.

Wherever currently the wrong "Illegal octal digit ignored" message is 
output and no other places, I was planning to change that to the new 
message, whatever the wording.  That would apply to \18 in all the 
contexts.  How about '"\18" resolved to "\0018"'?  (or "\18" resolved to 
"\o{1}8"').  That's not adding a warning to unwarned code, since they 
are already getting a warning (which happens to be a lie).
>> Documentation will be updated, including saying that -0400 and above on  
>> the command line means the same as -0777 currently does.
> 
> 
> I also assume that, where appropriate, these changes are for all
> interpolative contexts, not just m//, s///, and qr//?

Yes.
> 
> 
> Abigail
>