Forking Perl5 with Microperl++?

[rje]

"If I were to implement a language now, I'd write a very minimal core suitable for bootstrapping. ... Think of a handful of ops. Think very low level. (Think something a little higher than the universal Turing machine and the lambda calculus and maybe a little bit more VMmy than a good Forth implementation, and you have it.) If you've come up with something that can replace XS, stop. You're there. Do not continue. That's what you need." (Chromatic, January 2013)

This is in Chromatic's response to Moe, which sounds -Ofun and seems like a good idea.

And now that I've crawled out from under my rock, I see microperl, an ancient tool included with 5.8. Alright, I don't recall ever hearing about microperl. It's not in my copy of the Programming Perl book, and that sucker is a thousand pages.

And lately, haven't I seen grumblings about the insularity and stubborn bikeshedding nature of the Perl community?

So how about this. Microperl isn't the "handful of ops" that Chromatic is suggesting, and it ain't XS, but it's tiny and, well, it's Perl. Therefore, what are the issues around forking and modifying microperl (oh so gently) to bootstrap a variant of Perl5? I mean, it's already written, and it's tiny -- minimal, if Simon is to be believed. I mean, the thing built in a 300k footprint when compiled with a proper optimizer. So what's not to like?

So I re-ask my question. Doesn't microperl seem to be at least halfway to a bootstrap up to a useful and somewhat regularized, normalized, unpackable, what-have-you-able variant of Perl5?

Just for reference, here's a sample microperl script written in zentara's discussion. It seems pretty handily powerful for being a tiny subset of perl. Is there documentation for microperl?

#!microperl

#to substitute for a readdir or glob
#I needed to ls then grep
my @files = `ls`;
@files = grep($_ =~ /.tar.gz$/,@files);
foreach(@files){print "\ngunzipping->$_\n"; system("gunzip $_")}

my @files = `ls`;
@files = grep($_ =~ /.tar$/,@files);
(@bases) = map{$_ =~ m/^(.*)-\d+.tar$/ }@files;
print "@bases\n";

my %hash;
$hash{$_}++ foreach (@bases);
print "$_: $hash{$_}\n " foreach (sort {$hash{$a} <=> $hash{$b}} keys 
+%hash);

foreach $basename (keys %hash){
#initialize first file
if (-e "$basename-1.tar"){
       $old= "$basename-1.tar";
       $new= "$basename.tar";
       rename $old,$new or warn $!;
   }

#the restore-rotate.pl script just swaps files like they were tapes
system ('tar','-x','-M',"-F ./restore-rotate.pl $basename","-f$basenam
+e.tar");
unlink "$basename.tar"; #cleanup
print "----------------------------------\n";
}

system("mkdir proc");
system("mkdir tmp");
system("mkdir home");
exit;

[Corion]

microperl is basically still Perl5, except without the system specific configuration and likely without dynamic extensions (XS). See README.micro as included with the Perl tarball.

I'm not sure what modifications on the language level are worth to be made to microperl that wouldn't be the same if made to Perl5, as they share the same source code.

If you're looking to cut features from Perl (5), for example cutting away tie (thus giving up support for DBI), you can do that with perl in the same manner as with microperl, and it's likely just the same files that you modify. I think that microperl, or at least miniperl are (much) faster to build, so if you're modifying Perl internals, at least during the development stage, building one of the smaller Perls reduces your waiting cycle.

[rje]

AH. Well, if that's true, then my understanding was deeply faulted, and the content of my post is therefore ridiculous.

I've just been trying to wrap my head around writing a simple Turing machine with Lambda calculus that does the *kind* of thing that XS was written for (e.g. using native-compiled modules), all for the purpose of bootstrapping a Perl5-ish grammar which trades compatibility in favor of something a bit more ... well, I don't know, I guess portable the "new" way (e.g. LLVM?) as opposed to portable in the "C" way.

[Anonymous Monk]

I am entertained when someone applies the term bikeshedding to an open source project. Scratch your itch and throw working code at the problem of your choice. Perceived bikeshedding doesn't stand a chance against working code.
TJD