[Resarch notes NOT A SOLUTION]
A process of research and reflection on the following:
- Organize useful use cases.
- Explore some ways to use Common Lisp from a web browser.
-
Common Lisp で作った関数やアプリケーションをJavaScript に変換し、ブラウザ上で実行できる
- as a Portable way.
-
Common Lisp のREPL 環境をブラウザから使う
- Debugger
- Condition System
- Inspector
- IDE
- Editor
- Paredit
- Code Complete
- Tags
- Ref. Hyperspec
- Language Server Protocol - https://microsoft.github.io/language-server-protocol/
- Editor
-
ブラウザを仮想マシン(Lisp マシン)とみなす。そのホスト言語としてJavaScript の代わりにCommon Lisp で書けるようにする。ブラウザをOS とみなしAPI を駆使する。
-
Common Lisp のライブラリが使える
-
JavaScript のライブラリが使える
-
Bidirectional evaluation(双方向評価) by Baku Hashimoto https://baku89.com/2020/06/26/c-activity https://github.com/baku89/glisp/
-
ブラウザからCommon Lisp がどのように見えるべきか?
- 陰に
- 必要な時にREPL やエディタを立ち上げることができる
- JavaScript のConsole のように
- JavaScript のConsole からCommon Lisp が使える
- 陽に
- ブラウザーがまるごとREPL 環境となり、JavaScript の開発環境となる
- 陰に
-
Web サービス開発
- SPA etc.
- React etc.
- From Backend to Frontend.
- バックエンド側のCommon Lisp コードと、フロントエンド側のJavaScript にコンパイルされるコード開発はすべてサーバー上で行う
- →今回はブラウザーでCommon Lisp を動かす環境の話題だからこの利用例ではない
- バックエンド側のCommon Lisp コードと、フロントエンド側のJavaScript にコンパイルされるコード開発はすべてサーバー上で行う
-
ブラウザーからサーバー側Common Lisp のREPL でSBCL として使え、SBCL で作ったJavaScript がブラウザー側にもってこれて動く。こういうユースケースが自然じゃないだろうか?
- すべてのCommon Lisp がJS に変換できなくてもよいと思う
- であればJupyter でこれが実現できているかな?
- デバッガーはどうだ?
-
もし、Common Lisp がJavaScript にコンパイルされるというとき、それは処理系まるごとがJavaScript 上で動くことも意味する
- この場合、Emscripten によるWebAssembly 書き出しということになるが、現在実現されていない他、デメリットも考えられる
- SBCL のイメージをダウンロードするのに時間がかかる
- それはCommon Lisp そのものであり、JavaScript やJavaScript で叩くWebAPI が使えない
- したがってそのSBCL 上でParenscript を読み込んでJavaScript コード書き出しを行い、それをなにかの方法でブラウザー側に渡し実行する手段が必要となる
- ホストOSがないのでファイル保存などもできないのではないか?
- この場合、Emscripten によるWebAssembly 書き出しということになるが、現在実現されていない他、デメリットも考えられる
-
ポイント
- ニーズの観点
- Common Lisp でJavaScript のコーディングができること
- Common Lisp で(サーバー実装は当然できるが) Web のフロントエンド開発もできる
- ブラウザー上でCommon Lisp 処理系(更に開発環境)を持てる
- Common Lisp でJavaScript のコーディングができること
- 技術の観点
- サーバーとクライアント側の役割分担をどうするか
- JavaScript にコンパイルする内容に、Common Lisp そのものを含めるのかどうか(ex: デバッガー, GC, スペシャル変数, etc.)
- ニーズの観点
- common lisp jupyter - https://github.com/yitzchak/common-lisp-jupyter
- Like a https://replit.com/languages/elisp
- SLYME/SLY のWebSocket クライアント実装はある?
- Not at now
- (Scheme is Here: http://feeley.github.io/gambit-in-the-browser/)
- valtan[alpha version] - https://github.com/cxxxr/valtan Common Lisp to JavaScript compiler
- jacl - https://tailrecursion.com/JACL/ JACL: A Common Lisp for Developing Single-Page Web Applications.
SBCL ではx86_64(多分x86も) のネイティブコードにコンパイルされる。 そのバイナリーをJavaScript 側で受け取り、x86 として実行できればいいのか?と考えた。 - 👎 この考え方は筋が悪い。OSのシステムコールやDynamic Link Library 等も用意せねばならないのではないか。
この場合OS のイメージ読み込みから必要であり、読み込みに時間がかかる。 更に、仮想マシン側からホスト(ブラウザー)側で実行するJavaScript コードが書き出せればよいのだが、そこまでの仕組みがあるかどうか。 なければただの仮想マシンでしかない。