On 1 Oct 2000, Perl6 RFC Librarian wrote:
> =head1 ABSTRACT
>
> To simplify distribution of programs in binary form,
> support for dump should be kept.
>
> =head1 DESCRIPTION
>
> This would immensely aid distribution of code from one Linux, Windows,
> etc. machine to others without requiring all the recipients to be able
> to install Perl, compile and install modules required by the program,
> and configure their hosts so that Perl find the modules. There are
> also times when pre-loading and pre-processing large amounts of data
> are desirable.
You're kidding, right? Have you ever used this capability? If so, you
should have spoken up when the RFC to remove 'dump' was distributed.
As far as I know, it's rather difficult to turn a core dump into an
executable, so I don't think it "immensely aids distribution of code". I'm
willing to be proved wrong, though; if someone can provide a recipe to do
so and/or point out somewhere this is used, I'd be interested.
> =head1 IMPLEMENTATION
>
> RFC 267 wants dump eliminated mainly because it is a common name for
> user subroutines, bit also because it can be accomplished with a kill
> signal. I really do not care if dump is renamed, but I believe keeping
> the capability is in perl's interest for greater acceptance and use.
Funny, most other languages don't have a 'dump' command, yet that doesn't
stop them from being accepted. Maybe you want a way to get free-standing
executables; well, there's an RFC for that, too. I just don't think dump
is the road to that.
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
