develooper Front page | perl.perl5.porters | Postings from August 2010

[PATCH] Support B::Generate and B::C

Thread Next
From:
Reini Urban
Date:
August 29, 2010 03:11
Subject:
[PATCH] Support B::Generate and B::C
Message ID:
4C7A3230.3010204@x-ray.at
Sorry for the rant, skip to the patch attached

Are there plans by p5p to make certain core function public so that 
B::Generate and the perl compiler can be used after 5.10?
Or is nobody else allowed to write cop labels, alloc pads, fold 
constants or clone CVs?

   https://rt.cpan.org/Public/Bug/Display.html?id=28912
   http://code.google.com/p/perl-compiler/issues/detail?id=41&can=1

B::Generate needs pad_alloc, cv_clone, fold_constants and used since years.
B::C used CopLABEL_set since 1995, but is now disallowed using
store_cop_label and misses static destruction support
(a latefree bit) for hek's.

The only way out seems to through away those modules, or to have a plan 
for 5.14 to support them again.
It makes me sick to rewrite most parts of core just because someone went 
berserk and enforces the believe it should not be used outside core 
although it is used since 10-15 years. And nobody detects it because you 
are just lazy and linux still allows calling private funcs, and on 
cygwin I just use --export-all-symbols to be compatible with linux lazy 
linking. Who is trusting AIX and MSWin32.
I will not rewrite pad_alloc, cv_clone, he's and hek's, ... and keep 
maintaining that mess. This is not the idea of libraries.
Those modules used these functions from the very beginning.

And if p5p decides that this too private for other modules to use.
It's too late! Explain the users why you don't want this.
You want nifty optimizations, want to help companies, suggest
trying out tail call or and_not optimizations, but remove the
needed exports for them.
-- 
Reini Urban

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About