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

Re: The future of POSIX in core

Thread Previous | Thread Next
Nicholas Clark
September 2, 2011 11:40
Re: The future of POSIX in core
Message ID:
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 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". 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.

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:

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:

[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 @@
-# $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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About