Emacs Lisp

Emacs Lispは、GNU EmacsとXEmacsテキストエディタ（この記事ではあわせてEmacsと呼ぶ）で使われているプログラミング言語LISPの方言である。Emacs組込みの編集機能のうち、C言語で書かれた部分以外のほとんどを実装するのに使われている。また、利用者によるEmacsのカスタム化や拡張のために用いられる。

Emacs Lisp

パラダイム	関数型プログラミング, メタプログラミング, リフレクション
登場時期	1985年 (40年前) (1985)
開発者	GNUプロジェクト
最新リリース	29.4/ 2024年6月22日 (12か月前) (2024-06-22)
型付け	動的、強い型付け
影響を受けた言語	Common Lisp、Maclisp
プラットフォーム	クロスプラットフォーム
ライセンス	GPLv3
ウェブサイト	gnu.org/emacs
拡張子	.el, .elc, .eln
関連言語	LISP

Emacs Lispはスクリプト言語として使うこともでき、コマンド行や実行ファイルからも呼び出せる。バッファや移動コマンドのような編集機能はバッチ・モードで動作する。

Emacs Lispは、ときに「ELisp」や「Elisp」と書かれたり呼ばれたりすることもある (両表記ともGNU Emacs Lispリファレンス・マニュアル^[1]に見える)。機能でいうと、Common Lispの影響も後にみえるが、Maclisp方言と強い関係がある ^[2]。プログラミング・メソッドとして、手続き指向プログラミングと関数的プログラミングに対応している。関数をデータとして扱えるなどの強力な機能のため、(TECOを拡張言語としていたオリジナルの) Emacsの書換えにあたり、リチャード・ストールマンは拡張言語としてLISPを選んだ。ストールマンがGosling EmacsをGNU Emacsへ書き換えていたとき、Common Lisp とは違ってSchemeは既に存在した。しかし、当時のワークステーションの性能は貧弱であったため、Schemeよりももっと簡単に最適化のできるLISP方言を開発する必要があった^[3]。

例

Emacs Lispで書いたEmacsの簡単な拡張例をあげよう。Emacsでは、編集領域は、別々のバッファを表示するウインドウという領域に分かれる。おおざっぱにいえば、バッファとは (大抵はファイルから) Emacsのメモリに読み込んだテキストのかたまりで、テキストファイルとして保存できる。

