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

Re: The future of POSIX in core

Thread Previous | Thread Next
Mark Overmeer
September 2, 2011 04:48
Re: The future of POSIX in core
Message ID:
* Nicholas Clark ( [110902 09:54]:
> > @1: 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.
> So what whas the POSIX standard in 1994?
> Because that's when the code dates from.

See about that.  Actually, mostly
the same. And before 1988 many of those functions where part of the
(ANSI) C spec.

> One would not think that changing the output of perl -v would disturb
> anyone, but we got complaints because at least one deployed system was
> relying on it, for some sort of probe.

That doesn't wonder me at all.

> *Every* change has the potential to break something.

Yep, even bugfixes do bite existing code regularly. But gladly we do
fix bugs.

> So name it after the subsections of the POSIX spec?
> That avoids it being named "POSIX", and avoids having one
> monolithic module.

You do not want to have 17 modules with difficult names. That makes
it much harder for programmers to work on implement things. 

> After you first raised the issue, Aristotle had also offered patches to do
> this alone [no prototype changes, same usage() checking]. I wrote quite a
> lot of tests, and rejigged and applied his patches, because there seemed to
> be consensus that you're dead right on this one, and his code offered a very
> elegant solution to just this.

Yeh, I wondered why he got away with it so easily, where my patches
got totally ignored (what later got explained as "too late"). There are
some changes in the output produced by that change and no-one seems to
be bothered by that.

> >   2. remove all functions which croak in "not implemented"
> The implementation of these is now on demand, 1 line per function. The cost
> of keeping them is low.

On the other hand: you are 100% sure that no-one can every have used that
function in their code.

> a: change @EXPORT
> b: have something in @EXPORT that doesn't actually get exported.

> >   3. remove documentation for all functions which are not really
> >      implemented or documented as not possible to implement.
> Remove totally? Or document a list of "not really implemented" and
> "not possible to implement"

You may write documentation about everything what is *not* possible
with Perl, but it is kind-of useless. Removing those from the docs fits
better in the idea of "keeping Perl core as small as possible". And the
documented list of "missing" is far from complete anyway.

> >   4. let the documentation say: this legacy module provides a small
> >      subset of POSIX 1997, see POSIX::??? on CPAN.
> I suspect it's a subset of one or more sections of POSIX 1988 and 1993
> The POSIX module dates from 1994, but I'm not sure if some of it is a
> rewrite of something perl4-era, hence possibly from somewhat earlier.

subset of 1997 = subset of 2008.  My focus is on "small subset" of
functionality which is offered.

> >   5. refrase all the lies from the documentation. "is the same as"
> >      this means: full rewrite of the man-page
> "is the same as" is always risky, because everyone has a different man
> page (or none, so they read something random on the Internet) to base their
> expectations off. Documenting what it actually does is useful.

No, its is much worse.

    asin This is identical to the C function "asin()", returning the
         arcus sine of its numerical argument.  See also Math::Trig.

Of course, POSIX::asin is not identical to the C version of asin(). In
our case, the function accepts a SV which will get converted into a
double to call one of these [based on compile-time flags, I presume]
   double asin(double x);
   float asinf(float x);
   long double asinl(long double x);
and then packaged back into an SV. If I, as programmer, are really
interested in using POSIX::asin, then I do need to know how above is
handled. And how the border cases, like NaN are being handled. But in
any case, the asin() provided does have significant differences from

Maybe, above is a bit theoretical... in practice people may understand
this a bit better. Or simply try it out... but the next is worse:

   tolower This is identical to the C function, except that it can apply
           to a single character or to a whole string.  Consider using the
           "lc()" function, see "lc" in perlfunc, or the equivalent "\L"
           operator inside doublequotish strings.

"This is identical, *but*".  The ctype/tolower *macro* can only handle
native characters.  POSIX::tolower takes any string containing scalar,
ignores whether it is utf8 or not, and then treats all bytes in it as
7-bit characters (ascii or ebcdic), returning a new scalar with the result.
We do not have a single character data-type in Perl.

Let's asume that we are not implementing the programming language C. Then,
the documentation should, IMO, be reduced into:

  Legacy functions:
     tolower     use build-in funtion lc()

> >   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.
> "avoid errors from being reported" means that you're proposing that working
> code such as:
> $ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
> becomes a runtime error:
> $ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
> chdir is not a valid POSIX macro at -e line 1
> not even a compiletime error.
> It would cause less breakage to have a compiletime error.

No, my patch changes this:
  $ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
  without error
  $ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
  without error
  @EXPORT = qw/chdir/;
  sub POSIX::chdir {
     usage "chdir(directory)" if @_ != 1;
with a small exporter trick simply ignoring the 'chdir' keyword when
found by export().

Abigail did earlier protest against this change for a more valid reason:
POSIX functions have no prototype.  So, in reality, these two programs
do differ now-adays:

program 1:
  use POSIX 'exit';
  exit @rc;

program 2:
  exit @rc;

I consider the situation a bug, in both cases, because the documentation
says that exit needs a scalar. But those bugs may show up with people.
> As currently formulated, this is a stupid suggestion.
> I have considered my wording carefully, and I'm sticking to it.

I already stated that 6/7/8 would trigger discussions on what to break
or not.

> >   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?
> Any further suggestions are on what might go is turning out to be extremely
> controversial. Term::Cap and Pod::Text::Termcap are in core, Text::Termcap
> doesn't exist. I'm not sure what you mean by referencing them here - that
> they should go, or that POSIX::Termios is very limited without them?

One of the main reasons to have modules in the core distribution, is
because other modules in the core distribution need them. It is to be
considered wether we need a whole group of modules altogether.

> It would be better if the POSIX subclasses were in separate modules.
> But historically there were not, hence have been loaded via use POSIX;
> So it's not clear how to do this without breaking things.

Even in 5.8.9 someone added an, in perl4 syntax coded, package POSIX::SigRt
into POSIX/pm!  Let's try not to make that kind of mistakes again.

> I think it's fair to say that the pet subject of most core developers is
> "not breaking things". As in trying to achieve whatever else it was they
> actually wanted without inadvertently breaking something, often something
> they weren't aware of.

"Not breaking things" is, of course, not what I meant with "pet subject".
Breaking things is bad, which is a general concept of development. But
let's asume you understand my point better than the remark shows.

I really get fed-up with this lecture everyone likes to add to emails
about this subject. This must be at least the tenth time someone tries
to demotivate me in the past half a year. Perl-core developers are not
the only programmers in the World with experience in large projects! And
even iff I would have no experience, then still some of the points above
do make sense.

Let's try to focus on improving perl and study each others contributions
in detail before judging based on "I see you on IRC"/OSCON/YAPC, or not.


       Mark Overmeer MSc                                MARKOV Solutions                         

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