04/10/18 10:27:07
>>842 ぐぐれ
>>843 処理系に固定化され、固定化されたコードはそれ以上進化する余地なくなるということ。
>>844-845
そのリンクの文章のことではなかったけど、その中から異論を唱えると、
>実行時に、その言語のための環境(スクリプトライブラリ、初期化ファイルなど)を
> フルセットで持てるとは限らない。 最悪の場合、アプリケーションはそのバイナリ
> 単体で動作することが要求される。
これは単にアイデアが枯渇しているだけだろう。
実行ファイルに環境を埋め込む手段はいくらでもあるし、さらにその上に
環境の永続化という手段もある。
>アプリケーションの実行の主体はC/C++で書かれたコードで、
> その中から頻繁にちょっとしたリスト処理や文字列処理なんかが呼び出される。
これはevalそのものやVM、マシンコードの入り口を用意していれば済む事。
それに結局GCを伴うので、現実的には外部から頻繁には呼び出せず、一括して呼び出す方針になりがち。
そもそも外部のコンパイラが必要な時点でプロダクション環境とやらには論外だろう。
>むしろ、 memqなんて基本的なパーツはCで書いとくべきなんだ。
memqの様なすぐ代替が利く極端に小さいパーツならこの手も有効だろうが、
少しでも大きな処理になるとこの思想は破綻する。作者もそれはわかってるみたいだが。
結局実際は実装が二極化し、複雑性が増加しただけだろう。
組み込みスタブ関数郡のメンテナンス性の悪さを見ればわかる。
こんなところか。