Re: Perl 5.16 and Beyond.

Front page | perl.perl5.porters | Postings from September 2011

Re: Perl 5.16 and Beyond.

Thread Previous | Thread Next

From:

David Golden

Date:

September 13, 2011 06:04

Subject:

Re: Perl 5.16 and Beyond.

Message ID:

CAOeq1c_=4=rv-HgtW1rrHZ1-q8Jjaw-7jY_p9ziBZVw_LoNC6A@mail.gmail.com

On Tue, Sep 13, 2011 at 7:48 AM, Abigail <abigail@abigail.be> wrote:
> In Jesse's scheme, from 5.16 onwards, this is going to mean "5.14
> semantics".  But if this is run on 5.20, it shouldn't restrict itself
> to patterns with 5.14 semantics. If it's run on 5.20, it should also
> work on regexp constructs that were introduced in 5.18.

I'm very glad that Jesse put forth this ambitious vision, and at the
same time, I worry that the devil is in the details and that we might
find it hard to set expectations.  Here's another simple example
inspired by yours:

{
  use v5.20;
  sub match_it {
      my ($string, $pattern) = @_;
      return $string =~ /$pattern/;
  }
}
{
  use v5.16;
  match_it($string, qr/$pattern/); # case A
  match_it($string, $pattern);     # case B
}

Assume that $pattern is a string. In case A, the regex is compiled
under 5.16 semantics but matched in a scope with 5.20 semantics.  In
case B, the pattern is passed into a scope with 5.20 semantics and
then compiled and matched there.

Should semantics be bound to where a regex is compiled or to where it
is matched?  What happens when regexes are combined?

Imagine:

{
  use v5.20;
  sub match_it {
      my ($string, $pattern) = @_;
      my $new_pattern = qr/$prefix$pattern/; # case C
      return $string =~ /$new_pattern/;
  }
}

In case C, we are creating a new compiled regex under 5.20 semantics,
which could contain a compiled regex from 5.16 semantics.  Do we
expect the pattern to preserve 5.16 semantics for some portion of the
match or does the recompilation change the semantics of $pattern to
5.20 semantics?

Either way, this strikes me as having the potential to be insanely confusing.

A similar (if less convoluted) issue applies to any code compiled into
existence via string eval.

This all makes me wonder if the backwards semantics promise needs to
be more carefully scoped (no pun intended) to a more manageable set of
behaviors.  For example, I could see limiting the guarantee to syntax
-- thus ensuring that old cold still *compiles* on new Perl, but not
promising that it would have the exact same behaviors.  That's not
sufficient (e.g. promising the same layers on filehandles is probably
necessary) -- but it would be a start.

I think it might be easier (wiser?) to explicitly include things into
the promise as they seem feasibly rather than make a blanket promise
and then give exceptions.

-- David

Thread Previous | Thread Next