Re: The future of POSIX in core

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

Re: The future of POSIX in core

Thread Previous | Thread Next

From:

Mark Overmeer

Date:

September 2, 2011 01:39

Subject:

Re: The future of POSIX in core

Message ID:

20110902083933.GK6067@moon.overmeer.net

* Nicholas Clark (nick@ccl4.org) [110901 20:08]:
> On Wed, Aug 31, 2011 at 10:38:19PM +0200, Mark Overmeer wrote:
> Do we actually want a few hundred more POSIX functions *in core*?

No, we do not want a few hundred new functions in core, although
  . it would help portability of everyones code, because nearly
    all platforms do support POSIX to some level. It would help if
    that system-interface is taken seriously.
  . they are only very low level functions, so each is very light.
  . POSIX.pm exports zillions of constants (fcntl, errno, ...) which
    should be kept up-to-date as well. It is not pleasant for people
    to get most constants from POSIX.pm, and other from POSIX::2008.pm
but there is no real need.

> isn't an alternative more in keeping with the idea of a minimal core to
> 0: declare that the core POSIX is effectively a legacy module
> 1: that it supports (I infer) the 1997 POSIX.1 functionality
> 2: document that POSIX 2008 support is available on CPAN
> 3: provide modern POSIX 2008 support as one (or more) CPAN modules

@0: even when declaring it legacy, it still needs a lot of changes,
for instance to get rit of 250 autoloaded files in the distribution
of which many say "not implemented". So:

@1: POSIX.pm is by far not POSIX.1 1997! It has implemented only a
few (about 50) of its functions. The manual-page is very broken, as
I have shown various times before. And I do not believe that removing
things like "wide-character" support from a POSIX-in-core would
disturb anyone.

@2: after POSIX 2008, we will get extensions, like POSIX 2015. It is
inconvenient to rename modules, so in the long run we would get stuck
to POSIX::2008 to support the 2015 version... I think we need a better
name for it.  Or we may do: POSIX::2015 extends POSIX::2008 extends
POSIX::2015.

@3: yes.

> ie consider that the API of the current POSIX is pretty slushy
> [documentation and implementation fixes obviously still most welcome]
> and that the future of good POSIX support lies on CPAN.

The very large patches, which I have sent to this list, can be a good
start of the suggested changes.

May I suggest to do the following:
(step 6 to 8 may mildly break things, so need further discussion on
the list)

  1. remove the autoloading
  2. remove all functions which croak in "not implemented"
  3. remove documentation for all functions which are not really
     implemented or documented as not possible to implement.
  4. let the documentation say: this legacy module provides a small
     subset of POSIX 1997, see POSIX::??? on CPAN.
  5. refrase all the lies from the documentation. "is the same as"
     this means: full rewrite of the man-page
  6. remove 40 functions which simply forward to core perl functions
     with the same name, for instance chdir(), but avoid errors from
     being reported when people explicitly import those.
  7. remove stuff which no-one in its right mind should use: isalnum,
     wide character functions.
  8. move to CPAN things which have a very specific/limited use,
     for instance POSIX::Termios... or do we really need Text::Termcap
     and Term::Cap in core?

(I have patches for 1, 2 and 5 ready)

And then on CPAN
  a. create a new module.. ok POSIX::2008 isa POSIX, which in the
     beginning mainly a large manual-page.
  b. try to convince CPAN authors which added nice extensions to the
     core POSIX to move their XS component into POSIX::2008 to be shared.

(I have the new manual-page for a)

Grouping all fragments of POSIX library connectors will improve supported
for them onto uncommon platforms. On the other hand, provide freedom to
have alternative wrappers around these low-level functions on CPAN.
Even many UNIX systems get installed without C-compiler these days, so it
is increasingly difficult to install XS modules which are not supported by
a distribution. Putting all POSIX-XS into one spot will help spreading
these extensions.

My purpose while writing the new POSIX(::2008) manual was on experienced
computer programmers which enter our Perl world: they know which POSIX
function they need and want to know how to do the same in Perl. It's
more of an index. On how Perl does support platform features.

Anyway: I volunteer to implement above steps, because I have done quite
some work on that already. On the other hand, I am a little afraid for
the endless debates when touching pet subjects of certain core developers.
Those may consume all the time I have.
-- 
Regards,

               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       Mark@Overmeer.net                          solutions@overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net

Thread Previous | Thread Next