--- title: Glispはステートレス date: 2024-06-28T01:00:44.000Z updated: 2026-01-08T14:50:59.341Z tags: - glisp url: https://baku89.com/ja/Glisp%E3%81%AF%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%AC%E3%82%B9 --- # Glispはステートレス 書きかけ 元は静的なデータを表現するために設計された記述言語に、ある種の〈プログラム性〉を後付けしたくなることは常々あります。 例えばCSS variablesは「値の再利用」、CSS Functionsは「動的に値を算出するための式の記述」、HTMLでいえばShadow DOMやHTMXは、OOPにおける「カプセル化」に対応します。ちなみにこのドキュメントでは、こうしたプログラミング言語がもつ抽象化、自己拡張能力を、ざっくりと〈プログラム性〉と呼び表してみることとします。 Glispの基本的な発想は、CSSやXMLのような宣言的言語にどうせ後からプログラム性を追加したくなるのであれば、**プログラミング言語そのものをデータ構造の記述に用いようよ**、ということに尽きます。ページ記述、ベクターグラフィックス、或いは映像編集のためのプロジェクトファイル。そうした一見静的なファイル形式にプログラミング言語機能を溶け込せ、先に述べたような〈プログラム性〉を付加せんとするのがGlispの目標です。そのためには、プログラム、しいてはコンピュータにおける計算モデルというものを考え直してみる必要があります。 その前に、既存の制作ツールやフォーマットが、どのように〈プログラム性〉を取り入れてきたか、振り返ってみます。 ### エクスプレッション言語を埋め込む プロジェクトファイルを記述するための言語とは別に、パラメーターに動的な計算を可能とするエクスプレッション言語を埋め込むというアプローチは、多くのデザインツールに見てとることができます。例えばAfter EffectsはXMLなどをそのプロジェクト記述言語として用いますが、エクスプレッション言語にJavaScriptを採用し、位置や回転といったパラメーターに式を設定することができます。エクスプレッションからは`time`、`transform`のようなグローバル変数を介して、他の様々なパラメーターを動的に参照することができます。HoudiniにおけるHscriptやVEX、TouchDesignerにおけるPythonなどもこのカテゴリに属しますね。\ ![](https://wp.baku89.com/wp-content/uploads/2026/07/scrapbox-667e9b2041adea001d1d38f3.png)\ しかしこのアプローチの欠点は、一度エクスプレッション言語の内側に閉じ込められたパラメーターは、スライダーやビューポート上のオブジェクトを通した直接編集ができなくなるということです。当たり前な話、コードを更新するには常に文字入力による離散的な編集を強いられるのです。 その解決策の一つとして、**コード内で頻繁に調整が発生しそうなパラメーターをUIとしてエクスプレッション言語から昇格させてあげる**方法があります。After Effectsには、「スライダー制御」という、ただスライダーを表示するだけのエフェクトが存在します。これはエクスプレッションの中から参照されるためのダミーエフェクトで、映像自体には何の影響も及ぼしません。 ![](https://wp.baku89.com/wp-content/uploads/2026/07/scrapbox-667e9d0a7cb1f0001cc7f5dc.png)\ このようなアプローチは、他の様々な制作ツールにおいても見てとることができます。 - Houdini ― `ch("../path/to/param")` - openFrameworks ― ofxGUI, ofxImGui - TouchDesigner ― `op("../path/to/op")["parm"]` - Web開発 ― dat.gui ファイルフォーマットにおいては、HTMLにおけるJavaScriptなどがその代表例です。 ### データとコード ここで対比されているのは、GUIを通して滑らかに操作することのできる**データ**と、文字入力によってプログラムできる**コード**の存在です。データは、数値や色、画像、文章のような、ツールによって操作可能な**「もの」**を指します。コードは、これらのデータを元に新しいデータを作り出したり、何かかしらの作用を生み出すための**「手順」**を表します。ここでプログラムの語源を引いてみると、 _pro-_（前に） + _-graphein_（書く）、つまり「前もって書かれたもの」を意味します。つまり、プログラミングとは、コンピューターが計算を実行するための手順を、その実行に先立ってコードに書き表すことに他なりません。そしてプログラムが実行時に読み書きする対象こそがデータです。 ![](https://wp.baku89.com/wp-content/uploads/2026/07/scrapbox-667f8d866e2c1f001c5bb5eb.png)\ コンピューターが「パーソナル・コンピューター」として誰にでも使えるよう発展していった過程で大きな障壁となったのは、コンピューターという他者が人に代わって計算をするという間接性にあります。通常、コンピューターが計算を実行している最中にそのプロセスを覗き見ることはできず、プログラマーはコンピューターが計算をするための指示全てを前もって与えなくてはなりません。対話型インターフェースやオブジェクト指向といった概念は、コンピューターに触れるために実行に先立って考えるべきことの量を減らし、考えながら触れることを可能としました。しかしコンピューターを制作に使う私たちにとって最も重要なブレークスルーは、GUIによる直接編集（[Direct Manipulation](/direct-manipulation)）の実現でしょう。文字列のようなシリアルなメディアに代わって、２次元平面にパラレルに展開されたインターフェース上で、データはドキュメントやキャンバスとして視覚的に表現されます。ここで私たちははじめて、コンピューターを計算の代行装置としてではなく、データという「もの」を中心としながら、そこに操作を重ねていくための鉛筆や絵筆のような、いわば身体を延長する道具としてコンピューターを扱うことができるようになりました。しかしコンピューターは静的な道具 = アプリでもって静的な「もの」 = データを操作するための環境\ ![](https://wp.baku89.com/wp-content/uploads/2026/07/scrapbox-66802c12f4cfbf001cd39778.png) 文章作成にしてもデザインにしても、最終的に私たちが作り上げたいのは、文章なりグラフィックという「もの」そのもの、つまりデータです。多くの制作ツールの操作の対象も、そして最終的に出力すものもるデータとなります。この目的におけるコードは、「もの」を算出するための　それは説明 しかし、データが「それが何であるのか」を記述した説明文であるのに対して、データを生み出すためのコードは「どのようにしてそれを求めるか」を手順化したものであり、そこにはこの2つの表現の間には大きな隔たりがあります。 ### コード [#glisp](glisp)