nakamura
nakamura といいます.
すっかり scheme にはまってます.
WiLiKi って便利なのですねえ(wikiなページに書き込んだことなかったので).
いろいろ質問させて頂くかもしれませんがよろしくおねがいします.
(2004/04/09 11:24:55 PDT)
このごろ Gauche-gtk でエディタ作ったらどうなるかなと試してみてます.
ツッコミどころは満載かと思われるのでどうぞツッコんで戴ければと...
つか自分とこじゃなくてコッチの WiLiKi に色々書かせてもらおうかなあ.
http://homepage1.nifty.com/blankspace/scheme/editor/index.html
- shelarcy(2004/04/09 18:57:35 PDT) :昔得た情報によると、Guile Emacs はものすごくゆっくりとした速度で進んでいるようです。……ああ、探すのに苦労した……
72 :デフォルトの名無しさん :03/11/14 07:08 一応やってんのかな。 http://savannah.gnu.org/cgi-bin/viewcvs/guile/guile/guile-core/lang/elisp/ChangeLog?rev=1.11&content-type=text/vnd.viewcvs-markup guile-emacs 0.1 で動くことはわかったので、Emacs 側への統合開始の条件である Emacs Lisp との 100% 互換を目指してるはずだけど… このペースだと使い物になるのは10年後くらいか。
- nakamura(2004/04/10 11:18:37 PDT) あ, ほんとうだ. すごいまったり進行ですね. 動的スコープがあるから100%互換て大変そうだなあ.
にしてもShiroさんの「プログラミングと体力」には目からウロコがボロボロです...
- Shiro (2004/04/10 00:12:18 PDT): Edge見ました。すごいですね。
私もPangoとか、input methodのあたりを理解してないのであんまり
お役に立てませんが… defunでデフォルト値を取るようにするのは、
メソッドディスパッチやるかわりにlet-optionals* を挿入するってのは
どうでしょう。
- nakamura(2004/04/10 11:18:37 PDT) をを, こんなマクロがあったとは. ありがとうございます. そうかlet-optionals* ってまさにこういう場合に使えるんですね. わらわらと同名のdefine-methodが増えるのは自分でも微妙だなと思ってたので, ちょっと試してみます.
考え中だったり不明確なこと
- Emacs lisp でいうところの advice はどうしよう.
- Lisp:Geometry の中の「究極のフック」みたいなことが可能?
- あるいはskimuさんのggcで見つ けたtraceや, koguroさんのGauche:プロファイラのように参照を多段に持っていろいろやれば可能?
- 上記2つのどちらかで可能ならばエディタの機能とは独立してるので Gauche のモジュールにしたい. もし難しいなら, マクロ defun でくるんでいる関数定義についてS式をどっかに保管しておいて, advice のたびに再構成して評価し直すとかやればできるかな?まさに Emacs の関数セルのノリで.
- Shiro: 「再構成して評価しなおす」なんてことをしなくても出来そう
な気がします。単純には、defadviceされた時点で関数オブジェクトを
applicableなオブジェクトでくるんでやれば、そいつのobject-apply中で
いろいろできますね。より壮大なゴールとしては
<generic>をサブクラスしてCLOSのメソッドコンビネーションを付けられるようにする
ってのもありますが、引数の型によるディスパッチを入れなければならないので
ちょっと面倒だと思います。
- nakamura(2004/05/22 00:20:59 PDT): そうか, 関数をくるめばいいから元の S 式の保管なんて不要ですね. ちょっと作ってみました. advice.scm applicable なものを lambda そのものにしてみました.(少し書き加えたらゴテゴテしてきてた...) before, after は around から作れそうかなと思います. CLOS のメソッドコンビネーションってのがまだよくわかってないんですが何かスゴいことができそうな予感.
- ねるWiki:ねる ぼくもadviceが欲しくなったのですこし工夫してみました。src testcode。:around, :before, :afterのサポートもしてますがsemanticsはよく考えてないので怪しげです。あと、adviceにワイルドカード指定ができるとうれしいですかねぇ、やはり。
- nakamura: semantics や仕様を固められれば module にできそうですね. 私は思いきり勘違いしてたんですが, Emacs の仕様だと before や after を囲む around が 設定できないのですね. advice 内で順序を入れ換えられると思っていたら, 入れ換えられるというのは before なら before の中, after なら after の中だけでということで, 一つでも before や after があればそれを囲う around の advice は作れない, と. これははたして利点なのか, 欠点なのか, ちょっとピンとこないのでわからないですが...
- ねるWiki:ねる AOPのようにadivce(とその他の情報; cutpoint?)に名前を付けて再利用させたいなぁと考えているところなので、仕様がかなり迷走しています.... なにか良いアイデア, 仕様等があればつっこんでください。ところで、Emacsのadviceの仕様は、そこまでやっちゃうとよく分からない振る舞いをすることが多くなるからとか、一貫性がうまくとれなくなるからそうなってるってところではないでしょうか。これ以上複雑になるとぼくには取り扱えなさそうです....
- document string
参考 Lisp:コメント. Emacs の docstring は apropos で検索できて便利だけど 説明文が単一の文字列なのが読みづらいので引数の説明とか箇条書にできないかとか試行中.
→ やっぱりやめようと思います. 引数の使い方までの説明はほとんどリファレンスと同じくらい 詳細な説明になるのでリファレンスと別々にメンテしたくないし, アルゴリズムがドキュメントに埋もれるのはちょっとイヤだなと思ったので. 漠然と考えてるのは, SXML の簡易的な書式でドキュメント片を別ファイルで記述しておき,- describe-function などで必要になったときに autoload して中身をもってくる
- SXLST みたいなので html に変換し, それをそのままリファレンスマニュアルにできるようにする ってなことができないかなあと. まあ texinfo を生で書きたくないだけなんですが(笑)
- undo どうしよ. Emacs のように直線的にするか, ツリー状に遷移を辿れるようにするか.
- shelarcy どっちのバージョンも残しておいて試してみたい時にツリー上を辿れると便利ですね。基本的にツリーを作成していくようにしておいて、ボタンやショートカット等で undo/redo ときだけ現在作業中の状態を元に線形に辿っていくようなのはどうでしょうか?
- nakamura(2004/04/24 09:53:07 PDT)切りかえが可能にしとくのはよさそうですね.
今ふと, Emacs 的な undo ってもしかしてツリーを外周に沿って時間的に逆に辿ることなのかな? と思いました. あ, でも「戻った」ということも記録するからそう単純ではないか... でも何となくツリーをまず実装しておく方がよさげですね.
- nakamura(2004/04/24 09:53:07 PDT)切りかえが可能にしとくのはよさそうですね.
- shelarcy どっちのバージョンも残しておいて試してみたい時にツリー上を辿れると便利ですね。基本的にツリーを作成していくようにしておいて、ボタンやショートカット等で undo/redo ときだけ現在作業中の状態を元に線形に辿っていくようなのはどうでしょうか?
- 省略可能引数について.
Gauche-devel-jp で過去log読んでたら,同様の話題が既に出ていたのですね. Alex さんの提案にかなり近い形になってます. let-optionals* を使うようにすれば 型情報が不要といえば不要なんですが, 見た目がけっこう見易いし, 型で assertion を入れるくらいは やってもいいかなと思ってるので, 型指定は残そうかなと思ってます. - 端末上での文字幅について.
カラム位置を知るために文字が画面上で占める幅について扱う必要があります. これも Shiro さんが一度 Gauche-devel-jp で言及されています. GTK の文字列は内部が UTF8 なので, unicode から文字幅を特定できればいいかなと思ったのですが, http://www.debian.or.jp/~kubota/unicode-symbols-width2.html こちらを参照するとまだ若干の問題はあるようです. ただまあ, ひとまず http://www.unicode.org/unicode/reports/tr11/ こちらにある EastAsianWidth.txt を元に, N,Na,H,A を1カラム, F,W を2カラムにする hash-table を作ってそれを利用しようかと思ってます. あんまりポータブルな方法じゃないかなあ.- やっぱりダメでした. 全角記号とかが全滅. kterm や w3m 系のプログラムは幅を扱うユーティリティを独自で持っているようですね. Fribidi のソースとかも参考になりそうな気が するのでもうすこし調べなければ... Ambiguous な幅は文脈依存だから, 結局は各言語ごとの管理が必要なのかもしれないです.
- buffer内の正規表現検索について.
文字列検索なら小分けにできるんですが, 正規表現だと以降のbuffer内容を全部文字列にしないと いけないような... rxmatch が文字列だけでなく手続きポートに対してもマッチできれば最高なんですが, regexp.c 見たらやっぱり最初に文字列の長さが必要なんですよね...うーん...
(2004/02/14 08:16:21 PST)
セミナーお疲れさまでした.
大変勉強になりました.
内容も勿論ですが生Shiroさん見れたので満足です(笑)
でも懇談会行きたかったな...
関係ない内容ですが, export についてちょっと質問させてください.
頭%以外を export ...
↑hira さんが Gauche:WishList に入れて下さったのでマチ.
- define-public方式で当面対処してみます.