develooper Front page | perl.perl5.porters | Postings from October 2011

Re: Perl 5.16 and Beyond.

Thread Previous | Thread Next
From:
Father Chrysostomos
Date:
October 16, 2011 12:05
Subject:
Re: Perl 5.16 and Beyond.
Message ID:
A9EA8B25-1CD8-4F53-9371-D7C53DA116BA@cpan.org

Nicholas Clark wrote:
>    Except that this would be a test on the lexical scope of the caller.
>    How does that fit with
>    a) the desire to take references to builtins as if they are functions?
>    b) the desire to be able to introspect builtins using %CORE:: ?
> 
>    The "clean" implementation doesn't fit sanely with being able to take a
>    reference. It would provide a reference to a function whose behaviour
>    changes depending on the calling scope. Whereas what's needed for sanity
>    is for the function's behaviour to be consistent with the builtin's
>    behaviour at the lexical scope where the reference is taken.

While that model might make sense on its own, that’s not Perl’s model.  We already have modules with functions that change behaviour based on the caller’s hints, such as charnames::vianame.  Why would warning hints be in a different category from feature hints?

Having \&CORE::lc behave differently based on the caller’s hints (unicode_strings in this case) is a feature if you ask me, as it allows the code that takes the reference the choice of whether hints are to be captured immediately or inherited from the caller:

    \&CORE::lc
    \&charnames::vianame
    *ARGV->can('getline')

vs

    sub { goto &CORE::lc }
    sub { goto &charnames::vianame }
    sub { goto &{can ARGV 'getline'} }

> By which you mean that the policy should change. To date, new "things" have
> been allowed if previously they were syntax errors. Henceforth, no language
> changes, even those that are backwards compatible, should appear unless
> asked for?
> 
> This does (mostly) remove the "problem" that one can write and test against
> a newer perl interpreter, and not realise that one is relying on a new
> feature. On balance, I think that this is better.

That last sentence I do not agree with.  See below.

> However, it's never going to be a substitute for actually testing, as bugs
> will be fixed, and I don't think that all behaviour can be hidden.

Precisely.  If you do not test with an earlier perl you have *no idea* whether it works with it or not.  In fact, the only cases I’ve encountered that involved using ‘future’ perl by mistake were code that relied on perl bug fixes.  So I don’t think providing new features only under a pragma solves anything.  In fact, it complicates things.  Let me give a couple of examples.  The &CORE::subs feature cannot be versioned, as we have no system for making package variables appear and disappear based on what pragma is in scope (and let’s not go there).  Hence, allowing parentheses after __FILE__, etc., cannot be versioned, because versioning it results in nonsensical behaviour, unless we use some magic tricks to make

    BEGIN { *f = \&CORE::__FILE__ }
    f()

into a syntax error outside of ‘use v5.16’, but OK within ‘use v5.16’.  I know how to do that; I just think it’s wasted effort, and too weird to be of any use.  If we allow parentheses on an aliased &CORE::__FILE__ unconditionally, then

    use subs '__FILE__';
    BEGIN { *__FILE__ = \&CORE::__FILE__ }

will change the syntax under ‘use v5.14’, which I would consider a bug.  I’m not willing to introduce a new feature with known unfixable bugs.  Some may consider me nuts for worrying about such edge cases, but edge cases have to make sense; otherwise the model is flawed and needs to be rethought.  If the model is flawed, it is going to cause suprises, bug reports and future chagrin.

Also, allowing CORE::say and ‘continue;’ outside of ‘use feature’ and allowing the (\$) prototype to accept any lvalue expression were features I added in preparation for coresubs.  Without them, the edge cases don’t make sense.

My work on coresubs is currently stalled, and has been since this new policy announcement, since I don’t know whether that feature can stay.

Also, I would like to see a high-precedence ^^ operator to fill the blank slot in this table:

  bitwise              &    |   ^
  logical (high prec)  &&   ||
  logical (low  prec)  and  or  xor

It would be trivial to implement, but if it requires ‘use v5.16’, it’s not worth the bother.

So the new policy is *already* impeding development.

BTW, that is the only part of it I don’t really like.  The rest is excellent (in terms of policy; not in terms of which features people now think are going to be disabled).


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About