(3) 実装の方針 < Viivi Blog < Viiviの小部屋 < 入り口 / Entrance
[NOTE]
This article is written ONLY in Japanese.
I hope you can read the contents through one of the surprisingly advanced latest machine translators,
such as Google
and DeepL.
ここに記載した内容は Viivi に関する 非公式で個人的な考えを雑然と思いつくまま書いたものです. Viivi 開発の背景にある経緯や考えかたを知っていただくために設置しています.
JVM上にScheme処理系を実装することには,ユーザから見たときには その処理系が広範なプラットフォーム上で作動することを期待できるという利点があります. 実装する側からすると, 信頼性の高い Java API が部品として使えることや, 実装時に厄介な課題となるgarbage collectionをすべて JVM に任せられるという 大きな利点があります.
その反面,JVMはその内部のデータへのアクセスが制限されており, 外部から参照したり操作したりすることができません. そのためViiviはすべて自前で インタプリタに必要な構造を用意しその処理を管理しています.
Viiviの実装は, 特定のプラットフォーム(ハードウェアやOS)の構造には依存しておらず, プラットフォームから見ると高い抽象性を持っています. JVMの特定の機能にも依存していません. つまり,JVMと似たような動作(例外処理をすることくらいです)をして 似たようなAPIを提供するプラットフォームへなら,Viiviは非常に簡単に 移植できるはずです. これから出てくるであろう Object-Oriented なプラットフォームでも 同様のサービスは提供してくれるはずですから,簡単に移植可能であると考えています.
一方,実装する人間(つまり僕)から見るとViiviの構成は非常に具体的です. Viiviインタプリタは, Backus-Naur Formにしたがい JavaCC (BSD ライセンス) で記述されたパーサ部分を除いて, オブジェクト指向言語Javaで設計・実装された 明確な物理的イメージを持つ具体的な部品から成り立っています. 例えばもし僕に木材加工の技術があったら,木工細工でインタプリタ装置を組み上げられます(ウソ). それくらい具体的なイメージを持ってOOP設計しているということです.
他の処理系の内部は全く参照していません. R5RSをはじめとするSchemeの言語の説明やサンプルコードの評価結果を見て, そこからこうあるべきだというインタプリタの物理的な内部構造をイメージして Viiviを実装しました. ですからScheme言語処理系として厳密な規格から外れた挙動をしたり 熟練のSchemeユーザなら当然期待する動作とは異なる挙動を取る場合があるかもしれません. お気づきの点がありましたらどうかご指摘ください.
(3) 実装の方針 < Viivi Blog < Viiviの小部屋 < 入り口 / Entrance
2010/10/24 開設
Copyright(C) 2003-2022 ilma <ilma@viivi.io> All rights reserved.