develooper Front page | perl.perl5.porters | Postings from July 2009

Re: Back and forth compatibility

Thread Previous | Thread Next
Ben Morrow
July 11, 2009 19:05
Re: Back and forth compatibility
Message ID:
Quoth (Michael G Schwern):
> This discussion brings up a new type of compatibility.  Previously we've been
> worried about backwards compatibility, that OLD code using OLD features still
> runs fine on NEW Perls.  Deprecation warnings are there to give notice and
> removing a long deprecated feature is fine.  So in that view simply removing
> the implicit split to @_ with no further ado is fine.

In this specific case I am inclined to agree. The more general question
of changing the semantics of existing syntax is important, though, and I
entirely agree with those who think we need a way to do it where we
think it's a good idea. Here's a possible solution:

    1. When we have seen 'use 5.012' or a 'use feature' that implies
       5.12 in this lexical scope, you get the new behaviour.

    2. When we haven't, you *still* get the new behaviour, but also a
       warning 'split in scalar context no longer sets @_ as of perl
       5.12.0'. This warning will go away entirely with 5.14, so people
       get one major version of 'yes we really did mean it' to get the

[That was the important bit. What follows is speculation and vapourware,
and you can ignore it if you like :).]

I would also like to see (maybe not for split, since the old behaviour's
useless, but in general)

    3. If you say 'use legacy "split"' you get the old behaviour for
       this lexical scope. This is harder than it seems, since to be
       useful it has to work

           - from every package,
           - inside string eval,
           - with explicit calls to CORE::split,
           - with code that overrides Package::split and/or

       In practice this means it has to (lexically) replace the op,
       rather than just export a sub, and ideally all the code to make
       this work should be in legacy.xs rather than in the core.

I think I can see a way to make this possible, using

    - the ENTER/LEAVE/&c. blocks from Perl 6,
    - a SCOPECHECK block that fires when the current scope finishes
    - a NEWSCOPE block that fires at compile-time when a new scope is
    - a Block::Util module that allows you to install these blocks in
      the currently-compiling scope (this plus SCOPECHECK is what we
      need to replace the %^H-stringify hacks).

Block::Util would also be a good place to put the best-effort hacks for
emulating these blocks under older versions of perl. I intend to do a
more coherent proposal for these later, but I'd like to get at least a
skeleton implementation working first.

> BUT since we've never done it that way before, can we make this policy
> discussion orthogonal to this <weeping>very simple change to a looooong
> deprecated and dangerous feature</weeping> and just patch it in?

In this particular case, +1 :).


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About