On a nostalgic lark I searched Google for "Perl Python Parrot" and was
astonished (and excited) to discover the Parrot project.

The Parrot FAQ states that Parrot must run on all platforms on which
Perl 5 runs, including classic Mac OS.  I've been implementing a
POSIX-like environment for Mac OS (unfortunately named LAMP) that given
sufficient development could provide or mimic most POSIX facilities.  
LAMP's kernel (named Genie) is a regular Mac application that doesn't
do anything weird like futz around with the virtual memory system,
which while true means that fork() is absolutely impossible, since all
processes share the same address space and therefore process images
can't be copied (though vfork() can be managed with either a longjmp()
hack or a change in semantics).  I hope this isn't a showstopper.  If
Parrot's process contexts can be duplicated, then scripts can be made
to fork even though parrot itself can't.

Genie more or less supports multiprogramming, signals, blocking I/O,
and polymorphic file descriptors including pipes and sockets.  Programs
are built as CFM plugins (dynamically loaded shared libraries), and
each process runs in its own Mac OS thread.  Implementing threads and
dynloading *within* a Genie process shouldn't be too hard.  So,
contrary to MacPerl's approach of being a Mac application, I'm
suggesting that parrot simply target a pseudo-POSIX layer and punt the
Mac-specific details.

In case it's of interest, I also have Mac OS X, Linux/i386, and
Linux/m68k systems.

Josh