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

まだよく知らべてないんだけど、カリー化したことで可変長引数は犠牲になったろうな。こればっかりはしゃあない。

マクロを使えば一応まねごとが可能なことは ACL2 のやり方をみたんで知ってる。

Typed Racket の前例があるんで、マクロで型付きLispは実現可能だってことは知ってたんだけど、まさか Common Lisp でも Coalton というこんな本格的な型システムが実装されてしまうなんて。

Common Lisp は asdf 周りとか defsystem 周りでよく分かっていないところがあるんで本格的に使うならそこら辺を勉強しないとな。

型クラスでなんかやりたいけど、動的型付きプログラミングに慣れすぎてしまってすぐには何も思いつけない。

もちろん、実行時ではなくてコンパイル時に……。

ちゃんと宣言した型と違うのを返そうとすると型エラーになるな。素晴しすぎて泣けてくる。

ただどういうときに末尾再帰してくれるかは処理系によって違うんで理想的には Coalton 側が末尾再帰形式を変換してくれた方が良い感じする。

しかし、そもそもカリー化されてるためにいっぱい呼び出しを実行しちゃう問題も処理系の最適化に任せる雰囲気っぽいんであんまり期待できないかもしれない。https://github.com/coalton-lang/coalton/blob/b36c38226dcd2a6da3b3146125930eb179baa583/docs/design-docs/function-calls.md

Coalton が末尾再帰の形式にしてくれない件は sbcl であれば (optimize (speed 3) (safety 0)) を指定することで回避できた。

Coatlon 使ってれば型安全なんだし、safety とか要らんくね。

Optimize 設定しようぜみたいな話は書いてあるな。https://github.com/coalton-lang/coalton/blob/b36c38226dcd2a6da3b3146125930eb179baa583/docs/design-docs/function-calls.md

理屈の上ではできそうなんで移植性のことを考えると、末尾再帰の最適化は Coalton 側が請け負った方が良い気がするな。

とりあえず、sbcl でどうしたら回避できるか確認するか。

スペシャル変数とフック以外のケースで末尾呼び出しが最適化された場合に関数の挙動が変わってしまうケースを知らない。

ただ理屈の上では coalton 側で末尾再帰の最適化程度は可能なはず。Common Lisp で末尾再帰の最適化ができないのは主にスペシャル変数とフックのせいだし(個人的な認識です)。

optimizeが指定できればいいんだけど。

あ、coalton 側で tail recursion の最適化はしてくれないっぽいな。普通に SB-KERNEL::CONTROL-STACK-EXHAUSTED って言われてしまった。下の関数に (neko 100000) って入れただけなのに。これは回避法の模索が要るな。Coalton が関数型言語である以上、処理系に依存してでも末尾再帰は最適化されて欲しいところがある。

とりあえず tail recursion の最適化がなされるのかどうか確認するか。coalton がやってくれるならそうとう嬉しいんだけど……。

おおお、ちゃんと Coalton 動くー！すごい。Common Lisp で静的型付きプログラミングできるし型クラスまであるぞ！

おお、coalton 動いた！これで Haskell 的な型システムでプログラミングして Common Lisp から使えるじゃん！これはやばい。

いや、define のスペルをミスったアホなだけだった。

とりあえず、factorial を定義して動いたら満足したい。