Timeline for it list by senooken, page 67

じゃあ、Common Lisp でちゃんと check-type とか assert を書けばいいじゃんって話になるな。

戻り値の検査はいいから入力の検査を徹底すればいいような気もする。

あー、でもこれ Scheme で安易に実装すると tail call じゃならなくなるのか。

やっぱ静的型ないなら契約はいる気がするわ。どこで生まれたのかよく分からん nil を探すの嫌だし。

そんで、スピード重視するときにはなんかコンパイル時の変数で挙動を制御できるような感じにしておけばよくね。

そんな大袈裟なことしなくても Common Lisp なら check-type とか assert を勝手に挿入する関数定義のマクロを書いちゃえばいい気がするな。

Common Lisp に契約プログラミングを導入するやつあるじゃん。これ全部 CLOS になるんか。それはそれでちょっとやだな。

GitHub - sellout/quid-pro-quo: A contract programming library for Common Lisp in the style of Eiffel’s Design by Contract ™.https://github.com/sellout/quid-pro-quo

Contract があればだいぶ軽減されるよな。やっぱ Racket はよくできてる。

どこから `\#f` もしくは `nil` が発生したのかを追跡できるのが重要だ。

Racket の Slack で質問しちゃってなんか微妙な感じになっちゃったし。誰もこのことについて考えてないわけがないと思って聞いてみたんだけど勇み足だったかな……。

それを必要とする状況ってなんかプログラム壊れてるでしょって思う。

しかし car に (-> (Listof a) a) とかいうやばめな型をつけてて (-> (Pairof a b) a) だけじゃないのが Typed Racket の選択であったところはなんか自分の求めてるものとTyped Racket 陣営の求めているものに若干の差を感じるんだよな。

結構考えたんだけど null? かどうかの (-> (Listof a) a) の型やっぱ要らないんだよな。

やっぱ Typed Racket は丁度いいんだよな。だってちゃんと Lisp に型を付けてみました感あるし。

Coalton があんまり求めてるものじゃなかったんだよな。あれは正格評価する Haskell であって Common Lisp じゃなかった。

Common Lisp で関数を使う前に必ず describe 関数で挙動を確認する人生を送ればいいのだろうか。

たとえば string->number が失敗したときに `#f` になるの、型がないと隠れし `#f` になりがちなんだよな。

Scheme を書いているときの、なぞの `#f` の襲来が避けられることは大切な気がする。

動的型の Scheme なら `#f` Comon Lisp なら `nil` の唐突な襲来を回避せんといけないからな……。

まあ SICP の後半の苦しみは型を書いていればほぼなかったのではないかという記憶は消えていないけど。。。

昨日のよるこれを読んでしまったせいで、「本当に私に型いるんか？」という問いを生じてまった。まあ仕事なら要る一択なんだけど、趣味で書くなら要らないような気がしてきて心が Typed Racket から離れそう。

本のまえがき | 本の購入サイトhttp://ontolonomy.co.jp/books/preface/

プログラミングの基礎のサポートページの東京メトロ線の情報って古いんだな。これ一人でやってたら絶対気づかなかったやつだ。

なんか Either モナド的なの使いたくなる問題だな……。