Notices by きゅーけー (tojoqk@mastodon.tojo.tokyo), page 86

そうか……。そういう見方もあるよな。2020年6月17日の朝になんとなく構築したサーバーが今まで生きていてまだ使われているとは、あの日の朝は思わなかっただろうな。

337 はなんか急にでかいな。

ゆくとしくるとしを見ている途中に「以外」は他の「以X」系と違ってイレギュラーなことに気づいた。以の外だから良いのかと納得したけど。

般若心経きたら聞き取れる自信があったんで待機してたんだけど、分からなかった。流れなかったのか気づかなかったのかすら分からない……。

やっぱゆく年くる年で浄土真宗系の寺はでてこない印象ある。だいたいなんか願ってるからな。やっぱ願う方がスタンダードだしな。というか1/1を何か特別視すること自体がなんか違うんかな。寺が取材を拒否するんだろうか……。

あけおめ

Coalton 側で使えるマクロは Common Lisp 側で定義できるはず。既に `make-list` というマクロを見つけている。

可変長引数の関数が書けないならマクロを書けばいいのである。ACL2 でも Coalton でもこれは同じだった。

気になってた問題についてはだいぶ解決してきたんで Coalton で色々できそう。Coalton は Lisp の一種としてみるよりかは Common Lisp の中に実装された S式 で表現された Lisp 風のシンタックスを持つ ML 系の関数型言語としてみるのが良さそうだ。Coalton 上では S式のような複雑な式を構成する cons セルがないため、マクロを書く能力はなさそう。よって Coalton 自体は自己言及を特徴とする Lisp の性質を持ってない。ただ、Coalton で書いた関数は Common Lisp からシームレスに使える(逆も)ってことが重要であり、これができるのは本当に素晴しい。ともかく型クラスを使って抽象度の高い関数を作れると思うとテンションが上がる。

そんなに最新のバージョンを使うモチベなくなったんで Guix に登録されてるバージョンに戻そ。

(coalton False) は nil なんで、リストの相互変換が不要になるはずがなかった。

完全に勘違いしてた、最新のバージョンにしても相互変換が必要なことに変わりはなかった。

Coalton のリストを Common Lisp にするときは coalton-to-cl-list で逆は cl-list-to-coalton で変換する。

いや、減る分には何も起きないんで問題ないか。

バージョンが上がって依存ライブラリが増えたり減ったりしてると面倒なんだけど……。

あー、Guix 以外の方法で最新に追従するの面倒なので、Guix のパッケージ定義を久し振りに書くか。継承して名前を変えてバージョンをちょろっと変更するだけなんで楽勝なはず。

マスターじゃなくてメインだった。

完全に解決した。今私が使っているバージョンは Coalton の List が Common Lisp の List に置き換わる二日前のバージョンを使ってるからこういうことが起きてる(今はそもそも相互変換をする必要がない)。これ最新のマスターに追従した方がいいな。

お、ここの example のあたり、defsystem の書き方の勉強になっていいな。https://github.com/coalton-lang/coalton/blob/main/examples/small-coalton-programs/small-coalton-programs.asd

うー、Coalton の List と Common Lisp の cons からなる List を相互変換するやつ絶対いるだろうから確実にあると思うんだけど驚くべきことに見つけられない。どこに書いてあるんだ……。

どうやって、Coalton の List を Common Lisp の List に変換するのか分からなくて詰んでる。これ自分で書ける気もするんだけどたぶん用意されてるだろうから見つけたい。

`cons` の型を確認したところ、どうやら Lisp の `cons` ではないことが分かった。まあ、こればっかりはしょうがないな……。Lisp のただの対としての cons は静的型付きだと結構無理あるし。

Typed Racket は無理を通していて、`cons` は Racket の `cons` のままなんだけど。