なるということが起こってしまいます。ユーザからするとそこでなぜ最適化を抑制しなくちゃならないかってわかりずらいと思うし、埋め込んだ後で最適化をかけるならコンパイルされた最終状態じゃなくて途中のASTが得られる方が嬉しいですよね。:-)言われて見るとそうですね。ユーザにそこまで判断させるのは逆に煩雑な気がしてきました。書いていたら普通の文字列に紛れてしまったので)。仕様的にはデリミタがはっきりしているR6RSの方が良いと思うのでいずれ移行するつもりですが、既存の文法と両立できないので、なんらかのフラグを設けることになると思います。互換性の問題がありましたね。letrec*を提供してほしいです。現状のGaucheのletrecがletrec*の動作になっているので、名前を定義するだけでよいかと。現在のletrecは最適化がかかったときにletrec*の動作にならない場合があったような感じが頭の隅に引っかかってるんです。本当にそうなのかどうなのかはcompile.scmを読み直さないとならないんで保留になってます。モジュールをuseしているのに、エクスポートしている束縛を使っていないとき、それを指摘してくれる機能があるとよいです。gauche.testのtest-moduleが警告を出力してくれるとうれしいかも。...)がたくさんたまって来て、それをリファクタリングした時なんかに整理しやすい何かが欲しいと思っていました。ランタイムのチェックはオーバヘッドがあるので、テスト時のチェックが良さそうです。パッチをメーリングリストに送りました(アーカイブ)。展開してくれると、短く書けてよいかも。お、それは面白いかも。getaddrinfoに渡すhintsを<sys-addrinfo>を作らずに、キーワード引数で渡すことができるものがあると便利だと思うのですが、いかがでしょうか。protocol))))cgi-headerでの改行(Windows環境)Windows環境でwww.cgiを利用してcgiを使おうとすると、cgi-headerの出力が適正でなくて、正常なレスポンスが返ってきません。0aとして扱われるためのようです。\r\nを\x0d\x0aと書き換えても結果は同じだったので、出力の段階で何らかの変換をしてるのかと想像してます。0aになるのは自然だと思いますのでwww.cgi側で何か対策を取れないでしょうか?とりあえずは\r\nを\nだけに書き換えて対処してますが、もし明示的に改行コードを変えれる方法があるのなら適用してもらえれば助かります。変換がかかってしまうようです。(cygwinでは選べたような気もしますが)。modeにしちゃうと困る場合も出てきそうな気もします。define-cclassにcomparatorをgenstubのdefine-cclassでオブジェクトを比較する関数を指定できるようになるとうれしいです。double対応ができるので)。http-postが認証に対応してくれるといいですね。401を受けたら、自分で特にハンドルしなくてもAuthorizationヘッダつきのリクエストを再送信してほしいです。srfi)とかするとsrfi-*のモジュールを全部読み込んでくれるとうれしいです。並ぶので、このへんは何とかしたいところではあります。srfiにはGaucheの組み込み関数を置き換えるものもあるので、srfi-*で全部読んでしまうと危なくありませんかね。おっしゃるとおりformatなんかの挙動が勝手に変わってしまうと混乱の元になりかねないですね。私自身要望が整理できていないのでもともと思っていたことを書かせていただくと、ある機能を使いたいときに明示的にモジュールを読み込む必要があるのか、それとも組み込みで持っている機能なのかをマニュアルを読まずに判断するための基準がちょっと分かりにくいということを感じていました。srfi-*)と書かなくてはならないというのであればかえって分かりやすい(覚えなくてはならないのが明確であるため)のですが、現状ではsrfiの中でも一部の機能はコアに含まれていたりするので、ちょっと覚えにくいなと思っていました。リストや文字列といった基本的なオブジェクトを操作する関数については迷うことが多いです(removeとか)。その上でsrfiは文字でなく番号でつけられているため、とても覚えにくいなという印象が強くなります(これ自体はGaucheのせいではないんですけど)。ConnectNonblockingなconnect(2)をする方法があるとうれしいです。いまはソケットのfdをfcntlでノンブロックにすることはできて、socket-connectを呼ぶことまでできますが、nonblockingな場合はsocket-connectの呼び出しが失敗に終わるので、socket-statusが返すソケットの内部状態が、fdの状態を示したものになりません。I/Oはひととおり対応予定リストに入っていると思いますけど、一応要望です。)剰余付き累乗いくつかの数論的なアルゴリズムを実装するときに、剰余付き累乗が組込みで入っていると割と実用的な速度にできそうなのですが、標準で入らないでしょうか。今すぐ必要というわけでもないので気長に待つ感じで。私はそっち方面に明るくないのでコアにこれを持たせる必要性がよくわからないのですが、math.なんとか、みたいな拡張モジュールで持たせるぶんには構いません。その場合、これだけじゃなくて使いまわしのきく数論アルゴリズムパッケージ、みたいになってるといいですね。何かデザインして頂ければ本体にバンドルできるんじゃないかと思います。拡張モジュールでもいいと思いますが、できれば剰余付き累乗だけでも最初に乗っけてほしいです。DH法やRSAのような公開鍵暗号は、この関数一つあればSchemeで実装できてしまいますから、もし高速な実装ができれば実用上で意味があるのではないかと思います。以下に入れてそこから積上げてくってのがやりやすいかも。あれば簡潔に書けます。書くと非常に遅くなるんです。試してもらうのも手ですが、将来的にモジュールがあまり増え過ぎると目的の関数を探すのが大変になるので、覚えやすい単位でグループ化できるものはしときたい、という意図があります。arithmeticを実装する、というのはどうでしょう。今すぐでなくても将来色々とそのモジュールに追加してゆけそうな括りならば、とりあえず最初はpow-modだけを実装しておいて徐々に便利そうな関数を増やしてゆく、というのでいいです。助言頂ければありがたいです。:勉強中で助言というのもアレですが、整数論ではプリミティブは少なめで、応用がいっぱいという印象です。した方が良くないでしょうか。Writeソケットにwrite-blockしたとき、書き込めるだけのバイトを書き込んでブロックしない方法を提供してほしいです。selectとread-block、write-blockを使って、シングルスレッドのサーバで複数のクライアントを同時にサポートしようとしているのですが、ソケットを読まないクライアントがいるとサーバが書き込みでブロックしてしまいそうです。これは何とかしないとだめですね。ソケットをnonblockにするのはgauche.fcntlでできると思いますが、Gauche内部でwrite(2)がEAGAINを返した時の処理が難しい。Schemeレベルでのportへの書き込みからwrite(2)までにいくらでも任意のCレベルの処理が入る可能性があるので、EAGAINをSchemeレベルで捕捉したとしてもwrite(2)から再開する手段がありません。APIを全部トランポリンで書ければcall/ccで復帰できて綺麗なんですが、Cコードの方がえらく複雑になるので避けたいです。API内で捕まえてwrite-blockが特定の戻り値を返す、みたいな方法が現実的な線かもしれません。条件がかかるのが醜いですが...なるほど。port(バッファリングなし)という条件のときだけ、書き込んだバイト数を返すようにしてみました。EAGAINのときは0を返します。私にはこういう程度でいまのところ十分のようです。(srfi-68の進行も横目で見てないとならないんですが)。そこで対応を考えたいと思います。ありがとうございます。everyもほしいです。扱えると嬉しいと思いました。これはそう簡単ではないんですよ。開発の手間の問題で後回しになっています。ああ、では、書いてみます。export-all*export-allする際に、頭が%のものはexportしないようなexport-all*が欲しいです。prefixが設定できればなおいいのですが、%固定で充分だと思います。今作っているモジュールのpublic/private数が62/3なので大変なことになってまして・・・。nakamuraさんとこそのmoduleの先頭で以下のようなマクロを定義して、exportするものを明示的にこれでdefineすればいいんじゃないでしょうか。当面はアドホックに対応して頂けますか。(モジュールは「閉じて」いないため、いつでも新たなシンボルが追加され得ます)define-public方式はだいたいうまく動くんですが、define-class等別のマクロと両立しないんですね。いうのだけ明示的にexportを書くってので運用上はなんとかならなくはないんですが、システム標準にするのにはまだ抵抗があるって感じです。アドホックなやつ置いておきますね。命名規則とスコープが結びついてるのはラクちんで良い感じです。文字列を持っている変数を渡せたらうれしいです。ロードパスはコンパイル時に決定していて欲しいので、add-load-pathはマクロにしてリテラル文字列しか受け付けないようにしています。add-load-path内で変数を評価するようにしてしまうと、例えば次のフォームはうまく動きません。my-path))beginフォーム全体がまずコンパイルされ、その後評価時に"foobar"が評価されmy-pathへと束縛されますが、add-load-pathそのものはコンパイル時に処理されなければならないためです。コンパイル時に値が確定出来る式をadd-load-pathが取ることを許す、という変更は可能ですね。マクロの束縛はコンパイル時に確定しているので(でないとマクロ展開が出来ない)、こんなふうに書けるようにはできるかもしれません。(my-path))ちょっと考えてみます。現在の仕様でロードパスを実行時に変更するのは、変数*load-path*を直接変更することで可能です。&quot;foobar&quot;)マニュアルでは*load-path*を直接いじるのは非推奨としていますが、それは上記のような評価のタイミングによる混乱を避けるためで、分かって使うぶんには問題ありません。ご丁寧な解説ありがとうございます。使わない方向で検討したら却ってしっくりくるものに仕上がりました。アプリケーションバンドルにして遊んでいたのでした。