[Gauche] shiro: >kaki dangling pointerのは気づいてたんですが実害がないので放置してました。

[Gauche] kaki: ;; test-module が存在しないdangling autoloadを検知しています？phantomなglocがいますね。
gosh> (define-module foo (export dummy))
gosh> (use gauche.test)
gosh> (begin (test-module 'foo :allow-undefined '(dummy)) (values))
testing bindings in #<module foo> ... ERROR: symbols exported but not def ...

[Gauche] kaki: なるほど。

[Gauche] g000001: Smalltalkのメタクラスはクラスの属性というか背後のメカニズムという感じなので、共通の性質みたいなものは求めやすいかと思いますが、Common Lisp系だとクラスのクラスで別のオブジェクトシステムであってもよいという自由度なのでなんでもありという雰囲気ですね。80年代あたりは、安全なメタクラス合成などの研究はあったようですが https://dl.acm.org/doi/abs/10.1145/74878.74909

[Gauche] g000001: Common LispのMOPのデファクト(AMOP)ではvalidate-superclassで明示するのが正しくて、他の処理系はよく使われるパターンがvalidate-superclassで定義済みという感じですね。 https://web.archive.org/web/20210322074042/https://g000001.cddddr.org/3825366463 > SBCL

[Gauche] kaki: ところで、ドキュメントの scheme.ilist の所、"従って、このモジュールが提供する手続きは単に変更可能ペア用バージョンの別名になっています。" とありますが、ipairを生成する多数の手続きに言及・項目がありません。

[Gauche] kaki: メタクラスとメタクラスの関係が満たすべき性質とか、満たしてると嬉しい性質とかみたいなことに対して直感があまり働かないんですよね。

[Gauche] kaki: メタクラス、TwitterとChatGPTでちょっと聞いた噂では、SBCLは全部 validate-superclass で明示しないといけなくて、他の処理系はまた違うとかなんとか。

[COMMON LISP JP] 新着Lisp記事: Viivi 00.40.00 (alpha) 版を公開しました (2026/02/25) https://www.viivi.io/japanese/logs/release.00.40.00.html

[Gauche] shiro: array-for-each-indexのインデックスオブジェクト: 確かに。

[Gauche] shiro: 何も指定しない時に親のメタクラスを見て自動生成するのはCLOSにはなくて、stklosのを真似したんだったかな。CLOSだと何も指定しないとstandard-classになっちゃってそれに躓いたことがあるので。

[Gauche] shiro: メタクラス: これ確かCLOSでも特に制約はなくて、明示すれば親クラスのメタクラスと全然無関係なメタクラスを子クラスで指定できます。それで困ることが起きてもプログラマがわかってやってるってことで。(SBCLはなんかチェックが入るみたいですが)

[Gauche] shiro: >kaki リリースノート、リニューアルに伴いマークアップ方式を変えたのを半自動で変換したんだけどその変換ミスでした

[Gauche] kaki: gosh> (use gauche.array)
gosh> (time (rlet1 n 0 (array-for-each-index (make-array (shape 0 1000 0 10000)) (^ (i j) (inc! n (+ i j))))))
;(time (rlet1 n 0 (array-for-each-index (make-array (shape 0 1000 0 1000 ...
; real 2.270
; user 2.210
; sys 0.050
54990000000
...

[Gauche] kaki: 話は変わって、array-for-each-index のドキュメントに "インデックスオブジェクトを…渡すことで、 より良い性能を引き出すことができます" ってあるんですけど、arrayのrankが低いうちは最適化されててインデックスオブジェクト渡さない形式の方が速そうで気になりました。

[Gauche] kaki: (define-class <a-super-meta> (<class>)
())

(define-class <a-sub-meta> (<class>)
())

(define-class <a-super> ()
()
:metaclass <a-super-meta>)

(define-class <a-sub> (<a-super>)
()
:metaclass <a-sub-meta>)

;; <a-super-meta> と <a-sub-meta> は他人だけどいいのか？

[Gauche] kaki: メタクラスと親クラスのメタクラスの互換性って特にチェックされないっぽいですけど、継承関係は無くてもいいんですか？自動にすると全部のメタクラスを継承したメタクラスが生成されますよね。

[Gauche] kaki: 過去のニュース http://practical-scheme.net/gauche/oldnews-j.html のGauche 0.9.14リリースノートへのリンクが間違っているようです。 s/リリース%25 0.9.14/リリース 0.9.14/

[Chaton] shiro: test

[Gauche] hamayama: Gauche-package-repository-index のリンクが切れていますか?

[Gauche] shiro: 「手続きをショートカット手続きに変える」手続きがあれば良い気もしてきた。
(?$ proc) == (^x (and x (proc x))
(?$ proc arg) == (and arg (proc arg))

[Gauche] shiro: (2)ショートカットはあっても良いですが、ありと無しを混ぜるのはぱっと見わかりづらそう。and-let* やchain-andのように、ショートカットやるなら全部、混ぜたければカッコ使って、ってのでも良いように思います。　

[Gauche] shiro: (1)arityについては、なるべくそういうメタな情報を実行時にも保存してゆく方向で考えてます。Schemeの慣習として不定長引数で受けてapplyする、というのが書かれることは防げないので、あくまで出来る範囲で、ってことですが。静的にやるのはSchemeでは難しいですね。

[Gauche] kaki: 別に用意するなら (?$ h $ g $? f x) とか？暗号めいてきた気がしないでもないですが。$? が $? なのは $* に揃えてます。先頭の ?$ は、$? だと述語っぽくなっちゃうので。

[Gauche] kaki: このような複雑さを、現状のシンプルな $ に持ち込んでよいものか。

[Gauche] kaki: $? があると #f が来た時に$式全体が短絡すればいいと考えていましたが、この挙動だと途中までの短絡をしたい場合に ($ h ($ g $? f x)) みたいにネストする必要が出てきますね(折角のネストキラー(?)なのに)。逆に直近だけ短絡するなら、全部短絡したい場合は ($ h $? g $? f x) と書かせるか。

[Gauche] kaki: (話がとっ散らかってしまいますが)…というのを、(g (f x)) で (f x) が #f のときに短絡するやつが欲しいなあと思って、composeの#f短絡版があればいいかなと考えていたときに思いました。srfi.197の chain-and はちょっとだるい気がしまして。で、考えていたら思い付いたのが、$ を拡張して ($ g $? f x) で短絡できるようにするといいんじゃないかと。JSの ?. やRubyの &. からの着想です。

[Gauche] kaki: コンパイラがstaticにカタをつけられる方向で頑張るべきか…？

[Gauche] kaki: case-lambda とか適用可能オブジェクトとかあるから思ったより面倒かな、arity的な情報を保存する compose

[Gauche] kaki: シグネチャを取り出せればそれを eval すれば良さそうなんですが、<procedure> の info スロットがどのような値を取り得るかって特に保証はないですよね。