Files
quartz-research-note/content/Incremental Functional Reactive Programming.md
松浦 知也 Matsuura Tomoya f08ff8368c
All checks were successful
Build / build (push) Successful in 12m37s
[obsidian] vault backup: 2025-09-23 01:39:19[
2025-09-23 01:39:19 +09:00

31 lines
2.2 KiB
Markdown

---
date: 2025-08-20 15:12
---
#programming-language #research
[[Caleb Reach]]による、信号処理エンジンの[[ライブコーディング]]のための手法の提案。
[49.dafx2013\_submission\_60.pdf](https://www.dafx.de/paper-archive/2013/papers/49.dafx2013_submission_60.pdf)
[[ChucK]]や[[Faust]]など、ライブコーディングでシグナルグラフを丸ごと作り直すタイプの言語では、ディレイやリバーブのテールがコードの再コンパイル時に状態が吹き飛ぶためぶった切れる問題がある。
[[Functional Reactive Programming]]の手法で、各項(状態を持つプリミティブ)毎のユニークなラベルをつけて、再コンパイル時に状態を持ち越せるところでは持ち越せるというやり方を提案している
ただ、単純なテキスト同士の差分比較ではユニークなラベルの増分更新は意外と難しく、例えば
`(define x (+ (f 2) (f 3) 2))`
`(define x (+ (f 5) (f 2) (f 3) 2))`
に更新されたとき、ぱっと見は「`(f 2) (f 3)`の手前に新たに`(f 5)`が挿入された」と考えることができるが、原理的には「`(f 2) (f 3)`をまず`(f 5) (f 2)`へ書き換え、後ろに`(f 3)`を挿入した」と区別することはできない。そうなると新たに挿入された項だけ0で初期化して新たにアロケートする、となった時に、どこを0初期化すべきか決定できない。
きちんと文脈を持ち越すためにはエディタレベルでの編集履歴と突き合わせる連携が必要となる(論文中では[[Emacs]]の拡張として実装しているらしい)
(...でもこれって、「`(f 2) (f 3)`をまず`(f 5) (f 2)`へ書き換え、後ろに`(f 3)`を挿入した」の場合は、「`(f 5) (f 2)`へ書き換え」の時点でリロード、「(f 3)を挿入」の時点で再度リロードってコンパイルのタイミングを細かく分割できればそこまで問題にならないのではないか?)
なおこの言語における関数定義と適用はあくまでコンパイル時計算(+や`*`は状態を持たないランタイム時に実行される計算ノード)