develooper Front page | perl.perl5.porters | Postings from May 2015

Future policy and direction for POSIX.pm

Thread Next
From:
Aristotle Pagaltzis
Date:
May 5, 2015 17:18
Subject:
Future policy and direction for POSIX.pm
Message ID:
20150505171755.GA11978@plasmasturm.org
Hi,

I’ve just pushed a branch in response to #124446 (titled “POSIX.pm 1.47+
exports C99 math functions” and set as a 5.22 blocker):
http://perl5.git.perl.org/perl.git/commitdiff/ap/posix-exports

Let me quote the commit message:

  This patch does 3 things. For the purposes of bisectability it is
  unfortunately not feasible to split them up into separate patches.
  They are as follows:

  1. Revert the list of default exports in t/export.t to what it was
     in the commit tagged v5.20.2 but take the opportunity to retab
     it since the blame log is messed up anyway. This can be verified
     with a whitespace-ignoring diff.

     Add a note to the @EXPORT test to forestall future additions to it.

  2. In POSIX.pm, remove the new fenv_h tag and revert the math_h and
     stdlib_h tags to their state in Perl 5.20.2.

  3. Add infrastructure for adding export tags that will not automatically
     get added into @EXPORT when it is generated, and use this to add new
     tags for all the stuff added since 5.20.2.

     In the cases where these new tags are expansions on existing tags,
     they include the version number of POSIX.pm in which they were
     introduced, i.e. math_h_1_52 contains everything in math_h plus the
     new stuff from POSIX 1.52.

Now – there are two decisions there that I consider up for consensus
and/or pumpking decision:

1. There have been some additions to the default exports before – namely
   in c3fa0c84d6, Steve Hay added a bunch of new EFOO error constants:

       EBADMSG ECANCELED EIDRM EILSEQ ENODATA ENOLINK ENOMSG ENOSR
       ENOSTR ENOTRECOVERABLE ENOTSUP EOTHER EOVERFLOW EOWNERDEAD
       EPROTO ETIME

   Presumably because they are all-uppercase symbols pseudo-namespaced
   in C style with a prefix, this has not caused a problem.

   Do we consider such additions of constants to the default exports
   acceptable in principle?

   Generally?

   Or only within existing prefix pseudo-namespaces? (I.e. new DBL_FOO,
   EFOO, FLT_FOO are OK because others like them are exported already,
   but the new FE_FOO constants are not because no other FE_FOO
   constants have been exported so far.)

   Or do we consider the default export list now frozen forever?

2. When more functions and constants from some C header file are newly
   implemented for which POSIX.pm already has exports, what do we do?

   As a specific example, during the 5.21 cycle, Jarkko implemented
   a bunch of functions from math.h that were not previously available.
   But POSIX.pm already has a math_h tag, and anyone asking for that is
   surely going to be surprised if they suddenly get three dozen bonus
   exports.

   The approach I took was to add new tags that include the POSIX.pm
   version, i.e. math_h_1_52 for the math.h stuff as of POSIX 1.52. Is
   that a reasonable approach or do we want to do something else?

Obviously my own answer in both cases would be “freeze it” and “yes”, as
I have implemented in the patch. But someone else might well have a good
reason to propose something else, and ultimately it’s Rik’s call.

                                  — • —

In particular on #2, my own stance is shaky. I do believe that from the
perspective of POSIX.pm it is more or less the only sensible approach.
OTOH, from a user perspective, it sucks to have to remember to say `use
POSIX ':math_h_1_52';`. That’s a *terrible* interface for “give me the
new NaN stuff please”.

But I don’t see how that can be avoided.

So I must wonder if it’s a good idea to pursue POSIX.pm as such at all.
The approach of “here’s a huge bag of not-actually-related stuff whose
only commonality is being mentioned in the same spec” does not make all
that much sense.

It is also the reason that POSIX.pm needs this custom compile-on-demand
infrastructure to make `use POSIX;` not be terrible. (Or at least it
needed that once upon a time. I am unsure that it’s a real concern or
even a good idea at all on modern hardware.)

Maybe POSIX.pm should nominally be considered discouraged and people who
think they want to add to it in the future should be directed to other
modules or be advised to create a new one.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

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