新しいウインドウを開くユーザコマンドは、「C-x 2」である。これは、「Control」キーを押下した状態で「x」キーを押し、その後単独で「2」キーを押す、ということだ（空白文字は読み易いように示してあるだけで、打ってはいけない）。このキー列はEmacs Lispのsplit-window-vertically関数を動かし、普通は新しいウインドウに前のものと同じバッファが表示される。ここでは、その次に有効なバッファを表示するようにしたい、ということにしてみよう。そのためには、利用者は、次のEmacs Lispコードを、既存のEmacs Lispソース・コードや空のEmacsバッファに書く。

 (defun my-split-window-function ()
   (interactive)
   (split-window-vertically)
   (set-window-buffer (next-window) (other-buffer)))
 
 (global-set-key "\C-x2" 'my-split-window-function)

最初の文 (defun ...)は、新しい関数my-split-window-functionを定義する。これは、split-window-vertically (前のウインドウ分割関数) を呼び出し、新しいウインドウが別のバッファを表示するようにする。次の文 (global-set-key ...) は、「C-x 2」というキー列に新しい関数を結び付けなおす。

もっと簡単に書く方法もある。Emacs Lispには「advice」という強力な機能があり、利用者は既存の関数を再定義せずに新しいラッパーを作れる。「advice」を使うと、上のコードは、次のように再実装できる。

 (defadvice split-window-vertically
   (after my-window-splitting-advice first () activate)
   (set-window-buffer (next-window) (other-buffer)))

これは、split-window-verticallyが呼び出されたとき、関数の本体を実行する前に利用者の指定したコードを実行するよう命令している。

こういった変更は、たとえば「M-x eval-buffer」コマンドを使ってコードが評価されてはじめて効果が生ずる。Emacsの再コンパイルはおろか再起動さえいらない。Emacsのカスタム化は便利だといわれる所以である。もしEmacsの「立上げファイル」(ふつうは利用者の ホームディレクトリ にある「.emacs」という名前のファイル) にコードを保存すれば、次にEmacsが立ち上がったとき、Emacsはこの拡張を読み込むことになる。

ソースコード

Emacs Lispのコードは、「.el」という拡張子のファイルに、テキストファイルとして格納される（ただし、利用者の初期設定ファイル名は、Emacs21以前では例外として「.emacs」である）。ファイルが読み込まれると、Emacsプログラムのインタープリタ部分が、関数や変数を読んだり解析したりして、メモリに格納する。そうして、他の編集関数や利用者コマンドで使えるようになる。関数や変数は、自由に修正したり、読み込みなおしたりできる。

メモリ空間の節約のため、Emacsの機能の多くは、必要になるまで読込まれない。追加機能一式それぞれは、「ライブラリ」というEmacsコードの集まりで実装されている。たとえば、プログラムソースコードのキーワードの強調用ライブラリやテトリス・ゲームで遊ぶライブラリなどがある。各ライブラリは、ひとつまたは複数のEmacs Lispソース・ファイルで実装される。

一部の関数は C言語で書いてある。これは「プリミティブ」と呼ばれる（「組込み関数」とか「サブル」ともいう）。プリミティブはLispコードから呼び出すことができ、C言語のソース・ファイルを修正し再コンパイルすることでのみ変更できる。GNU Emacsでは、プリミティブを外部ライブラリにすることはできず、Emacs実行形式の一部分となる。XEmacsでは、オペレーティング・システムの動的リンクのサポートを使って、プリミティブを実行時に読み込める。関数をプリミティブで書くのは、Emacs Lispからはアクセスできない外部データやライブラリを用いる必要があったり、C言語とEmacs Lispで実行速度の差が十分認められるほど頻繁に呼ばれたりする場合である。

ただし、C言語でのエラーはすぐにセグメンテーション違反やより些細なバグにつながるため、エディタをクラッシュさせるし、Emacs Lispのガベージ・コレクタと正しく相互作用するC言語のコードを書くことは困難であり問題を引き起こしやすいため、プリミティブで実装されている関数は比較的少数である。

バイトコード

Emacs Lispコードの性能は、「バイト・コンパイル」で向上させることができる。Emacs Lispのソース・ファイルをバイトコードという特殊表現に変換するコンパイラがEmacsにはある。Emacs Lispのバイトコード・ファイルの拡張子は、「.elc」である。ソース・ファイルにくらべると、バイトコードは速く読み込めて、ディスク空間を少ししかとらず、読込み時のメモリーが少なく、速くうごく。

バイトコードは、プリミティブよりは遅い。しかし、バイトコードで読み込まれた関数は、簡単に修正したり、再読込みしたりできる。さらに、バイトコード・ファイルは、プラットフォームに依存しない。Emacsについてくる標準的なEmacs Lispコードは、バイトコードで読み込まれるが、利用者の参照用として、対応するソース・ファイルも大抵付いている。利用者の拡張はそれほど大きくもなく、また計算機の負担も小さいので、普通はバイト・コンパイルされない。

言語機能

「cl」パッケージは、Common Lispのサブセットとしてはかなり大規模な実装であり、注目に値する。

Emacs Lispは、静的でなく (字句的でもなく) 動的スコープを使う。したがって、もし変数がある関数のスコープで宣言されると、その関数から呼び出されたサブルーチンにおいても有効になる。これはもともとは、利用者のカスタム化のための高度な柔軟性を提供するためのものだった。しかし、動的スコープには短所がいくつかある。第一に、別々な関数の変数間での不本意な相互作用のため、大きなプログラムではバグを簡単に生じやすい。第二に、動的スコープ下での変数アクセスは、字句的スコープのそれより、一般に遅い。そのため、Emacs Lispを字句的スコープに変換する、という計画が立てられたが、まだ完了はしていない。「cl」パッケージのlexical-letマクロは、Emacs Lispのプログラマに効率的な字句的スコープを提供している。「cl」はよく使われているが、lexical-letはめったに使われない。

Emacs 24 では静的スコープが使えるようになった。

Emacs Lispは、他の多くのLisp実装でおこなわれている末尾再帰の最適化をしない。最適化されていない末尾再帰は最終的にスタックオーバーフローに至る可能性がある。