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

demerphq wrote:
> On 1 June 2010 20:07, karl williamson <[email protected]> wrote:
>> demerphq wrote:
>>> On 1 June 2010 19:05, Eric Brine <[email protected]> wrote:
>>>> On Tue, Jun 1, 2010 at 6:45 AM, demerphq <[email protected]> wrote:
>>>>> IMO these days octal, and any other non parenthesized code-like
>>>>> escapes should be deprecated.
>>>> A stylistic warning in ambiguous cases (like Abigail's "/\08/ interpreted
>>>> as
>>>> /\x{00}8/" warning) sounds like a good idea, but not a *deprecation*
>>>> warning. That would mean we're planning on removing octal support from
>>>> Perl,
>>>> and I haven't heard any reasons for doing that. Does supporting octal
>>>> escapes cause maintenance problems?
>>> Any non-parenthesized escape structure using numeric values is a
>>> maintenance problem when seen from the point of view of modifying or
>>> joining snippets of a regex together.
>>>
>>> cheers,
>>> Yves
>>>
>>>
>> I thought this was all settled until this heated up again, so I was about to
>> submit patches to change \08, et. al., including the addition of \o{...}
>>  for an arbitrary length octal character constant.  (I'll wait for things to
>> settle down.)
> 
> When i said the above i meant for the USER of perl, not us perl
> authors. Yes there is a modest maintenance burden for US, but it pales
> in comparison to that affecting the user.
> 
>> What I find a maintenance problem is more that there are three copies of
>> these, each with slightly different behavior, and have diverged over the
>> years.  My understanding is that originally the regex and qq were handled in
>> common code.  But, for the most part they've been split apart.  I can't
>> remember why; Yves has said why in the past, and it's convincing.
> 
> Heh thanks. Some of the reasons:
> 
> \1 is a backreference in a regex, in a string it is always the same as
> \001. This holds for \1 to \7 and for \10 (\8 and \9 dont count as
> octal).

In a replacement, \1 is a backreference, and that is handled in toke.c
> 
> Another reason is that we want the octal for "." to match "." and not
> like the "match anything but a newline" type behaviour it normally
> has. So we cannot convert it to a literal during compilation like we
> would in a string.
> 

That's what I now remember as convincing.  But this gives me an idea. 
We could do something like we did for \N{...} which was to move it's 
handling back to the parser, which created an intermediate form for 
regcomp.  Couldn't we move the non-ambiguous parts back to the parser, 
which would convert them all to \x{...} ?  Then only the problematic 
parts, which hopefully is just the octal, would have to be maintained 
separately.  The one problem I can think of for this is the 
stringification of the regex wouldn't be what was input, and that is 
confusing to the user.  This is a problem with the intermediate form of 
\N{...} now.  But I imagine it is solvable.

In an earlier thread, I mentioned that [\8] is the same thing as 
[8\000], and that clearly is a bug, and the stringification doesn't show 
the NUL that gets generated.  I now believe the reason is that on 
successful compilation, the stringification is as close as possible to 
the input string.  That could be extended to avoid the intermediate forms.

[snip]