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

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).

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.

And actually we cant determine whether a given octalish escape is a
backreference, or an octal escape, until we compile the regex, even
worse, depending on the regex executed BEFORE the regex with the
"octal" in it, a given octal escape, say:

\11

may refer EITHER to the 11th capture buffer in the previous pattern,
or whatever it is that \11 is in a string depending on how many
capture buffers there were in the last successful match.

Basically, using normal octal in a regex is an accident waiting to
happen. Only when its written with a leading zero is it safe, and even
then you have the problem of concatenation.

> And in regex code, there are two copies, one for bracketed character classes, and
> one for not, so there are differences in behavior there.  I actually haven't
> looked at the possibilities of unifying them; I've just presumed that
> function call overhead was a concern.

In this case tho, \1 is not a backreference it is the same as \001.

Isnt octal special. Very special. ;-)

> The snippets of code are small.  I
> suppose that the optimizer could inline them if they were static in the same
> file.  But I don't know enough about the possibilities of inlining across
> files.

Me either.

Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"