Gauche > Archives > 2013/04/24

2013/04/24 07:17:56 UTCyamasushi
#
lib/util/list.scmの
#
(define assoc-set!  (with-module gauche assoc-set!))  ;liblist
(define assq-set!   (with-module gauche assoc-set!))  ;liblist
(define assv-set!   (with-module gauche assoc-set!))  ;liblist
#
なんですけど、assq-set!とassv-set!の定義のところが気になるのですが・・・
2013/04/24 09:04:47 UTCkaki
#
そういえば (setter assoc-ref) とかって定義されてませんよね.あと (setter array-ref) とか (setter sparse-vector-ref) とか (setter sparse-table-ref) とか.
2013/04/24 09:48:49 UTCshiro
#
わはは。コピペして直し忘れですね>util/list.scm
#
そのへんのsetterが無いのは単に忘れてただけだと思う。気づいたら指摘してください。その都度足します。
2013/04/24 09:56:17 UTCyamasushi
#
__FILE__、__LINE__みたいな特殊変数ってあるのでしたっけ?
#
デバッグするときに、どこだっけ?ということが多々あるので、#?= __FILE__ __LINE__
#
みたいな感じでマークをつけておきたいのです。
2013/04/24 09:59:56 UTCkaki
#
なるほど.また見付けたら報告します>setter
2013/04/24 10:07:33 UTCshiro
#
ああ、それは前に話題にしたことがあったけどどこだったかな>__FILE__。今でも、#?=の後の式が単純な変数や定数でなければその場所が表示されますよね。処理系の中ではファイルと行数の情報は取れているんです。そこで、例えば(source-pos)のようなマクロ呼び出しでソースファイル名と行数に置き換えられるようなマクロを書くことは出来ます。ただ、Cプリプロセッサのように使えないんです。
#
というのは、Gaucheが取れる情報は「そのフォームがソース上に実際に出現した場所」です。したがって「(source-pos)を含む式に展開される便利マクロfoo」を書いて、fooを使った場所で簡単にその場所がわかるようにしよう、と思っても、表示されるのはfooが展開された場所ではなく、fooが定義された場所になっちゃうんです。Cプリプロセッサでは、__FILE__や__LINE__は変数名のまま展開されて、展開が全て終わった後に、展開後の場所の情報に置き換えられますよね。
#
Cプリプロセッサは行指向なので展開後にもファイル名や行数がわかるんですが、Gaucheの場合、マクロ展開をする時点では既にソースファイルからは離れてしまっているので、「場所」という概念が無くなっちゃってます。
2013/04/24 10:12:34 UTCkaki
#
http://chaton.practical-scheme.net/gauche/a/2009/05/22
#
この辺りですかね
2013/04/24 10:13:29 UTCshiro
#
まあ、「マクロ呼び出しが出現した場所のソース情報」を何らかの形でマクロ展開器からアクセスできるようにしてやればいいのかもしれない。マクロ展開器を含めた改造が必要になりますが。
#
ああそれですそれです。>kaki
2013/04/24 10:33:55 UTCyamasushi
#
ということは、#?=で単純な値の時にファイル名がでないのは、その情報がとれないから、ということですか?
#
()で囲むと出るのはなぜだろうなあと、いつも不思議に思っていました。
2013/04/24 10:38:57 UTCshiro
#
そうです。純粋に実装上の都合で、ソース情報はリストの先頭のペアにだけ保存されるようになっています。
2013/04/24 11:06:38 UTCshiro
#
まてよ、(assoc-set! alist key val)はalistを変更するとは限らないんだな。(set! (assoc-ref var key) val) でkeyがまだvarに無い場合、var自身も変更されるべきだろうか。つまり (set! var (assoc-set! var key val)) の動作をすべきだろうか。
2013/04/24 11:17:00 UTCshiro
#
あーでもCLのsetfと違ってsrfi-17は手続きレベルで動くから、(set! (assoc-ref (another-expr arg) key) val) となった時困るんだな。setterが呼ばれた時点では(another-expr arg)が既に評価済みなので、(set! (another-expr arg) (assoc-set! ...)) としたくてもできない。
2013/04/24 11:35:07 UTCkaki
#
あー,assoc-set! は filter! みたいなそういうアレなんですね(線形更新っていうんでしょうか).他の *-set! と同じように使えるのかと勘違いしやすそう,と思ったけど alist が () の時を考えれば自明かな…
2013/04/24 11:46:35 UTCshiro
#
まあ、本来alistは更新して使うようなデータ型ではない (上書きの時は新しいペアをpushして前のやつをシャドウする) んで、assoc-set!とはあるべきじゃないのかも。とはいえ現実にはあると便利な時がたまにあるんでやっぱり用意しときたいけど。
2013/04/24 21:41:49 UTCyamasushi
#
gosh -Eと同じことを、replでできたら便利じゃないかなと思います。というのは、gosh>d hoge とよくやってしまうからです。
#
特定の文字だけに反応して、括弧を補完してくれればいいかなと。今の場合だと、dです。(個人的には$もあると便利だなと。)
#
試しに入れてみたいのですけれど、これはどこをいじるといいのでしょうか?