Front page | perl.perl5.porters |
Postings from December 2009
Re: Carp/overload problem exposed by mktables
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
December 1, 2009 06:31
Subject:
Re: Carp/overload problem exposed by mktables
Message ID:
20091201143131.GN2582@plum.flirble.org
On Tue, Dec 01, 2009 at 05:42:50AM +0100, Aristotle Pagaltzis wrote:
> * Nicholas Clark <nick@ccl4.org> [2009-11-30 11:10]:
> > It doesn't gain us anything.
>
> Sure does.
>
> > On any existing version of perl it's not in core.
> > On any future version of perl where it might be in core,
> > it's already possible to write it in pure perl utilising
> > C<no overloading;>
>
> The answer to this is the following:
>
> * Nicholas Clark <nick@ccl4.org> [2009-11-30 11:15]:
> > Also, overload::AddrRef doesn't just want refaddr from Scalar
> > Util. It also wants blessed() and reftype().
>
> That it wants those other Scalar::Util routines is exactly the
> point. They should all be core and Scalar::Util should become
> a thin pure-Perl importer à la feature.pm, instead of an XS
> module.
Yes, but there is a difference. feature enables builtins. In particular,
things that could only be (currently) implemented as builtins.
Also, Yves was proposing fixing a couple of interface anomalies on them,
which would mean the "builtins" would be *different* from the current
versions, so Scalar::Util would still need to keep the old versions as
legacy.
This is a proposal to migrate more XS code into core, XS code which
pretty much works just fine where it currently is. Running stuff under
miniperl is a special case. I don't see that as justification for "it
should be linked into core"
> The DynaLoader part of its current form is regularly screwed up
> by packagers even now, if only intermittently. Is there any
> reason to retain this trap for the unwary, going forward?
I think that a much better technical fix to that piece of political
stupidity would be the appended. And it's backwards compatible with the
existing versions of perl they currently ship. (And I believe will be
shipping until 2013)
> Besides that, with every extra module a piece of Perl code loads,
> the probability that Scalar::Util got loaded approaches 1 ever
> more rapidly. It is unlike every other module and the single most
> `use`d non-pragma by a *very* wide margin.
I believe that neither of us can produce stats on that either way.
And I don't like the argument of "everything uses it" because it feels like
a slippery slope, and as soon as you disqualify the current winner by
bringing it in, there will be another one along soon.
> And it *was* originally supposed to become part of core:
> http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=330AACC8-B5CC-455D-8965-82425FD8A952@pobox.com
>
> * Nicholas Clark <nick@ccl4.org> [2009-11-30 11:10]:
> > So it just makes the core bigger.
>
I've been working hard to make the core smaller. In various ways, including
the size of the executable. The more that can be made hookable so
something can do it in ext/ or on CPAN, the better. This just feels like a
retrograde step.
Also, comments by Adam Kennedy about the "GreyPAN" - all the Perl code in
public but not on CPAN suggests that perl is (still) used for a lot of glue.
I've seen the code that our (oh so lovely) work hosting company wrote, and
they use perl from shell scripts as a better sed, for 1-liners.
There's a lot of less well written stuff out there that doesn't use any
modules. Or at least, not all the modules "modern perl" would use. So I
think it does matter.
Finally, there seem to be 3 different conflated arguments as to why they'd
be good in core
1: for miniperl
2: because a certain Linux "Vendor" screws up repeatedly.
3: for speed
but the latter *isn't* true if all they are is XS code in a C file.
What's actually needed is a way to have them as ops.
Which, as a special case, would mean more ops. Which isn't in itself a
problem, as there's (virtually) no limit on the number of ops we could have.
But I was thinking (and looking at Perl_ck_subr in op.c) that it would
actually be more useful to *add* the ability for an XSUB to declare itself
inlineable, by having some way for it to offer an OP that implements itself.
(Getting the hook in core is probably moderately easy. Getting xsubpp to
compile XS code, or at least a subset, to OPs, probably is doable, but isn't
actually essential for this to be useful)
Nicholas Clark
diff --git a/cpan/List-Util/Makefile.PL b/cpan/List-Util/Makefile.PL
index 1cba5ab..7022f3a 100644
--- a/cpan/List-Util/Makefile.PL
+++ b/cpan/List-Util/Makefile.PL
@@ -8,10 +8,29 @@ use ExtUtils::MakeMaker;
my $PERL_CORE = grep { $_ eq 'PERL_CORE=1' } @ARGV;
my $do_xs = $PERL_CORE || can_cc();
+my $force;
for (@ARGV) {
/^-pm/ and $do_xs = 0;
/^-xs/ and $do_xs = 1;
+ /^-force-pm/ and $force = 1, $do_xs = 0;
+}
+
+if (eval {require List::Util; 1}) {
+ if (!$do_xs && !$force && $INC{"List/Util/PP"}) {
+ die <<"EOM"
+You currently have the full XS implementation of List::Util installed, but I
+cannot find a compiler to let me build a new XS implementation.
+
+The pure-perl implementation does not provide all the functionality of the XS
+implementation, so will not be installed by default, as this is effectively a
+downgrade.
+
+To force a build of the pure perl implementation, use
+
+ $^X $0 --force-pm
+EOM
+ }
}
WriteMakefile(
Thread Previous
|
Thread Next