#gosh precompってモジュールにしか対応してないんですか?
#$ echo '(print "Hello, world!")' > hello.scm
$ gosh precomp -e hello.scm
$ gauche-package compile hello hello.c
hello.c:50:1: error: unknown type name 'SCM_EXTENSION_ENTRY'
SCM_EXTENSION_ENTRY void Scm_Init_hello() {
^
#HOWTO-precompile.txtに書いてあるgreetモジュールの例は動きました。
#Gauche本体の src/*.scm もprecompileしてるので独立したモジュールでなくても使えなくはないんですが、その使い方はどうなるかわからないのでドキュメントしてないです
#これまで拡張モジュールとしての使用しか考えてなかったんですが、static linkもサポートしたんでスタンドアロンプログラムにするっていう道もあるのか
#今やろうとしているのは、兢プロ(のAtCoderのレギュレーション)ではコンパイルと実行を分けられるので、コンパイルフェーズのうちにコンパイル時エラーを検出したり、マクロ展開を済ませておくことです。コンパイル時エラーだとペナルティがないけど実行時エラーはペナルティがある、みたいなことがあるようなので。
#AtCoderのサイト上でコンパイルフェーズを走らせることができるってことですか? もしコンパイルとして走らせるコマンドを指定できるなら、test-moduleやtest-scriptによるチェックをコンパイルとして走らせるとコンパイル時エラー検出は出来たりしませんか。
#マクロ展開の時間は実行時にまたかかっちゃいますが。
#はい。なるほど、コンパイル時エラーに関してはこれでもいけそうですね。ただ、偽陽性があるのがちょっと怖いです。gosh precompしてその結果を捨てるだけなら、test-scriptのような偽陽性はありませんか?
#(まあ現実的には兢プロで提出されるようなコードで問題になるような偽陽性のエラーはないかもしれませんが)
#細かいところまで覚えていませんが、precompの方がチェックが「緩い」はずです。本当は通るコードをtest-scriptがはじいてしまう可能性はありますね。具体例はすぐには思い浮かびませんが、多分コードの方を工夫すれば回避できることが多いんじゃないかな...
#ありがとうございます。test-scriptで問題なさそうならこれをAtCoderに提案しようと思います。
#あ、でもこれ load するのでってトップレベルで (read) とか書いちゃってたら駄目ですよね。やっぱりprecompかなあ。