Gauche > Archives > 2015/10/25

2015/10/25 03:47:39 UTCkaki
#
質問です。 http://chaton.practical-scheme.net/gauche/a/2013/12/23 で "fが未定義でもエラーにはできない" とありますが、R5RS/R7RSでは評価順序は未規定なので、f を先に評価してしまえばエラーにできる気がします。ここでの問題は、f を(性能的な要求で)後から評価するので、f が未束縛であっても(評価されるまで)エラーにできない、ということでしょうか?
2015/10/25 03:56:36 UTC齊藤
#
同じような疑問を持って後で話題にしてます。 http://chaton.practical-scheme.net/gauche/a/2014/01/02
2015/10/25 04:10:58 UTCkaki
#
ありがとうございます。なるほど。ということはあとの問題は、性能的な、つまり先行チェックのオーバーヘッドだけってことですね。
2015/10/25 07:14:01 UTCshiro
#
全てのグローバル関数コールでチェックを出すとえらいことになりそうだけど、コンパイル時に束縛が見えてたやつは出さないでもいいことにすればそれほどでもないかな。と思ったけどソースに書く順番で出てくるコードが変わるのは気持ち悪いってば気持ち悪いな。
#
あれ、twitterの仕様変わった?
#
URLはtwitter側で短縮されるから一律20文字と考えて良いってことになってた気がしたんだけど
#
s/20/22/
#
その計算で140文字に収まるはずのツイートが文字数オーバーではねられてる
2015/10/25 07:39:50 UTCkaki
#
対象がグローバル関数コールだけで一度束縛された変数が未束縛にはならないなら、未束縛かどうかチェックするのは1回だけでいいので、チェックしたらJIT的に消してしまうのはどうでしょうか。__padding__________本文117文字
2015/10/25 07:47:09 UTCkaki
#
webで見るとURLが23文字で数えられているように見えます。__________________________________________________________________________________116
2015/10/25 07:47:44 UTCshiro
#
それも文字数オーバーになってる>116
2015/10/25 07:48:05 UTCkaki
#
ぐぬぬ
2015/10/25 07:49:04 UTCshiro
#
試しにpostしようとしたメッセージ自体をwebクライアントに貼り付けてみると本文114文字なら大丈夫っぽい
#
てことはURLが26文字扱いになったのかな。FAQの記述とかは変わってないけど
#
で、チェックインストラクション(+対象となるidentifier)で2ワード、一度走ったらNOPにしちゃうことはできるんだけど、NOPでもディスパッチは発生するんでできればやりたくないなあと。
#
むしろ、(leaf expressionでの)unboundエラーが出た時点で実行してるインストラクション列を調べてmatchがunboundであることを見つけられたらそっちの方がいいなと思ってる(コストはエラー発生時のみかかるので)
2015/10/25 08:03:09 UTCshiro
#
いや、23文字になったっていうのが正しいっぽいな。______________________________________________________________________________________________________________________
#
できた。
2015/10/25 08:03:56 UTCkaki
#
あ、名前が入るのを忘れてました。
2015/10/25 08:04:19 UTCshiro
#
ほんとは短縮urlの文字数を得るAPIを叩いてそれを使うべきなんだろうけど、とりあえずハードコード。
2015/10/25 08:12:30 UTCkaki
#
なるほど>unbound。でもその場合、matchが未束縛であることによってunbound以外のエラーが出る場合は検出できませんよね。 (define (f x) (match x ((f) x))) みたいな。これunbound variable: matchエラーにしてもいいですよね。
#
エラーにならないっていうパターンもあります。 (define (f x) (match x (f x))
2015/10/25 08:16:38 UTCshiro
#
ああそうかあ。マクロを関数と解釈しちゃった場合に起こり得るエラーは何でもありえるわけだなあ。
2015/10/25 08:21:56 UTCkaki
#
既に良いJITコンパイラ的なものがあるなら、JITでNOPも消せて気にならなさそう、みたいなことは思いました。でも今はJIT最適化はしてないんですよね。
2015/10/25 08:25:04 UTCshiro
#
今はやってないです。
2015/10/25 09:04:59 UTCshiro
#
別の方法として、関数ごとにその中で参照された未束縛のGREFエントリのリストを持っておくというのはどうだろう。関数がはじめて実行される時にチェックする。GREFインストラクションはどうせ最初の実行時に束縛チェックが行われるから、関数エントリ時にそれをまとめてやってしまっても全体のコストはほとんど変わらない(現在はその時の実行パスにないGREFについてはチェックが遅延されるわけだが、未束縛グローバル変数への参照が後々まで残るというのは気持ち悪いから、それが無くなるってのはプラスでもある)。一度チェックが済んだらリストをクリアする。リストが空かどうかのチェックは関数エントリ時にのみやるからオーバヘッドも少なそう。メモリ使用量は増えるが…
2015/10/25 14:33:22 UTCshiro
#
あれ、このコードではちゃんと動くはずがない、という箇所を見つけたんだが今までちゃんと動いている。謎。こういうの何とかバグって名前があったな。何だったっけ。
2015/10/25 14:57:17 UTCKei
#
schrödinbug?
2015/10/25 15:00:42 UTCshiro
#
ああ、確認したら波動関数が収束してもう動かなくなるからだっけ。
2015/10/25 15:10:07 UTCKei
#
日本語と英語のWikipediaで言ってることが若干違う気がしますが、見つけたら動かなくなるというのは割りと好きかも。
2015/10/25 22:24:01 UTCquasicrane@twitter
#
こんにちは。unbound variables エラーと、 その他のエラーを見分ける手段は、エラーメッセージ以外にあるでしょうか?
2015/10/25 22:48:57 UTCshiro
#
今のところないです。ただ、このアイディアはおもしろそうなので、unbound variableエラーにフックできるようにしようかなあとちょっと考えています。
2015/10/25 23:10:23 UTCquasicrane@twitter
#
ありがとうございます。実際上、メッセージで判断しておきます。
Java っぽい頭だと、UnboundVariableError とかエラークラスを細かく分けるのかなぁと考えてました。特にそうしたいという希望では無いです。
2015/10/25 23:56:47 UTCkaki
#
Gaucheのコンディション型が細分化されていないのは前から気になってました。