John Tobey <jtobey(a)channel1.com> writes:
Sure, I suppose you could implement a major mode as a separate Perl
process, but who really wants to invent protocols for such things?
Not to mention ways to serialize and deserialize interesting data
structures.
It would be _way_ simpler, incomparable more robust, incredible more
maintainable, and infinitely more useful[1] to have Perl as a
subprocess. And both Perl and Emacs Lisp are really good at
serializing data structures.
However, I have to admit that Emacs as a loadable Perl module, or Perl
as a loadable Emacs module, has a much higher hack-value. Kids today
don't appreciate the power of the Unix pipe any more.
The third option, creating a single Perl+Emacs executable, is simply
to ugly to consider.
So
#1 (Perl as Emacs subprocess): Cool! I want that to part of the Emacs
distribution.
#2a (Perl as Emacs module): Nice! I want the module interface to be
strong enough so that interested third parties can maintain modules
for other languages. However, they should not be bundled or
distributed with emacs as standard.
#2b (Emacs as Perl module): Nice! I want "make perl-module" to work
in the standard Emacs distribution.
#3 (Single Perl+Emacs executable): Gross! Go away!
Footnotes:
[1] And more than that, but I'm running out of adjectives.