#ああ。そういうの既にあるんですね。JTL 。Mosh に JIT compilation のせたら、Mona OS のドライバを Scheme で書いて一度目はインタプリット、2度目以降はコンパイルされたネイティブコードというのを狙っていたんですが。
#JTLとかのadaptive compilation
#は、n回めとm回め (n != m) で実行されるコードが違う場合があるので、
#完璧に動いてるならいいんだけど、トラブルがあると面倒そうだなあと思う。
#再現条件を見つけるのが大変。
#素直なJITの方がその点ではずっと楽じゃないかな。
#おー。なるほど。ググってみたら首藤さんの JavaHouse での投稿が見つかった。
#ただ、ソフトウェアの複雑性が2〜3桁上がるような時代になったら、人間が全ての動作を決定的に把握するというのは無理になるんじゃないかと思う (今でももう限界か?)
#そうなるとどうせ機械的検証に頼らざるを得なくなるから、
#adaptive compilationでどうコードが変化しようが仕様が保たれているということが機械的な証明で担保されるならそれでよしってことになるのかなあ。
#たとえ、誰もたった今、n回目のループでどんなコードが動いているのか把握していないとしても。
#「仕様が保たれているコード」を生成する adaptive compiler を書くのがそもそもしんどそうだなあ。あ。でも証明機械が「これこれこういう場合に矛盾するよと教えてくれれば良いのか」
#どっちかというと、コンパイラ自身を一種のコード変換器とみなして、入力と出力で仕様部分が不変であるってことを証明する感じなのかな。
#人間ががんばる部分は、仕様の提示の部分か。
#$ cat test.scm
(use srfi-1)
(define (main args)
(delete-duplicates (append '(a) (if #f #t))))
$ gosh test.scm
Bus error
#再現した
#定数リスト破壊で変なことが起きてるかな。
#いや、定数リスト関係ないや。
#gosh> (delete-duplicates (cons 'a (undefined)))
Process scheme segmentation fault
#なおした。
#引数がdotted listだったときになんか変なことやってた。
Gauche > Archives > 2009/07/27