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:

Nicholas Clark

Date:

September 2, 2011 11:40

Subject:

Re: The future of POSIX in core

Message ID:

20110902184014.GE23881@plum.flirble.org

On Fri, Sep 02, 2011 at 05:23:20PM +0200, Abigail wrote:
> On Fri, Sep 02, 2011 at 04:35:57PM +0200, Mark Overmeer wrote:

> Whether it's unpleasant or not is an argument that should have been raised
> when POSIX.pm was introduced (or when prototypes were added to the core,
> whatever happened last). What's important now is, "do we want to break
> backwards compatability".

POSIX.pm dates from 5.000, in Oct 1994. Chunks of it are unchanged from then.
Prototypes date from 5.002 in Feb 1996.

[strictly ext/POSIX/POSIX.xs was POSIX.c between alpha 6 in March and
5.000, and seems to have been generated from ext/posix/POSIX.xs from alpha 4.
isalnum() etc, which Mark correctly observes are broken for anything UTF-8,
are essentially unchanged from 5.000 alpha 8, 4th April 1994.

http://perl5.git.perl.org/perl.git/commit/2304df62caa7d9be

git first records prototypes in 5.002beta1, 13 months after 5.000
shipped, but (it seems) that they originate from this message from 28th
September 1995, referenced in the changes:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/9509/msg00666.html

I don't know if it's awesome or awful that when looks at the archives from
10, 15 or more years ago that a lot of the names are not only familiar, but
still answer their e-mail.]

None of this is quite as old as t/op/unshift.t or t/comp/decl.t, all lines of
which in the 5.10 release came directly from the 1.0 release:

http://perl5.git.perl.org/perl.git/blame/maint-5.10:/t/comp/decl.t
http://perl5.git.perl.org/perl.git/blame/maint-5.10:/t/op/unshift.t

[I think that the only changes between perl 1 and then was removing comment
lines with an RCS Id. I think that the next oldest unscathed test was
t/cmd/switch.t dating from 3.0, although that had a bugfix in the 5.0 alpha
2 release:

old mode 100644 (file)
new mode 100755 (executable)
index 2af2c9e..faa5de4
--- a/t/cmd/switch.t
+++ b/t/cmd/switch.t
@@ -1,6 +1,6 @@
 #!./perl

-# $Header: switch.t,v 4.0 91/03/20 01:49:44 lwall Locked $
+# $RCSfile: switch.t,v $$Revision: 4.1 $$Date: 92/08/07 18:27:14 $

 print "1..18\n";

@@ -40,7 +40,7 @@ sub foo2 {
     return $_;
 }

-print do foo2(0) == 20 ? "ok 7\n" : "not ok 1\n";
+print do foo2(0) == 20 ? "ok 7\n" : "not ok 7\n";
 print do foo2(1) == 1 ? "ok 8\n" : "not ok 8\n";
 print do foo2(2) == 2 ? "ok 9\n" : "not ok 9\n";
 print do foo2(3) == 3 ? "ok 10\n" : "not ok 10\n";

]

> I'm with Nick on this one. First, I don't expect "exit (@x)" is used often.
> Second, since "POSIX::exit(@x)" does DWIM, and "exit(@x)" doesn't, I don't
> see any benefits on make neither DWIM. Third, who's going to benefit? Is
> potentially breaking existing, working code worth the benefit of "some new
> code that uses an odd construct, now behaves equally unexpected regardless
> whether POSIX is present"? IMO, the benefit doesn't outweight the downside.

The contradiction has been tolerated for 15 years. I don't expect Perl 5 to
to last another 15 years in active development.*

There's up to 16 years' of working Perl 5 code for which there is potential
breakage. Even if Perl 6 is another 10 years late, it still has 6 more years
grace to displace Perl 5 before we get to 16 years of future Perl 5 code.

Nicholas Clark

* But I'm happy to be proven wrong, particularly if it's still fun to
  program Perl 5 in 2026, on a shiny new 5.44.0 interpreter. I wouldn't want
  Perl 5 to be the next COBOL.

Thread Previous | Thread Next