#perlのダイヤモンド演算子のようなメカニズムはschemeと相性がよくないのでしょうか？
#うまく表現できないのですが、これはあると便利だなあと、ふと思ったのです。
#ダイヤモンド演算子のどの面(機能)に注目していますか? 単に一行づつ処理するだけならGaucheでも(do-generator [line read-line] ...) ですよね。
#コマンドライン引数の暗黙処理のことなら、確かに文化の違いがあると思います。Gaucheなら陽に指定する方がいいでしょう。(files->line-generator files) とかやって、filesが()なら標準入力から読むとか。それなら (do-generator [line (files->line-generator (cdr args))] ...) で while (my $line = <>) { ... } とほぼ同じになりませんか。
#コマンドライン引数の暗黙処理はGaucheには合わないんですか。
#単純にコードはそのままでコマンドライン引数の処理ができてしまうのが便利だなあと思ったのです。perl風に空気を読んでline-generatorを生成するようなイメージでできるのかなあとか。
#暗黙のコンテキスト自体と、それが「コマンドライン引数」という特定の要素にハードコードされているって2点が、それぞれ微妙にいまいちなのの二乗になってる感じ。やるとすれば、引数をparameterにして、そのデフォルト値をコマンドライン引数にする、という感じかな。それだと、コンテキストを差し替えたい時はparameterizeでいけるのでいまいち感が解消されます。
#「あるコードの塊を切り取って別のところに持っていってもそのまま使える」っていうのがイイ、っていう感覚があるんじゃないかなと思うんですね。コマンドラインツールとして書かれたコードなのに、loadして適当にコンテキスト設定してライブラリ関数として呼べる、とか。
#そうです。ダイヤモンド演算子を見てそういう印象を受けました。
#ダイヤモンド演算子って外から入力ファイル切り替えられましたっけ。ARGVかなんか強制セットすればいけるのかな。
#でもリエントラントにはならないだろうな。
#こうやるのでは？
#./some.pl < input.file
#もしかしてlocalつければARGVもダイナミックスコープのように使える?
#試してみた。
#print @ARGV,"\n";
sub local_func() {
local @ARGV = ("input");
print @ARGV,"\n";
main();
}
sub main () {
print @ARGV,"\n";
}
local_func();
main();#結果：
#aaa
input
input
aaa
#行けそうです。
#お、いけてますね。なら同じ精神で、コマンドライン引数をparameterにしてそっからデフォルト値を取るようにしたらいいかもしれない。
#Perlはよく知らないんですが、
#while (my $line = <>) {
read_other_file("foo.txt");
// $lineを使ったなんかの処理
}#みたいなコードで、read_other_fileで<>を使っていた場合、ちゃんと動くんですか?
#さてPerlがどうしてるかは知らないけど、コードでオペレータが現れる度にそこでコンテキストを捕捉してジェネレータを作ることにすれば相互干渉は避けられそう。Gaucheでやるなら例えば(do-generator [line (input-files->line-generator)] ...) みたいになって、どの時点でジェネレータが生成されるのかはっきり分かるからもやもや感が減るんじゃないかな。
#<>は<STDIN>の略記だった記憶なので、動くのでは？
#いや、Perlの例で疑問だったのは ARGV を書き換えた時に、多分裏にあるだろうファイルハンドラみたいなものの保存も行われるんでしょうか? でないと、read_other_fileから復帰した時に、どこまで読んだかの情報が失われますよね?
#「初めてのPerl(3版)」p.108には二箇所以上で使うべきでないような記述があります。
#二個目を使う前に@ARGVを再初期化すれば問題ないと脚注にあります。
#RT : shiro: もしかしてlocalつければARGVもダイナミックスコープのように使える? http://t.co/RJOEprTc #そういえば、port->line-generatorやport->sexp-generatorってないんですね
#それぞれread-lineとreadと同じだから、ってどっかに書いた気もするんだけどコメントだったかな。
#あれ、でもport->char-generatorはあるのか。なんでだっけ。
#むー、途中で気が変わったとみた。
#ジェネレータからポートへ変換するgenerator->portがあると面白いですね。
#その視点は無かった。virtual portを使えば書けるな。
#http-getからジェネレータを作って、それをポートにすればいいのかなあと。
#「最初にジェネレータありき」の発想で見なおしてみると新鮮ですね。
#うーん、http-getの場合直接virtual portにしちゃってもいいような… あと、ネットワークリソースが背後にある場合、コネクションを占有するのはあんまり良くないので、http-getを抽象化するならwith-*式、つまり(with-input-from-uri "http://example.com/" (^p (read-line p) etc...)) って形がいいんじゃないかなあ。 #なるほど。
#これ凄い。量が質に転化する証拠を目にしている気分。「でかいニューラルネットにランダムなyoutubeイメージをばかすか喰わせたら勝手に顔を認識するようになったでござる」 http://research.google.com/archive/unsupervised_icml2012.html #RT : shiro: これ凄い。量が質に転化する証拠を目にしている気分。「でかいニューラルネットにランダムなyoutubeイメージをばかすか喰わせたら勝手に顔を認識するようになったでござる」 http://t.co/UsmFiqlq… htt ... #RT : ksmakoto@twitter: RT : shiro: これ凄い。量が質に転化する証拠を目にしている気分。「でかいニューラルネットにランダムなyoutubeイメージをばかすか喰わせたら勝手に顔を認識するようになったでござる」 ht ...
#RT : shiro: これ凄い。量が質に転化する証拠を目にしている気分。「でかいニューラルネットにランダムなyoutubeイメージをばかすか喰わせたら勝手に顔を認識するようになったでござる」 http://t.co/UsmFiqlq… htt ... #これ公式RT拾ってるのかなあ。
#ごめん、mentionsでひっかけてるので公式RTも拾っちゃうんだ。
#あれ、GET statuses/mentionsでinclude_rtsつけてないのに公式RTも含まれちゃうのかな。include_rts=falseとかしないとだめ? https://dev.twitter.com/docs/api/1/get/statuses/mentions #retweeted_statusがあるやつを除けばいいのかな。
#chaton-twitter bridgeで、公式RTを拾わないようにしました。遠慮なくRTしちゃってください。
Gauche > Archives > 2012/06/26