#あれ、ひょっとしてtrunkのGaucheって、provide不要になったんですか?
#はい、だいぶ昔にwishlistに上がってたautoprovideの機能が入りました
#autoprovide入れたのは2008-11-22だから0.9でもprovide不要じゃないかな。正式にドキュメントしたのがいつだったか覚えてないけど。
#おお、そうでしたか
#しばらく使ってないと、知らない機能が増えててびっくりしますね
#Gaucheで、ライブラリモジュールとしても実行プログラムとしても使えるスクリプトを書くには、どうしたらいいんだろう。
#(select-module user)
(define (main args)
(display "org.visha.log.log4j.generator\n"))
#ってのをモジュールの最後に書けばいいっぽいけど、これって他のプログラムからloadすると何度もmainが定義されることになるのかな。
#何か悪影響がありそうで怖い
#あんまりそういう用途は考えてなかったなあ。
#LispはREPLの文化だから、わざわざスタンドアロンのプログラムに仕立てる意味が薄いとは思いますけど
#(試したければloadして個別に関数を呼ぶ)
#というより、Gaucheのモジュールってわりとディレクトリ階層との結びつきが強いので、同じファイルをライブラリにもスクリプトにも、ってのは使いにくいんじゃないかなと思ってた。置き場が違うから。
#でもPerlとかPythonではやってるんだっけ。
#はい。たぶんRubyも
#userモジュールのmainを定義する方法は、mainを持たない実行スクリプトがそのライブラリを呼んでる場合に困ると思う。
#確かにそうですね。そうか、Gaucheではmainは必須ではないんでしたっけ
#置き場の違いは、安直にシンボリックリンクで解消(?)してます
#ないです。mainを特別扱いするのはsrfi-22だけで、
#RnRSではmainは特に意味を持たないですね。
#需要があれば、そういう機能をつけること自体は構わないです。
#必要に迫られているわけじゃないです
#テストを同一ファイルに書いておくのに便利、というのは聞いたことがあるな。ライブラリファイルをスクリプトとして実行するとテストが走る。
#たまたま今書いている(整理している)モジュールを安直に使うのに、そういえばどうすればいいんだろう、と思っただけなので
#なるほど
#*program-name* と (port-name (current-load-port)) を比べる、という手はあるかな。面倒だけど。
#でも、軽量スクリプト言語のライブラリとしては、余計なコードをロード時に読み込んでほしくはないですね。読み込まない仕組みになるのならいいですけど。
#用途によっては多少重くても便利な方がいいってことはあるかもしれない。性能を気にするほど「ちゃんと」作り込む場合はちゃんとファイルも分けることになると思うけど、quick hackでいいや、って場合は別だろうから。
#確かに、自分がGaucheを使う場合のスクリプトの変遷を考えると 1. 書き殴りスクリプト 2. その中の便利そうな機能を他でも使いたくなってモジュール化 3. 拡張/整備 なので
#1~2の過渡期なんかには、単体でライブラリにもプログラムにもなるのは便利だと思います。
#トリッキーな方法だけど、
##!/bin/sh
:; exec gosh -l "$0" -e '(exit ((with-module foo foo-main)))'
(define-module foo
)
(select-module foo)
(define (foo-main)
(print "hello")
0)
#ファイルに実行属性をつけとく必要があります
#あー、パス指定されるとうまく動かないか。
#Perl はモジュールは .pm というファイルに書いて実行スクリプトからは分離するほうが多いんじゃないかな?
#shebangの下をこうすればよかった。
#:; exec gosh -e "(define(main args)((global-variable-ref'foo'foo-main)))" "$0" "${1+$@}"
#おおお。
#Perl 使いは CPAN モジュールを作って目立ちたいという強烈なモチベーションがあるので、みんなわりとちゃんとモジュールをパッケージングする傾向があるかも。
#うわ、すげ...