20 March 1999

Perlmacs Rationale

The Perlmacs modifications to the Emacs source tree conform as much as possible to the standards and conventions of Emacs. You can exclude Perl from Perlmacs entirely by configuring with --disable-perl. It took quite a bit of work to merge the differences between Emacs 20.2 and 20.3 into Perlmacs, but I intend to do the same when the next Emacs release appears. I make this effort to maximize the likelihood that the patch will be accepted by the Emacs maintainer, since, if it were accepted, Emacs updates would automatically apply to the Perlmacs code.

When I originally approached Richard Stallman about the patch, he thanked me but rejected the idea of linking Perl into Emacs. Instead, he pointed out that an FSF goal is to replace Emacs' Lisp interpreter with its Guile Scheme implementation and write translators (in Scheme) to convert both Lisp and Perl code to Scheme. RMS acknowledged that the task would be difficult and asked whether I would like to work on it. I expressed skepticism but downloaded Guile, joined the Guile mailing list, and proceeded to learn Scheme.

I have not ruled out the possibility of working on a Perl-to-Guile translator, and I frequently think about how I would go about it. However, after a few months on the mailing list, I became reasonably convinced that:

  1. Guile was then (at version 1.2) far from suitable for a task such as emulating Perl and should probably be completely reimplemented; and
  2. A Perl interpreter limited to what could be translated into Scheme for working with Scheme data would seem crippled in comparison to the "real" Perl program, at least until it was capable of compiling and using Perl XS modules.

After a 6-month rest, I became interested in finishing up Perlmacs.

RMS objected to supporting Perl directly on the grounds that it is "messy". He may have meant that the interpreter implementation and API were unsuitable for a program as serious as Emacs, but I think he was referring to Perl's syntactic complexity. I do fault Perl for being non-machine-readable (except by perl). Scheme is pretty good in that respect, which can be important in an application scripting language, where the application should be able to update configuration files in response to actions of users who may not know the config file syntax.

But I also agree with Larry Wall's belief, expressed in a speech at the LinuxWorld Conference & Expo, that "the very fact that it's possible to write messy programs in Perl is also what makes it possible to write programs that are cleaner in Perl than they could ever be in a language that attempts to enforce cleanliness."

Probably no seasoned Perl programmer, no matter how much a purist, writes Perl code that is as easily parsed as Scheme or Emacs Lisp, but there is a value in human readability and intuitiveness apart from syntactic minimalism. Perlmacs offers the best of both worlds. The config file can still contain Lisp code, and commands have access to the vast and ever-growing Perl module library. Guile translators could provide the same benefits, but they do not exist. And unless someone is even more fascinated than I by the challenge of translating Perl to Guile, I doubt that it will happen for at least a year or two... until I get around to it. :-)

--John Tobey