Re: Perl 5.18 and Regexp::Grammars

Front page | perl.perl5.porters | Postings from August 2013

Re: Perl 5.18 and Regexp::Grammars

Thread Previous | Thread Next

From:

Damian Conway

Date:

August 10, 2013 23:17

Subject:

Re: Perl 5.18 and Regexp::Grammars

Message ID:

CAATtAp6f3XNR-+0aKjmaa=1dOu3_-3CK-xfbX17vYTjW=5fa+g@mail.gmail.com

Dave Mitchell wrote:

> I think that this is the one that will be impossible to work fully
> workaround; i.e. the modification of user-supplied code blocks before
> the perl parser gets to see them.

Thanks for the detailed analysis and response, Dave.
It was, as usual, both interesting and educational.
And, as usual, much appreciated!

I had already assumed that this particular issue would prove to be the
one that was unfixable, as it proceeds not from a hidden bug, but rather
from a change of behaviour needed to fix hidden bugs.

> Before I discuss this in more detail, first can I ask whether its
> absolutely necessary for R::G to modify user code? Could the effects
> you achieve be done by exporting (say) a tied var $MAGIC_VAR into the
> callers namespace???

Yes, the current release of R::G already uses a similar solution.
Namely, it turns off 'strict vars' in the scope where the module is used.

That is obviously a *bad* solution, but so is exporting a variable.
Imposing 'no strict "vars"' weakens compile-time testing of every var
in that single scope. Exporting a "pseudo-var" weakens compile-time
testing of that single var in every scope. Honestly, I still can't
decide which is worse.

Of course, the right solution would be for R::G to set up a *lexical*
pseudo-var in each scope where it's imported, but I'm not aware of
any reliable way to do that...except by using source filters. :-(

> For those two reasons (bare code blocks don't get processed; code blocks
> are compiled - and possibly error out - before they can be modified), I
> don't think R::G as it stands is viable under 5.18.x.

Agreed.

> Which leads me to repeat the question: is it possible for R::G to work
> without the facility to modify the text of user code blocks?

It is, albeit by injecting either unlimited non-strictness into a
limited scope, or limited non-strictness into an unlimited scope.
I will simply have to settle on one of those two workarounds for 5.18.

> If not, then I wonder whether, for 5.20.0, we could add a new facility
> that would allow you to do what you need.

I would VERY MUCH like to have the facility your described for capturing
the raw source of constants (and other components).

That would not only solve my problem, it would also no longer require me
to use the trick of using 'overload "qr"' to return an object with
overloaded concatenation and stringification. So it would greatly
simplify the implementation of these kinds of modules. And probably
improve their performance too.

So, yes: please sir, may I have this for 5.20???

Though perhaps 'source' would be a better keyword than 'raw'?

And, ideally, the source code fragment being passed into the overloading
sub would not just be the "contents" of each constant construct, but
the entire syntax of the construct, including:

    - the delimiters used

    - any keyword used ('q', 'qq', 'qr', 'qx', 's', 'tr', or 'y')

    - any flags used (i.e. in the case of 's', 'tr', and 'y')

That is, reworking and extending your own example:

 use overload;
    BEGIN {
        overload::constant source => sub {
            my $s = shift;
            say "source($s)'";
            $s;
        };
    }

    $rex = qr/abc(?{})def$x/i;
    $str = "ABC$a[$b+$c]DEF";
    $str =~ s{foo}{bar}gxms;
    $hex = 0xDeadCode;

would output:

    source(qr/abc(?{})def$x/i)
    source("ABC$a[$b+$c]DEF")
    source(s{foo}{bar}gxms)
    source(0xDeadCode)

I you could give me that, I might do *great* things with it.
("-- terrible, yes, but great!")

Damian
(with dreadful visions already dancing in his head ;-)

Thread Previous | Thread Next