"PL"

2025-01-13

昨日は友達とキリンビール工場に行ってきた。500円のツアーがあってビール作りの概要を教えてもらいつつビールを飲ませてもらえる。だいぶ楽しかった。あの体験は優しさで成立していると思う。

原料となる麦やホップを食べさせてもらえたほか、ビール製造の中間生成物である麦汁の飲み比べをさせてもらえた。何より説明してくれるお姉さんがビール好きで、1つ質問すると厳選した3つを返してくれるのが良かった。一緒に飲んで欲しい。飲ませてもらったビールもめちゃくちゃおいしいし。併設されているレストランに行けていない（リサーチ不足でご飯を食べてから行ってしまった）のと、他にも見学コースがあるみたいなのでまた行きたい。

ホップを使ったリンスを買って使ってみたら、髪からフルーティ系なビールの匂いがして最高。

AIに仕事を奪われることはないだろう。とはいえ単に作業をするだけの労働はAIに奪われる。コードを単に書くのは作業であって、仕様からコードを生み出すだけならAIでやった方が早いし（今の相場なら）安いから。

とはいえそんな単純作業が仕事であることはなくて、将来のこととか仕様の考慮に入っていなかったことをコードを書きながら調整して主体として責任を持って成果を出すことは、社会がまだAIに対して認めていないように感じる。

誰もが優秀な部下を持つようになったが、人々は誰かに責任を持った主張をして欲しくいのだろう。ポジションをとって主張をし、ダメだったときは失落したり挽回することを人格に求めている。信頼をして仕事を任せる相手は人間じゃないと嫌だと社会が思っている。

そういうわけで人間は労働力としての生成AIを手に入れただけであって、人間社会で主体として認められたあらたな人格を手に入れたわけではない（今のところは）。成果を出すためには社会が理解できるポジションを取ることが必要で、そのロールモデルの振る舞いとして社会と交流しないといけない。どんな振る舞いをするのが良いか決めるために生成AIを駆使する仕事の仕方が増えるだろう。ロールモデルには矛盾なくとりうるアトミックな行動があって（思想とか哲学みたいなもの）、それを組み合わせることでその人らしい振る舞いが形成される。思想とか哲学とかに一貫性がないと社会から信頼してもらえない。一方で外部から同じ要求がなん度もくることはないため、それに応じた異なる振る舞いをする必要はある。思想や哲学から外部刺激に対して振る舞うことにはエネルギーとか思考とかが必要で面倒だから生成AIを使うと便利だろう。

これはプログラミングにも応用できる。アプリケーションのコアなロジックのインターフェースは綺麗に設計されてクライアントから受け入れてもらう必要がある。そこがブレると利用するのがそもそも大変だし、見出した価値がすぐに失われてしまうだろう。一方で、それを活用して振る舞いを追加したり修正することは生成AIがこなすだけで十分なのではないだろうか。振る舞いを追加することは、そのアプリケーションのコアな部分のインターフェースと世の中によく知られた技術要素のインターフェースを組み合わせて表現できるだろう。

外部からの要求に応答して振る舞いをしたりインターフェースを利用して新たな機能を提供する際に、コアな思想を見直してアップデートすることもあるだろう。とっているポジションをちょっと変えるということ。使う側からすると理解の仕方をちょっと変えないといけないのでこの変更が気に食わなかったり理解できなかったりすると嫌な感じがする。変化の速度が早すぎて理解が追いつかないとたとえ良い変化であったとしてもアンチになってしまい信頼をなくすことに繋がる。そのため人間に直接理解されるインターフェースは人間に合わせた進化をしないと社会に適合できなず、市民権を失う。

したがって生成AIはインターフェースを提供するソフトウェアエンジニアの職業を奪うことはない。一方でインターフェース設計に関与しない、定義されたインターフェースの中だけで作業をして、他人と相互作用をするインターフェースを定義しないエンジニアリングは生成AIのコストに負けて自動化されるだろう。

次に、他人と相互作用するインターフェースのあり方が変化するかが問題になる。これまで公開されて使われていたようなインターフェースは今後も必要だろうか。インターフェースを解釈するのが生成AIだけになれば、その変化が早くても理解が追いつくためわざわざポジションをとったり人間の理解速度に変化の速度に合わせる必要がなくなる。これは作り上げるものの抽象度の違いに依存するだろう。何かを作り上げたかったらその一段下の抽象度の言葉で構成を説明してほしい。妥当性を検証するために。そこから下は信じることにして（信じられる何らかの根拠を持つことになる、ここも何か困難があるかも、今は著名なOSSだからokとか言って信用することにしている）、欲しいものの一段下のレイヤで自分で納得がいけば良いものであると判断する。

そして、人間の思考とか議論のレイヤは高々10とかにおさまっており、それが生成AIの登場で変わるとも思わない。なのでインターフェースを人間が作ってポジションをとる必要性も今後変わらないと思う。根拠はなくて直感だし、多分僕の願望も入っっている。

良いインターフェースを定めるために、鍛錬を積む必要はあり、それは生成AIによって取って代わられる仕事でなされることが多い。生成AIを使って仕事をやる先端のインターフェース提供者と、そこから学べない後進が場所によっては生成AIがやる仕事をするローカライズされたインターフェースの提供者が並行して存在する世界になるだろう（生成AIに限らずこの状況はあるだろうが）。

漏れなくスタックトレースをGoで取りたい！

k1LoW/errors でスタックトレースをエラーにつけられるようになる。便利なのだがトレースをプログラマが明示的に指示しないといけない。設定をコードベースで一回やれば終わりではなく、エラーの発生源で書かないといけない点が気になっている。書くこと自体は許容しているが、漏れがないように人間が頑張るのは許容したくない。漏れをなくすための仕組みを主張する。

ライブラリとして使うためにはreadmeの説明で十分だと思うが、議論のためにここでも説明する。以下のように用いる。

https://go.dev/play/p/Cwp4n-vZONv

package main

import (
	"encoding/json"

	"github.com/k1LoW/errors"
)

func f() error {
	// このようにWithStackを呼び出した箇所でのスタックトレースがerrorオブジェクトに記録される
	return errors.WithStack(errors.New("ouch!")) // ここは11行目
}

func main() {
	err := f()
	// スタックトレースを含んだエラー内容をフォーマットする
	s := errors.StackTraces(err)
	b, _ := json.Marshal(s)
	println(string(b))
}

実行すると以下のような出力が得られる。見やすさのために jq にかませてフォーマットした。

[
  {
    "error": "ouch!",
    "frames": [
      {
        "name": "main.f",
        "file": "/tmp/sandbox123757503/prog.go",
        "line": 11
      },
      {
        "name": "main.main",
        "file": "/tmp/sandbox123757503/prog.go",
        "line": 15
      },
      {
        "name": "runtime.main",
        "file": "/usr/local/go-faketime/src/runtime/proc.go",
        "line": 272
      },
      {
        "name": "runtime.goexit",
        "file": "/usr/local/go-faketime/src/runtime/asm_amd64.s",
        "line": 1700
      }
    ]
  }
]

スタックトレースの先頭 (frames配列の先頭要素) はWithStackを呼び出した位置を指す。

したがって、アプリケーションの中でのエラーの発生源をスタックトレースから漏れなく特定するためには、エラーの発生源の全てでWithStackを呼び出す必要がある。

なお、WithStackを重ねて呼び出しても問題ようになっている（深いスタックトレースを持つものが生き残るようになっているし、他のも気遣いがされている）。

名前付き返り値とdeferを使って忘れないようにする手法も紹介されている。

func f() (err error) {
	defer (func(){
		err = errors.WithStack(err)
	})()
	b := strings.Builder{}
	_, err := b.Write([]byte("hello"))
	if err != nil {
		return err
	}
	// ...
}

ある程度楽をできるし、この後の議論をした上でもバランスの良い選択肢だと思うが課題も感じている。その課題と解決案を以降で議論する。

  1. deferを書くのを忘れそう
    • こちらはリンターでなんとかなるだろう。ここでは深く議論しない
  2. deferの中でerrors.WithStackを呼ぶと、エラーの発生源から離れるため、具体的にどのreturn errで落ちたかがスタックトレースから追えない
    • エラーメッセージから判断できる可能性は大きいけど

二つ目の課題の例を以下に挙げる。fではどの行で落ちたか分からないが、gではどちらのwithStackで生成したかが残る。

func f() (err error) {
	defer (func() {
		err = errors.WithStack(err)
	})()
	if err := ok(); err != nil {
		return err
	}
	if err := ng(); err != nil {
		return err
	}
	return nil
}

func g() (err error) {
	if err := ok(); err != nil {
		return errors.WithStack(err)
	}
	if err := ng(); err != nil {
		return errors.WithStack(err)
	}
	return nil
}

func ok() error { return nil }
func ng() error { return errA }
var errA = errors.New("this is error")

https://go.dev/play/p/SGr1B4sDF9I で動かせる。

k1low/errorsでは、errors.WithStackはfunc(error) error 型を持つ。それを func(error) errors.T とする。ここでTは以下のようなerrorをStackTraceメソッドで拡張したようなインターフェース。

package errors

type T interface {
	error
	StackTraces() stackTraces // 戻り値型には議論の余地があるが、ここでは重要ではない。
}

// 唯一のT型のコンストラクタ
func WithStack(err error) T { ... }

スタックトレースを取りたいアプリケーションでは、すべての関数定義で返すエラー型を標準の errorではなく errors.Tとする。そうすると、すべてのreturnされるエラーオブジェクトからスタックトレースを取得できることが保証される。

以下の二点が嬉しい。

  1. errors.Tを返す関数しか呼ばない関数は繰り返しerrors.WithStackを呼ぶ必要がなくなる
  2. errors.WithStackをエラーが発生するたびに (deferの中ではない！) 呼び出すように保証できるので、スタックトレースがちゃんと深くなる

この方法の問題は以下。人によっては許容できるだろう（ぼくはありだと思っている）。

  1. すべての関数定義で返すエラー型をerrors.Tに統一する方法が定まっていないこと
  2. errors.WithStackをたくさん呼ばないといけないこと
  3. 独自のエラーインターフェースを定義していて気持ち悪いこと

一つ目はリンターを書けば良い。error型を返す関数を定義したら怒るだけなので簡単。deferでちゃんと書くことを保証するよりも難易度は低いはず。

二つ目は諦めるしかない。生成AIに頑張ってもらいたい。手書きするのは嫌だけど、補完があるならギリギリ許容できる気持ちがある。

三つは対処を思いつかない。これも諦めて受け入れるしかないだろう。標準のエラーとは別物として扱おうとしているのだから型は真っ当に手法を表現している。解決手法がGoぽくないのだろう。

  • deferを使う手法ではスタックトレースがちょっと足りない
    • とはいえエラーメッセージが適切に設定されていれば問題ではない
    • 込み入ったこともしないでいいし簡単
  • とはいえ設定もれが怖い気持ちや、スタックトレースをもう一段深く取りたい気持ちもある
    • そのときは今回提案した型で頑張る手法をとれば良いと思う

2025-01-04

過去に何個か一人でCLIツールを作ったことがある。そのときに雰囲気で乗り越えてしまいストレスの少ない綺麗な書き方を知りたかった概念をあげる。

  • エラーハンドリング
  • 参照周りの型変換
    • 特にパターンマッチやforループ、関数定義で & 記号を書く構文特有の意味があるときがよくわからない
  • ライフタイム
    • 実用的に我々はどんな塩梅で書くのが良いかとか、誰が所有するのが良いかを判断するためのベストプラクティスを持っていない
  • トレイトの勘所
    • ユーザ定義型に機能を実装するときに、どういうインターフェースを持たせるか迷う。どのようなトレイトを実装するかを決められない。クライアントとしての標準を知らないのでサーバとして何を提供するか、常識をもとに判断できない

要件を定めてそれを保証する仕事がソフトウェアエンジニアの仕事になるだろう。それだと単発の仕事か。進み方を把握して、それを促進する作りにする必要はあるはず。

プログラムの開発（状態や環境に反応するソフトウェアの開発）自体は生成AIによって簡単になった。要求や要件を実現することしかまだ生成AIのブラックボックスに入れられていない。要求や要件の整理の道具として生成AIを利用してはいるが、

これからは生成したプログラムに対して保証された機能の制限が大事になってくるだろう。プロダクション環境で動くプログラムを見る人間は減り、その代わりにソフトウェア検証、パーミッションの制限で安全性を保証したり、デモで振る舞いを確認する未来がくるだろう。ソフトウェアを実装するコストが低くなり、つまりソースコードに向き合う機会が減り、コードの振る舞いを静的に理解しなくなっていく。あるいは言語を高級にするだろうか。言語にどんな性質があると幸せ？

生成して良い言語に良い性質を持たせることはありそうなアプローチ。

仕事は確かにたくさん奪われそうだけど、契約をデザインして（うまくそれを表現することを含む！）プログラムを作り上げる営みは楽しいからずっと続けると思う。

2025-01-03

https://dev.nfurudono.com/posts/go-errors-stacktrace に移転しました。

大掃除は年末にしたのだけど、コーヒーグラインダーを掃除し忘れていたのでやった。結構な量の粉が中から出てきて驚いた。豆を砕く場所と粉が出てくる穴の間に傾斜した通路があってそこに溜まっていた。

今日も餃子を作った。昨日たねを作りすぎたので。ちょうど買い足した餃子の皮を消費できた。蒸しと焼きの両方やって昨日と同じ感想だった。たねを作るときに白菜の水分を抜く工程を入れていたが次回は外してみようと思う。

明日は鮭のホイル焼きをしようと思う。衛宮さんちの今日のご飯に感化された。

  • 鮭・玉ねぎ・にんじん・しめじを適切に処理する
    • 鮭には酒と塩を振って5-10min放置してから拭き取る
    • その後酒に塩胡椒を振る
  • 玉ねぎ・にんじんを敷いて、その上にコンソメをかける
  • 全てを載せつつバターも添えてホイルに包む
  • 加熱する
  • パセリか何かをかけるらしい
  • わさびマヨがあっても良いとか

朝は納豆とかかな。卵も食べよう。 朝はサンドウィッチにする。ほうれん草、卵、ベーコンを入れたい。卵しかないので買い出しが必要。パンもない。

2024-12-25

関数の引数はそれぞれ何で、どんな性質を期待するかや、そのほかの事前条件を満たした上でこの関数を呼び出すと、その結果としてどんな返り値が得られてそれ以外にどんな副作用があるかを表明するのが関数の契約。文章を用いるのが簡単だし、伝えやすくするには図を用いても良いし、型とかバリデーションのための式で表現しても良い。何にしても契約を表明すると楽しくプログラミングできる。

この関数の呼び出し側はどんなふうにこの関数を使って処理を実現するだろうかとか、この関数を実装するときはどんなふうに作ろうかと考えるのがまず楽しい。みんなが幸せになれる契約をデザインするのが楽しい。ソフトウェアのテストは契約を守っていることを検証することだと思う。型を用いた表現は契約の表明で、型検査が検証（それも厳密な）である。

このように良い契約をデザインするのがプログラミングでまずやることだと思う。その次に自動で検証するためのコードを書くのがTDDの人だし、関数型の怖い人は型で契約を表現しようとするかもしれない。そのためにすごい表現力を持つ型システムを考えて勉強して使う印象がある。

TDDで最初から完成版のテストを書かないことからわかるように、契約を最初から詳細まで書く必要はない。そんな契約を満たす実装を書けるだろうかと思うこともある。なので最初はふんわり「ユーザの情報を返すAPI」とか決めておいて、IDが欲しいとか、シャーディングしてるから作成日時も欲しい、みたいな事前要件を足したり、ユーザ情報全部返すのはきついし呼び出しがわも幸せじゃないから、名前とメルアドだけ返すことにする、みたいな調整も入るだろう。課金が滞っているユーザに対しては普通の結果は返さない、代わりにエラーを返す、みたいな変更も実装したり呼び出しているうちにしたくなるはず。

結局のところ普通のプログラミングをしようと言っているだけなのだが、僕が強調したいのは契約と実装を分けて考えようということ。契約が先にあってそれに実装を合わせる（合ってない状態はバグってる状態）考え方でいたいし、僕と契約を共有する人には（その共有する契約のレイヤで）いて欲しいと思う。

僕はmac osのコードがどうなっているかを気にすることはなくて、普通にパソコンが動けば満足するし、実際動いているので不満はない。キーボード叩いたら文字が出るという契約を守ってくれている。でもosのapiを叩く友達はそもそもドキュメントが公開されてなくて辛い、みたいなことを言っていた。このように、自分が関心のあるレイヤの契約が問題になるのだと思う。

契約はプログラミングの細かいレベルだと変数の名前とか、改行の置き方によって表明されるもので、大きいレベルだとサービスやロールの責務として表現されると思う。サービスのAPIは代表的な契約だと思う。APIという言葉は契約と同じような意味だと思うけど、エンドポイントみたいな意味でも使われているし責務みたいな概念には適用されないと思っていて使わない。

僕たちが欲しいものは何かを表明しよう、というのが契約を表明しようということだと言い換えられる。使う側からしたらその実現方法は関係ないし、提供する側からしたら契約さえ満たせば何をやっても良い。 getterとsetterを提供するからと言ってそういうフィールドをよく知られた方法で提供しないといけないわけではないし、バッファリングとか遅延実行をしても良い。

未定義な状況とか意図しない状況はある。今と昔では状況が変わって、その頃は妥当に思えた契約が時代に合わなくなることもある。契約がないと実装が良くないで話が終わってしまうが、契約があれば仮定が違ったのだと結論づけられる。人の記憶があればその人の心に契約があって仮定が違ったと判断できるだろう。記憶を失ったりその人が失われたりする場合は契約を表明しておくべきだろう。

型はデータ構造やその不変条件を表現したりそれらに名前をつけることで、契約を表現する。そして型を用いて表明された契約は普通型検査によって契約が満たされていることを検証する。正しい場合には正しいと判定するし、正しくない場合には正しくないと判定する。さらに、ある程度ちゃんとした型検査器は、どのように契約が満たされなかったかを説明してくれる。

テストは契約を検証するためのコードで、そのテストが契約のどんな部分を検証するか、テストケースの名前として表明される。その表明を満たすようにテストコードが実装されて、テストランナーに呼ばれる。契約のどんな側面をそれぞれのテストケースで検証するか、検証すると幸せか（誰にとって？）を決めるのはテスト実装者のスキルに依存するだろう。契約の中で脆いところを普通は検証するのだろう。明らかに正しそうなやつは手を抜いてしまえるはず。

バリデーションも契約を表現する手段の一つ。契約を検証処理として実装して表明するのがバリデーション。型と同じようにすべての実行について契約が満たされるかを検証する。一方でテストと同じように実際に動くものに対して検証を行う。

実際に動かして試すのは何だろう。契約とはあまり関係なさそう。実装したやつがどんな感じになってるか微妙なので試して動作を観察するのがとりあえず動かしてみる目的。これは脇道だったな。ただし、あまりによくわからなくなっているときは分割統治をするときだと思う。自分の手の中にある対象をコンポーネントに分割して、それぞれに対して契約をデザインする。その契約を満たすように実装しつつ、その契約を期待して組み合わせて元々の目的を達成すれば良い。わからない部分が新しい契約の内側にはいれば小さくなった簡単な契約を満たすことに問題は帰着できたし、それらの契約を組み合わせることに課題があるなら詳細を忘れて便利な道具を手に入れられたのだからやはり問題は簡単になっているはず。うまく契約を設計することが難しいなら、それは楽しいから問題ない。ずっと取り組んでいればいい。

何にしても契約を表明することが何より先にくる。これだけでプログラミングが楽しくなる。その後に型、テスト、バリデーションを書いたり実装をしたりする。

そういう考え方が how to design programsにデザインレシピとして書いてあるのでよかったら読んでみてください。

プログラミング言語はこの辺りが優秀で、型システムの研究とかで契約を表明して保証する方法を検討しているし実際に生かされている。なので言語に守られているうちは割と安心できる。あとは怠慢にならなければいいだけ。

プログラミング言語に閉じられなくなるとき、例えばWeb APIを提供するときは急に難易度が上がる。Web APIでも契約を表明して検証するためにスキーマ駆動開発がある。契約を書き下すことを支援するのはもちろん、型とかバリデーションで表明することも支援する。テストツールの支援もある。

僕たちが求めているのは以下である。

  • 契約を表明すること
  • 契約を洗練すること
  • 契約を犯せないようにすること
  • 契約を犯しかけたらなるはやで誰かに教えてほしい
  • これらを簡単に実現できること

最初のやつは設計しようぜ！という話。次が設計技法とか良い設計みたいな話。三つ目は型とかバリデーション、テストの話。次もそう。最後のやつはそれら全てを支援するエンジニアリングの話。

契約の話をしたのでパラダイムの話をしたい。オブジェクト指向と普通のやつの話。どっちでもいいけど、契約を表明しやすいパラダイムが良いと思う。

オブジェクト指向な考え方だと、内部状態を持つオブジェクトがメソッドを受信してその結果内部状態を変えたり返信したりする。そういうふうに契約を表明して守っていくならオブジェクト指向を使えばいい。

関数型みたいな普通のやつは、仮定が与えられた状況で関数を呼ぶと結果を出す。そういう契約の書き方をするなら関数型みたいに書けばいい。

どちらも相互に変換可能だから力まず表現しやすい言葉遣いを使えば良いだろうと思う。

割と思いの丈をダンプした。これは就職したからできたことのように思う。学生の頃に培った理想が現実世界では必ずしも簡単に実現しないことを体験できた。自明だと思っていた領域の非自明な部分に気がついて思うところが出てきた。

プログラミングの楽しいところは、ロールを分けてうまく契約群を設計することにあると思う。フレームワークを作るのはそういう契約の集まりを定義することだから楽しい。一方でフレームワークを使うと契約を設計する機会を奪われる分楽しくないかもしれない。

その分他のレイヤに注力すればいいのだろうが。

自分が自由に設計したいレイヤで他人に契約を決められるとストレスだろう。本当につまらない。反対に自分が関心なくて誰かにうまくやって欲しいときには良い契約を強い人に決めて欲しいと思う。そういうレイヤを担当するフレームワークを使って欲しいし、技術を選定したい。

アーキテクチャ設計についても言及できそう。アーキテクチャは中長期的には変遷するものだが、短期的には変わらない。アーキテクチャに乗っかってここのコンポーネントを作り込む。ここのコンポーネントをストレスなく作り込みやすくするアーキテクチャが良いアーキテクチャなのだろう。

2024-10-28

昔は親の顔より見た lambda をこの頃は全然見ていないしタイプしてもいない。寂しいねえ。クロージャをぼちぼち使うのだけど、評価規則や型規則とにらめっこする時間は完全に失ってしまった。

Goのanalysisとtypesに入門する

Goで静的解析してリンターを実装したい。具体的には、あるT1インターフェース型の変数がスコープにあるときは、T1よりゆるい任意の型の使用を禁止する、みたいな制約を入れたい。その辺に転がっている記事ではASTを覗いてみたり、SSAを覗いてみたりするようだけど、ASTとその型をまともに扱っていつつ、いい感じに静的解析ツールとして仕上げる記事を見つけられなかった。

この記事ではGoプログラムの静的解析ツールを実装するために存在する標準的なツールチェーンの思想を説明する。Go Analyzerは静的解析ツールフレームワークとして用いる。具体的な静的解析には標準ライブラリを用いる。

具体的には、あるT1インターフェース型の変数がスコープにあるときは、T1よりゆるい任意の型の使用を禁止する、みたいな制約を入れたい。

これを検証するGoの静的解析ツール。例えば以下のようなrの使用を検知したい。

func parse(r io.Reader) (string, error) { ... }

func (rw io.ReadWriter) {
	var r io.Reader = getReader()
	s, err := dump(r) // 「rじゃなくてrwを使ってくれ〜！」と指摘したい。
	...
}

https://pkg.go.dev/golang.org/x/tools/go/analysis これ。準標準なパッケージ。ドキュメントの冒頭に思想がちゃんと書かれているのでそれを読むのが良さそう。

一個の解析ツールに対応する。Analyzer.Runに解析を実行する関数を定義する。この解析ツールを実行するとき（実行するのはフレームワークの仕事）に、Pass構造体が渡される。

Pass構造体は解析対象のパッケージごとに作成される。なので解析の単位はパッケージごとということになりそう。いいじゃん。

type Pass struct {
	Fset         *token.FileSet
	Files        []*ast.File
	OtherFiles   []string
	IgnoredFiles []string
	Pkg          *types.Package
	TypesInfo    *types.Info
	ResultOf     map[*Analyzer]interface{}
	Report       func(Diagnostic)
	...
}

こいつを通じて解析をする関数は処理対象のデータにアクセスしたり、処理結果を報告したりするぽい。モナドとか代数的エフェクトみたいで綺麗だ。そう思うとあれらは抽象化された一つの振る舞いの切り口を表現するための基本的な演算を定義していたのだから、まあそうだなと思える。Kokaで静的解析ツールを作るときにはpassエフェクトを定義するのだろう。

The Fset, Files, Pkg, and TypesInfo fields provide the syntax trees, type information, and source positions for a single package of Go code.

これは本質情報の予感。このあたりにうまくアクセスすることで、ぼくたちの頭の中で想像する型付き抽象構文木へのアクセスを実現できるんだろう。データ構造が思ったのと違いそうなことには気をつけよう。

これらに加えて、他のanalyzerが出力してくれる結果をこのanalyzerの入力として使える。それにアクセスするためには pass.ResultOf[a].(aResType)を参照すればよい。

診断(diagnostics)を出したければPass.Reportとか、パッケージで提供されているReportfとかを使うらしい。

ここまでで、モジュラーに静的解析ツールを実装するフレームワークの構造がわかった。それに乗っかれば静的解析をいい感じに動かすことはできそうだ。静的解析の処理を実装する方法もなんとなくわかった。Pass構造体の世界観に乗っかればokな感じがする。

次に自在にプログラムを解釈する方法を知りたい。プログラムはコンパイラに処理されていろんな形態に変換されるので、ユースケースに応じて適切な表現を選ぶ必要がある。今回は型付き抽象構文木を扱いたいので、Pass構造体のFset, Files, Pkg, TypesInfoあたりを上手に使えると良さそうだ。特にTypesInfoが気になる。これは types.Info型をとるみたいなので、typesパッケージを見に行く。

typesパッケージはこれ https://pkg.go.dev/go/types。冒頭の説明がスッキリしていてまだ何をやれば型付き抽象構文木に対してクエリっぽいことをできるか、どんなクエリっぽいことが許されるかを理解できない。なので貼ってあったチュートリアルのリンクを辿る。なお、スッキリしている説明自体は読んでよかった。このパッケージが扱うフェーズで何をやるか説明されていて、もっと詳しく読んで良さそうなことに自信を持てた。

なお、僕の目的のためには他の解析ツールの結果を使う方が良いかもしれないとも思う。暇だし気になるのでチュートリアルを読むのに時間をかけるけど。

脱線したがチュートリアルを読み進める。https://go.dev/s/types-tutorial これ。これを読む目的は、何をやれば型付き抽象構文木に対してクエリっぽいことをできるか、どんなクエリっぽいことが許されるかを理解すること。

このチュートリアルはジェネリクスには対応してないらしい。ジェネリクスのためのドキュメントは別途あるとのことだけど、今回は基礎を知りたいので気にしない。

イントロと例くらいは読んでみて、あとは斜め読みでいいかな。まずはイントロ。

Measured by lines of code and by API surface area, it is one of the most complex packages in Go’s standard library, and using it requires a firm grasp of the structure of Go programs.

とのこと。大変だ。

Starting at the bottom, the go/token package defines the lexical tokens of Go. The go/scanner package tokenizes an input stream and records file position information for use in diagnostics or for file surgery in a refactoring tool. The go/ast package defines the data types of the abstract syntax tree (AST). The go/parser package provides a robust recursive-descent parser that constructs the AST. And go/constant provides representations and arithmetic operations for the values of compile-time constant expressions, as we’ll see in Constants.

データ構造とアルゴリズムを分けるの賢そう。parserにastを定義しないとか偉い感じがする。色々あるんだろうな。どう嬉しいのかはわからないけど。定数畳み込みをastに対して実装したいが、parserに依存するわけではないよね、みたいな話かな。

名前解決、型検査、定数式の計算は一緒にやらないといけないなるほど。ここでいう名前解決とは、名前の出現に対してその宣言を対応させること。

例まで読んだがパッケージレベルの話しかわからないな。ぼくは式とかのレベルでプログラムを処理したいんだ！ということで本命のInfo構造体への言及を探すことにすると、TypeAndValueでそれらしいことを述べている。

Info.Typesは map[ast.Expr]TypeAndValue らしい。そろそろ手を動かして、プログラムのこの要素は式として扱われるか？とかをみたい。と思ったらドキュメントが例を出してくれた。こういうときが一番楽しい。式があったら型は得られるようになってるのね。ただまだよくわかってなくて、mapの定義域をast.Exprとしているが、そのExprとして本当に登録されるのはどの範囲のExprなのかがわからない。当然 ast.Expr{} なんて渡しても、その型を計算しているわけがない。どういう操作で手に入れたast.Exprに対しては、Info.Typeがその型を教えてくれるんだろうか。Infoを生成するやつが知ってるのかな。analysisパッケージはよくわからんPassがInfoを持っていたので微妙だけど、パッケージの単位で処理をするのでパッケージに存在するすべての式の型を教えてくれると思って良さそう？

確かにConfig.Checkはパッケージを型検査して、引数にInfoへのポインタをとって結果を書き込みそう。

次に、型同士の比較をしたい。具体的には、T1が必要な文脈でT2は使えるか (assignable) を判定する方法が欲しい。そのためにこれが使えるhttps://pkg.go.dev/go/types#AssignableTo。引数に渡すTypeインターフェースの値はTypeAndValueで取れるので、ほとんど勝ったようなもの。ちなみに僕は、最初ConvertibleToを使っていて全然ダメだった。ConvertibleToは数値が変換できるか判定するやつぽい。

AHK入門

Windowsマシンでキーボード操作が不便なので導入する。悪態をつきながらも使っている人を知っているので内容を理解していないが期待している。

https://www.autohotkey.com/ 公式ページからバイナリを落とせる。インストールするとwelcome画面が開いたのだが、そこに「コンパイルする」ボタンがあって、ちょっと不安になる。僕はプログラムをボタンを押してコンパイルしないといけない？

ついてきたマニュアルはいい感じのスタイリングでよみやすそう？

頭から飽きるまで読んでいく。

  • スクリプトの作成 (Create a Script)

    • Be sure to save the file as UTF-8 with BOM if it will contain non-ASCII characters. For details, see the FAQ.

    • BOMがいるらしい。そういえばBOMってなんなのだろう。結局まだちゃんと理解してない。
  • スクリプトの実行 (Run a Script)
    • なんかソースファイルをダブルクリックしたりして実行できて、実行してる間だけ効くらしい。
    • イベントハンドラみたいなやつの定義がそれぞれのスクリプトに対応するかと思っていたが、なんかメンタルモデルがあってなさそう
  • それぞれのスクリプト実行がWindowsのトレイアイコンに反映されるらしい。なるほど

飽きたのでhello worldする。

以下はCapsLockを押すとhello, worldと出力するよう設定するahkスクリプト。ちなみにこれらのhello, worldはCapsLockを打って入力している。

#Requires AutoHotkey >=v2.0.0

CapsLock::
  {
    SendInput "hello, world"
  }
  Return

CapsLockで英数変換するのは以下で実現できた。

#Requires AutoHotkey >=v2.0.0

CapsLock::
  {
    SendInput "^{Space}"
  }
  Return

紆余曲折あって、以下のようになった。Windowsでもいい感じにvim使えるようになって幸せ。

https://github.com/naoyafurudono/dotfiles/blob/main/autohotkey.ahk

#Requires AutoHotkey >=v2.0.0

IME_SET(SetSts, WinTitle:="A")    {
    hwnd := WinExist(WinTitle)
    if  (WinActive(WinTitle))   {
        ptrSize := !A_PtrSize ? 4 : A_PtrSize
        cbSize := 4+4+(PtrSize*6)+16
        stGTI := Buffer(cbSize,0)
        NumPut("Uint", cbSize, stGTI.Ptr,0)   ;   DWORD   cbSize;
        hwnd := DllCall("GetGUIThreadInfo", "Uint",0, "Uint",stGTI.Ptr)
                 ? NumGet(stGTI.Ptr,8+PtrSize,"Uint") : hwnd
    }
    return DllCall("SendMessage"
          , "UInt", DllCall("imm32\ImmGetDefaultIMEWnd", "Uint",hwnd)
          , "UInt", 0x0283  ;Message : WM_IME_CONTROL
          ,  "Int", 0x006   ;wParam  : IMC_SETOPENSTATUS
          ,  "Int", SetSts) ;lParam  : 0 or 1
}

IME_GET(WinTitle:="A")  {
    hwnd := WinExist(WinTitle)
    if  (WinActive(WinTitle))   {
        ptrSize := !A_PtrSize ? 4 : A_PtrSize
        cbSize := 4+4+(PtrSize*6)+16
        stGTI := Buffer(cbSize,0)
        NumPut("DWORD", cbSize, stGTI.Ptr,0)   ;   DWORD   cbSize;
        hwnd := DllCall("GetGUIThreadInfo", "Uint",0, "Uint", stGTI.Ptr)
                 ? NumGet(stGTI.Ptr,8+PtrSize,"Uint") : hwnd
    }
    return DllCall("SendMessage"
          , "UInt", DllCall("imm32\ImmGetDefaultIMEWnd", "Uint",hwnd)
          , "UInt", 0x0283  ;Message : WM_IME_CONTROL
          ,  "Int", 0x0005  ;wParam  : IMC_GETOPENSTATUS
          ,  "Int", 0)      ;lParam  : 0
}

IME_TOGGLE() {
  current := IME_GET()
  IME_SET(!current)
}

IME_OFF() {
  IME_SET(0)
}

CapsLock::
  {
    IME_TOGGLE()
  }

~Esc::
  {
    IME_OFF()
  }

RubyKaigi2024参加メモ

RubyKaigi2024に参加したので、思ったことをメモしておきます。

参加したセッションはこちら: https://rubykaigi.smarthr.co.jp/2024/plans/d2350276-c631-4bdc-ad75-49e446e798a3

今回のセッションをいくつか聞いてShopifyのやり方に憧れるようになった。エンジニアリングをしていく上での姿勢として、課題に対して上流から対処しよう、みたいな箴言があってそれが心に残っている。 ShopifyのRuby周りのチームはまさにそれを地で行っていると今回のセッションを聞いて感じたそういうチームに所属して（作って？）良いエンジニアリングをしていきたいと思っていたのだが、これまでは具体的なイメージいを持っていなかった。

ShopifyのRubyチームによる貢献にはすでに自分が直接的に恩恵を受けているし、彼らがどういう思想で取り組んで具体的に何をしてきたか、これからどういう思想でやっていくかを生で聞くことができた。遠いけれども具体的に目標とする存在に出会えたことが今回の一番の収穫だったと思う。

バージョンとかライブラリのインストールとか大変だしよく分からないのでスッキリする方向に進んでいきそうで楽しみ。セッションも普通に勉強になった。

一方的に知っていた人もお互い初めましてな人もお話しできてよかった。今回存在を新たに認知した人ももちろんいて、いろんな人が色々やっていることとか、意外とコミッタ少ないこととか認知できて良い。 Rubyって人間が作ってるんだなと感じる。

現実味を感じる一週間でした。

ElmアーキテクチャをReactで実現する話

リアクティブプログラミングの勉強をしていた頃にElm言語を知って好きになった（全然コード書いてないけど）。特徴はElmアーキテクチャにあると思っている。 Webアプリケーションの大体のフロントエンドアプリケーションはこう言うアーキテクチャで表現できるはず、みたいなことを言っていて、そのアーキテクチャが簡単なので気に入ったのだろう。

ユーザやAPIとやりとりをするアプリケーションなので、外界からの入力は当然ある。

また、それによって（のみ）アプリケーションの状態は変化する。アプリケーションが取りうる状態はアプリケーションに固有だし、どんなことがアプリケーションで起こって（入力としておきえて）、その結果どのような状態遷移をするかもアプリケーションに固有。なのでそれらはアプリケーションの実装者が決める。入力というかイベントがあって、それによってある状態から他の状態に遷移する、状態遷移系を定義するのはシンプルに思える。

状態が決まればそれの描画結果も決まるはず。もちろんDOMとかスタイルを当てたりとかして状態を描画結果に対応づける方法はそのアプリを作る人が定義する。描画というのは状態から描画結果への写像なのだ、と思うのがシンプルなポイント。

最初にあげた、外界からの入力は曲者。クリックとかレンダリングとかAPIの呼び出しとかは、知ったことではない感じがする。少なくともフロントエンドアプリケーションの範囲で意味を定義して実装するものではない。なのでその辺はElmのランタイムがいい感じに実装してインターフェイスを提供してくれる。そのインターフェイスを使いつつ、イベントを定義することになる。

Elmアーキテクチャは最高なんだけど、仕事のプロジェクトで使うとなると言語の選択はもっと資本主義ぽい判断が必要になって、TypeScriptとReact使うかという気持ちになる。

幸いなことにこれら二つでElmっぽいことはできるので、今の仕事では黙々とそれを進めている。 Reactで違うところは、Elmランタイムがなくてもうちょっと小さな部品がたくさんあって、それをいい感じに組み合わせて使うところだと思う。useEffect で頑張るとか。

そのあたりを頑張っているうちとかに、だんだんElmアーキテクチャっぽくするのが辛くなったりして辛い。みんなで強い気持ちでその方針に向かうのが良さそう。

https://guide.elm-lang.org/ がElmのガイドでElmアーキテクチャを推してくれる。なのでみんな読んでほしい。

エフェクトハンドラで実現したい世界と、Elmアーキテクチャみたいな世界は重なる部分が多そうだと感じている。 Reactの開発者もuseContextはalgebraic effectなんだ！みたいなことを何処かで言っていた気もするし、誰しも思うことなんだろう。

2024-02-17

glangにgeneratorを入れようというプロポーザルがあって、試験的に実装されているみたい。いくつかのパターンがあるけど、だいたいこんな感じで使える (The Go Playground)。

ジェネレータとして使われる関数は定義の段階では普通の関数と区別がつかないような構文定義をされている。コンパイラやランタイムの実装が気になるし、静的解析ツールが大変なことにならないかが心配。

気が向いたらプロポーザルを読もう。ジェネレータが引数にとる関数がブールを返すけど、どちらを返すかを誰が決めているかも気になる。

第一印象ではgolangには入らないで欲しいなと感じた。

2024-02-13

今日1on1で教えてもらった。ロールモデルとして追っていく。https://scrapbox.io/kawasima/%E3%82%A4%E3%83%9F%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%96%E3%83%AB%E3%83%87%E3%83%BC%E3%82%BF%E3%83%A2%E3%83%87%E3%83%AB

2023-12-26

ついったで同僚が panicIndex と言っていて、なんだそれと思ったので調べた。golangの文脈だったので想像はある程度ついて、golangのランタイムの一部として？実装されている関数でインデックスに関するパニックを投げる関数だった。

https://go.dev/src/runtime/panic.go

来年はついに配属される。小Rまでもそうだったけど求められることが変わるので楽しみ。今度は長くなるので、そこで効きそうな技術を特に強くしておきたい気持ちと、自分の主張を通しやすそうな環境なので好き勝手とがりたい気持ちがある。

どっちもやればいいかな。

推し言語機能 Racket編

この記事はGMOペパボエンジニア Advent Calendar 2023 🎅会場の19日の記事です！

昨日はyagijinさんのReactやってる人向けのSwiftUI入門でした。 Swiftに興味があるReact信者の僕のために書いてくれたのかと錯覚しました。これを期にSwift UI入門しようと思います。 Swift UIは双方向バインディングを採用しているとのことなので、Vueとの類似もありそうですね。

Reactを書いている時間は癒しの時間です。ところでReactは関数型言語からインスパイアされた機能が多いですよね。今日の記事はそんな関数型言語の中でも僕の好きなRacket言語の記事です。僕が一推しするRacketの言語機能を紹介します。

好きなRacket言語の言語機能を紹介します。ざっくりとした紹介なので、ここでの知識を人に話したりプログラミングで活用する前に、節々で参照する公式ドキュメントを参照してもらえると嬉しいです。

  • 契約
  • named let
  • 動的束縛

ここでいう契約とは、関数の入出力の性質を関数定義の際に宣言しておくことで、関数を呼び出しを実行する際に入出力の値を検証し、違反していた場合にエラーを投げる言語機能のことです。余談ですが、契約と型は対応する概念です。契約の検証は実行時に行いますが、型検査はコンパイル時に行います。静的に型をつける言語では関数定義の際にその型を宣言することで、関数呼び出しのあるコードの入出力の方を検証し、違反する呼び出しを特定します。 ContractのRacket Guideを貼っておきます。https://docs.racket-lang.org/guide/contracts.html

ここでは https://docs.racket-lang.org/reference/function-contracts.html の例をお借りして説明します。

> (define/contract (maybe-invert i b)
    (-> integer? boolean? integer?)
    (if b ( -i) i))
> (maybe-invert 1 #t)
-1
> (maybe-invert #f 1)
maybe-invert: contract violation
  expected: integer?
  given: #f
  in: the 1st argument of
      (-> integer? boolean? integer?)
  contract from: (function maybe-invert)
  blaming: top-level
   (assuming the contract is correct)
  at: eval:2:0

冒頭の define/contract で始まるS式では、関数定義をしつつ、その関数の契約を宣言します。二つの引数 i, b をとる関数 maybe-invert を定義していて、bがtruthyなら-iを返しbがfalthyならiを返す関数として実装しています。この関数の契約は(-> integer? boolean? integer?) と宣言されています。これはinteger?を満たす値とboolean?を満たす値を引数に取り、integer?を満たす値を返す関数である、と読みます。

(maybe-invert 1 #t) という関数呼び出し式では第一引数に 1, 第二引数に #t を渡しているので入力に関する契約を満たしていて、返り値は-1になるので出力に関する契約も満たしています。そのためエラーが出ずに何事もなく計算結果の　-1が表示されます。

一方で、 (maybe-invert #f 1) という関数呼び出しでは引数の順序を間違えて渡しているようです。第一引数にfalseを表す #f を渡しています。#f は integer? を満たさない（そういうふうに integer?が定義されている）のでRacket処理系は契約に違反している旨をエラーとして表示しています。

こういうのが契約です。ちゃんと確認していませんが、PHPで型注釈を書いた際にも実行時の検査が行われるそうなのでPHPは契約を言語機能としてサポートしているといえそうです。他にはD言語も契約をサポートします。

入力値のバリデーションはコードを書くときに当たり前に行う作業ですが、それをシステマチックに行うためのフレームワークを言語が提供してくれるのは魅力的だと思っています。また、契約は型システムや漸進的型つけとも密接に関わりがある楽しい概念です。

次はnamed-letです。これについても公式ドキュメントを貼っておきます。https://docs.racket-lang.org/reference/let.html#%28form._%28%28lib._racket%2Fprivate%2Fletstx-scheme..rkt%29._let%29%29

RacketやSchemeなどのLisp系言語で勉強しているとwhileやforは習いませんが、再帰を習います。例えば整数のリストを受け取って、その和を返す関数sumを定義するにはこんな感じで書きます。

> (define (sum lst)
          (if (nil? lst)
              0
              (+ (car lst) (sum (cdr lst)))))
> (sum '(1 2 3 4 5 6 7 8 9 10))
55

nil?はリストが空を判定し、carはリストの先頭要素をとる関数で、cdrはリストの先頭を除いた部分をとる関数です。先頭の値とそれ以降の和をたすことで、リスト全体の和を得ています。

このように再帰があればループはかけるのですが、関数を定義してその直後にその関数を呼び出す、そしてその後その関数は使わない、みたいなケースがしばしばあります。そういうときに役立つのがnamed-letです。以下のように再帰関数の定義と関数呼び出しを同時に行うことができます。

> (let sum ((lst '(1 2 3 4 5 6 7 8 9 10))
       (if (nil? lst)
           0
           (+ (car lst) (sum (cdr lst))))))
55

再帰関数を使ってループを書くことでループの中での再代入を避けることができます。そのためループ不変条件を把握するのが楽になります。そしてnamed-letを使うことで、不要な関数定義を省くことができます。スコープにある変数は少ないほど嬉しいです。ここだけで使う再帰関数なんだということが一目でわかります。あと書いてみるとわかるのですが、named-letを書くととても気分がいいです。

最後は動的束縛です。emacs lispの変数束縛は動的だということで有名ですし、最近だとReactのContextが動的束縛っぽいかなと思います。やはり公式ドキュメントのリンクを貼っておきます。https://docs.racket-lang.org/guide/parameterize.html

誤解を恐れながらいうと、環境変数みたいなやつをコードの中で設定できる機能です。公式ドキュメントの例をそのまま貼り付けます。

> (parameterize ([error-print-width 5])
    (car (expt 10 1024)))
car: contract violation
  expected: pair?
  given: 10...
> (parameterize ([error-print-width 10])
    (car (expt 10 1024)))
car: contract violation
  expected: pair?
  given: 1000000...

REPLで2回プログラムを実行しています。(expt x y) は x の y 乗です。それのcarを取ろうとしています（carはリストの先頭要素を返す関数でした）が、(expt x y)の計算結果は数値であってリストでないのでcarの契約に違反します。そのためエラーメッセージが表示されています。今回フォーカスしたいのは動的束縛です。parameterize で error-print-widthの値をそれぞれの実行で 5 や10に指定しています。その結果表示されるエラーメッセージの幅が5になったり10になったりしています(10... と 1000000...)。おそらくエラーメッセージを表示する関数の中で error-print-widthが参照されているのでしょう。

このように関数を呼び出すタイミング側でその振る舞いを変えられるのが動的束縛の旨みです。関数の引数で渡す必要がないので、動的変数を参照する関数と設定する関数の間の関数たちが余分な引数を取らなくても良いわけです。

グローバル変数を使ってもこのような引数を介さない設定はできますが、動的束縛を使う方が衛生的です。例えば一つのプログラムの中でグローバル変数の値を変えたい場合、グローバル変数の値を書き換えることになります。これは悪名高い可変なグローバル変数を使うことを意味します。可変なグローバル変数は無関係に見えるプログラムの実行順序がクリティカルにプログラムの振る舞いを左右するのでよくないです。

一方で動的束縛では関数呼び出しごとに値を設定するため実行順序のことは気にしなくて良いです。値を設定した呼び出しの範囲下ではそれが反映されるし、その範囲外ではその設定は無効化されます。このように衛生的に、かつ疲れない形で広い範囲で参照する値を設定できることがグローバル変数と比較した際のメリットだと思います。

動的束縛される変数を参照する場合、呼び出し側の不慮の事故によって変数の定義もれでプログラムが正常に動作しないかもしれません。環境変数を設定し忘れるとアプリケーションが動かないのと同じです。こういう事故は実行する前、例えばコンパイルしたり型検査のタイミングで気がつけると嬉しいですよね。

Racketでこの課題を解決できるかは知らないのですが、エフェクトハンドラとエフェクトシステムを使えば型検査の中で解決できます！ その説明をしたい気持ちが溢れているのですが、そろそろ日を跨ぎそうなので興味がある方は僕に声をかけてくれると嬉しいです。

プログラミング言語の言語機能、いいですよね。言語設計者が思う表現のベストプラクティスが詰まっていて触れるたびに嬉しくなります。

明日のアドベントカレンダーは冷静沈着なTepiさんがTextのJetpack Composeで画像表示した話を書く予定とのことです。 Jetpack Composeは名前しか聞いたことがないので、新しい概念を見られそうで楽しみです！

それでは良いクリスマスを！

2023-09-12

以下のあたりを完全に理解したらだいぶ楽になる気がする。

  • エラー処理
  • イテレータ
  • 借用とcopy

エラー処理やイテレータの周りはrustに限らずどの言語でも乗り越える一つの壁な気がする。例えばpythonに入門したときは、フランクにExceptionを継承したクラスを定義して、それを投げたりキャッチしたりすることを覚えたり、ジェネレータやリスト内包表記を覚えたりしたときに楽になった。そのほかはモジュールとかパッケージ周りの仕組みが新しく言語を学ぶときの障壁だと思っている。

借用とcopyは割とrust特有な気がする。似たところで、rubyの構文はその言語特有の難しさだと思う。 rubyの構文は慣れないとパースが難しいと思っている。実際に書いてみると、そう書きたくなる気持ちはわかるし書いていて気持ちいのだけど。

エアダスターを買ってノートパソコンのキーボードを掃除したら幸せになれた。ちょっと前にUキーの裏にゴミが入って、たまにかちゃかちゃ言って鬱陶しかった。そして週末にオリエンの都合で外でパソコンしたときに、たくさんゴミが入った気がする。

Amazonで400円くらいのエアダスターを買って使ってみたら、なんとなくよくなった気がする。昔の自分だったら圧縮した気体を吹き出すために400円かけるなんて、とか思っていただろうから成長した。手段ではなくそれがもたらす価値に対してお金を払えるようになったので偉い。

この価値観は、賢く生きるためには逆手に取ったり取られないようにしたりしないといけないんだろうなと思う。例えば自分が提供する価値を売るときには、この価値観を持つ人に対して安価な手段で高い見返りを得られると良いし、自分が目的を達成するために人のリソースを買うときは、リソースの売り手が想像もつかないような価値を見出すと有利だろう。

読んでいる。https://dl.acm.org/doi/10.1145/2660193.2660223

threaded codeの何がいいかを理解しないまま今に至っていたけど、ループ構造を変えることで分岐予測の精度を高めるみたいなことが書かれていて、そうなんだとなった。バイトコードハンドラのディスパッチをループの末尾で行うようにするらしい。ループの末尾でディスパッチするってどういうことだ？ それぞれのハンドラが相互再帰な関数として定義されていて、全てのハンドラの末尾で次のバイトコードを読み込み次のハンドラを末尾位置で呼び出す、みたいな感じかな。分岐予測の仕組みは僕の中でブラックボックスになってしまっているのだが、めっちゃすごいやつだと思うことにすると、コードパスと次に実行されやすいハンドラの間に確かに相関が生まれそうなので、分岐予測の精度は上がる道理があるかもしれない、という気持ちになる。逆にループの頭でディスパッチすることにすると、ハンドラの末尾でループ先頭への無条件ジャンプを経由してからディスパッチすることになる。この一回挟まる無条件ジャンプが邪魔なのかな。この論文に飽きたら答え合わせしよう。

契約と型検査

プログラミングの型検査・契約・テストについて書きます。お酒を飲みながら書きました。注意は払ったつもりですが、変なところがあるかもしれません。

  • 契約とは何か
    • 例を含める
  • どんな嬉しさがあるか
  • 型検査との兼ね合い

契約 (contract) とはプラグラムの関数の入出力に関する規約のことです。例えば整数の割り算をする div 関数は、二つの整数を受け取って商を返す関数だとしましょう。このとき、入力の二つの値は

  1. どちらも整数
  2. 二つ目の整数は0ではない

ことが求められます。また、整数の割り算を行なっているので、div(a,b) の値は例えば

  1. a の絶対値以下であること

が求められます（もっと細かい要求をしても良いでしょうが）。箇条書きで示したような div 関数について求められる性質のことを契約とよぶことが多いです。

ここまでで例を示しました。例のことは忘れて一旦抽象的な定義を試みましょう。契約は関数を呼び出す側と呼ばれる定義の間の約束事です。関数を正しく呼べば正しい結果を返すことを規定します。どんな呼び出しが正しくて、正しい呼び出しをされたと仮定とした上でどんな結果が正しいかを規定するのが契約です。

先ほどの例を考えると、 div 関数の第二引数に0を渡すのは呼び出し側の契約違反で、div(168,4) の結果が42にならないのは関数定義の契約違反です。契約は、関数呼び出しにおける呼び出し側と定義側との間の規約を表明し、検査します。

多くの言語でコードを書く際は、関数の冒頭で引数のチェックをして、呼び出し側の責任を追及するスタイルでコードを書くことになりがちです。言語によっては組み込みの機能でいい感じに契約を書いて、実行時に検査できます。 D言語とかRacketがいい例です。

例えばRacketだと、モジュールでエクスポートする関数を表明する箇所で、関数の契約を書きます。完全に雰囲気ですが、おそらくこんな感じで書くんじゃないかったかと思います。正確にはRacket GuideかRacket Referenceをご覧ください。

#lang racket

(export
  (div (-> (and int (lambda (x) (< 0 x) )) int  int)))

...

(define (div a b)
  (/ a b))

契約を書いておくと何が嬉しいでしょうか。問題の切り分けが楽になることが嬉しいですね。Blame shiftingができます。みなさん人生で一回は Segmentation fault とか Null pointer exception とか car: cannot apply for nil みたなエラーに遭遇したことがあるかと思います。これらのエラーは契約をちゃんと関数に書いていないから起きるはずで、まともなライブラリを使っていればあまりみないはずです。これらのエラーが出たときには割と深く絶望して、どの関数が悪さをしているか探す旅が始まります。

もし真面目に契約を書いていれば関数が許さないnilを受け取った時点で呼び出し側に責任があることを即座にエラーを起こしたり、変な結果を返しそうになったら返す直前に同様にエラーを起こします。

これが契約の嬉しさです。反対に、関数を動かして契約違反で怒られない限り、その契約を実装が遵守していることが保証されます。これもまた契約の嬉しさの一つです。契約はプロダクション環境で生きているドキュメントとして機能します。

テストとの違いは、契約は実行時に検査をすることが大きいでしょう。テストはテストを走らせるときにしか検証を行いませんが、契約は実行時にも検査を行います。プロダクション環境で関数を呼び出すときにも契約は検査されるのです。

契約はいいものであることがわかったと思います。関数定義の性質を保証して、何かあればすぐに検出し、何もなければ、すべてのそれまでの実行で違反したケースがないことを保証します。

この観点で見たときに、型検査はテストよりも契約に近しい存在だと言えるでしょう。型検査は、コンパイルのたびに型制約が満たされていることを検証します。健全な（まともな）型システムでは、型検査をパスしたプログラムは実行時に型エラーを起こさないことが保証されます （この保証がある型システムのことを健全だというので順番は逆ですが）。型検査では、関数の入力として渡される値が、関数が期待する条件を満たすことを検査しますし、関数が返す値が宣言にあっていることも検査します。契約と対比させると、契約は実行時に検査を行う一方で、型検査はコンパイル時に行うという感じです。

逆にいうと、契約は型検査で静的にやろうとする検査を実行時まで遅延したものです。実行時には任意の計算をできるので表現力は契約の方が高いです。例えば引数の値が10と20の間である、みたいなことを検査するのは型検査では大変ですが、契約ならちょちょいのちょいです。

じゃあ契約だけでいいじゃないか、型検査なんてやめてしまえ！という話になるかというと、そういうわけにもいきません。型検査には契約にないよさがあります。

型検査の良さは静的に検証が済むことにあります。つまり、以下の二つを型検査は満たします

  1. 全ての実行について、検証結果が成立する
  2. プログラムを実行しないでも検証を行える

まず一つ目について。契約やテストでは、実行した場合については動作を検証してくれますが、それとは違う値については特に保証をしてくれません。だから境界テストみたいな、人間が上手に動かす技法が使われるのでしょう。型検査では、ある程度検証内容を抽象的にしたり保守的にすることで、全ての実行に対する性質を保証します。 intが返る関数は決してfloatを返さないことを型検査では保証できます。

抽象化や保守的な検査を行う二つ目の恩恵として、実行しないでも検証できることが挙げられます。本番環境で動かさないとわからなかったり、テスト環境をせっせと用意する必要は、型検査では生じません。

型検査や契約の有用性を主張してきましたが、それでもテストは必要です。実際に色々な具体的なケースで動かすことでわかることは多いでしょう。型検査は動かさないでもわかることを検証して、契約は動かしたらわかることを検証します。テストはプログラムを動かしてみて検証します。型や契約だけではプログラムを動かすことはありません。そこが大きな違いなはずです。

それでも全ての異常の検知をテストでまかなう必要もないはずです。契約や型検査は保証をする仕組みとして優秀です。基本的な保証は契約や型検査で済ませて、本当に際どいところをテストでカバーする、みたいな役割分担をすると幸せになれるんじゃないでしょうか。

2023-07-22

コンパイラの実装で、次はポインタ算術をやる。演算子がオーバーローディングされているので型検査が必要。今は環境とかのデータ構造を設計する気力がなくて、パソコンを前にふにゃっとしている。お昼ご飯食べたら考える。

興味本位でコンパイルしたプログラムの実行速度を測ってみた。時間計算量が試数時間なfibの実装（あのみんな大好きなナイーブなやつ）で、 fib(40)を計算してみた。自作コンパイラだとuser時間が1.3secくらいなのに対して、 gccのO3でuser時間が0.3secくらいだった。 O3を指定しないと（多分O2）0.5secくらい。 Inliningとかは効かないだろうし、ループ周りでの最適化もできないはず。スタックマシンではなくレジスタマシンとして動かすことで（無駄なpush/popを排除することで） O2くらいの速さになってる感じかな。 O3では何が早くなってるんだろう。気が向いたら調べるか、実装するかしたい。

お昼を食べて買い物に行ったあと、型検査器を実装した。がんばった。 strcmpがboolを返すと思い込むやつをやって時間を溶かした。ランニングをしてオーバーロードに取り組む。今はintもポインタも64bitにしているけど、abiをみたらintは32bitっぽいので合わせる。オーバーロードは楽しそうだけどintを32bitにするのが面倒。 ASTに型を行き渡らせたので難しくはないはず。

買い物ではズボンを買いに行った。涼しい長ズボンが欲しかったので。初めて買う感じのやつを変えて満足している。サンダルも欲しかったけど、僕の期待が矛盾していることに気がついたので断念。来年は期待を変えられることを願って今年はスニーカを履き続ける。

Cとかその辺の関数型言語を使っていると欲しくなる言語機能第1位は動的束縛だという説を提唱したい。代数的エフェクトほどのことを普段使いに人類は求めているとは僕には思えなくて （普段使いと言ったのは、凝った仕組みを作る場合はのぞきたい気持ちの表れ）動的束縛が欲しいんじゃないだろうか。オブジェクト指向でインスタンス変数を使うのもこの用途が多いんじゃないかと勝手に思っているんだけどどうだろう。

とにかく、動的束縛が欲しい。動的束縛はいいぞの会を結成するまである。

Uを叩くとメチって音がする。髪の毛でも入り込んでしまったかもしれない。割とストレス。

2023-07-21

https://github.com/naoyafurudono/comp

早いもので作り始めてから2週間たったみたい。もっとサクサク進むと思っていたのだけど、しばらく楽しめそう。

自作CコンパイラでCのプログラムの一部をコンパイルできるようになった。これまでは変数宣言をできなかったので型宣言のあるmain関数を読めなかったが、 intだけ許容するようになったので、初めてCのプログラムをコンパイラが受け付けたことになる。

こんなコードをコンパイルすると、

int main()
{ 
  int a; int b; int i;
  a=0; b=1; i=0;
  while(i < 10)
  { 
    int t; 
    t=a+b; a=b; b=t; 
    i=i+1; 
  }
  return a;
}

こんなアセンブリを吐く。 SSAみたいな中間表現を挟んでレジスタ割り付けを真面目にやるのはいつがいいんだろうか。

.globl _main
.text
.balign 4
_main:
    stp x29, x30, [SP, #-16]!
    mov x29, SP
    sub SP, SP, #32
    mov x0, #-16
    str x0, [SP, #-16]!
    mov x0, #0
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-24
    str x0, [SP, #-16]!
    mov x0, #1
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-32
    str x0, [SP, #-16]!
    mov x0, #0
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
.L0:
    mov x1, -32
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #10
    str x0, [SP, #-16]!
    ldr x1, [SP], #16
    ldr x0, [SP], #16
    cmp x0, x1
    cset x0, lt
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    cbz x0, .L1
    mov x0, #-40
    str x0, [SP, #-16]!
    mov x1, -16
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x1, -24
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x1, [SP], #16
    ldr x0, [SP], #16
    add x0, x0, x1
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-16
    str x0, [SP, #-16]!
    mov x1, -24
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-24
    str x0, [SP, #-16]!
    mov x1, -40
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-32
    str x0, [SP, #-16]!
    mov x1, -32
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #1
    str x0, [SP, #-16]!
    ldr x1, [SP], #16
    ldr x0, [SP], #16
    add x0, x0, x1
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    b .L0
.L1:
    mov x1, -16
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    mov SP, x29
    ldp x29, x30, [SP], #16
    ret
    mov SP, x29
    ldp x29, x30, [SP], #16
    ret

2023-07-19

実装しているCコンパイラ で関数定義をできるようになった🎉。今までも既存のコンパイラで作ったオブジェクトファイルとリンクすれば呼び出すことはできていたが、自分で定義した関数がある程度ちゃんと呼べるようになった。

まだ型がlongしかないので道は長い。

https://github.com/atweiden/fzf-extras ここが良さげ。

2023-07-17

Cコンパイラをarm macで実装しているのだけど、a=b=0; return b;"みたいなコードがセグメント違反で落ちる。 lldbで調べてみると、main関数は正しい値をw0にセットしてretできていそうなんだけどその後の動的リンクされたコードでエラーが発生しているみたい。設定する値を変えるとエラーにならずに実行が終了する。謎である。

ABIを守っていないのが悪さをしているかも。

土曜日はパソコンしてた。お昼頃に連絡が来ていたことに気がついて、翌日の約束をした。

勢いで日曜日は丹沢に行くことになって、卒業ぶりに会った友達と2時間くらいの登山をしてきた。コースタイムが4時間だったのでいいペースだった。最近登山をしておらずペースタイム通りの時間でいく想定をしてしまっており、思ったよりもあっさりと終わってしまった。友達の靴が下山した後の道で壊れてしまったのでサンダルを貸して歩くことに。風呂に入ってからはま寿司で3時間くらいお茶を飲んで帰宅した。

日曜日は海の日なので海を目指して部活の後輩と走った。天王洲アイルが海の近くだったのでそこまで行ったのだが、思ったよりも海っぽくなかったのが残念。久しぶりに走ったので走り始めがだいぶ辛かった。

久しぶりの人と会うと時間の流れを感じる。

arm64のメモ

Cコンパイラを実装するためにarm64のことを調べている。この記事はそのメモ。

よくあるソフトウェアのライブラリについているドキュメントとは毛色が違う。

Arm macを使っている人の話です。

  • 既存コンパイラがはくアセンブリを覗く方法
    • アセンブリをはく: gcc -O0 -S
    • ディスアセンブル: otool -vVt
  • デバッガで調査する

アセンブリ命令って割と体系的になってなくてやばいイメージがあったけど、 arm64は秩序がある程度あるように感じている。まだ深淵を覗けていないだけかもしれないが。汎用レジスタの名前が簡単なことが大きいかもしれない。

2023-07-08

椅子に座るほどの元気がなくてもパソコン座れるので楽しい。気軽にコーディングできる。

cコンパイラ実装するやつは、今からローカル変数の定義に入るところ。ここまでで、四則演算と比較をコンパイルできるようになった。 armでやっているのだが今のところそんなにx86と違わない。 push/popでスタックポインタがarmだと16byte境界にしか設定できないとか、割り算がシンプルだとかくらいの違いしか観測していない。

そういえばenumは値だった。変数名みたいにコンパイラがよしなにするやつというイメージが強くて戸惑ってしまった。今回初めてcファイルを頭を使って分割した。定義と宣言の違いを認識して活用する日強がある。

パーサ前はサクッとできて、コード生成も一応形にはしたのだが、生成したアセンブリをアセンブルして実行するとセグフォで落ちる。 x29にSPをmovするだめみたい。x29以外にしたらどうだろうと思い、x9を使ってみたらセグフォのタイミングが変わった。ちゃんと追ってないので明日起きたら追ってみよう。

とりあえず、armのマニュアルを落とした。めちゃ長いけど良さげ。ソフトウェアと違って、ライブラリが無い分こういうふうに一つのでかいドキュメントが提供されるのはなんかそうなんだろうな、という感じがする。Web版よりも検索しやすいのはいいこと。今日はこれくらいにしよう。

ちなみに今はラフロイグ10年を飲んでいる。いいでしょ。

動画を見たり手を動かすことが増えた。あとは仕事でドキュメントを読む時間が増えて、活字が安定供給されているのが影響しているかも。

とはいえ仕事で読むドキュメントは、読み物としてはそんなに面白く無いことが多い。その分手を動かしてものを作るのが楽しいからいいのだけど、小説を読む楽しみとか、心に響く論文を読む感覚が足りない。小説とか論文とかに飽きてきたのはあるのかもしれない。残念ながら深掘りできる人間ではなかったのか。広く学ぶ好奇心とかがあるわけでもないのだけど。

話題になっていたのは当時から認識していたが、ずっとみていなかったユーフォを見た。特に第一シーズンが好きで、上手くなりたい、のあたりが響いている。僕がある程度まじめに考えて方向性を決めるときには、上手くなりたいが奥底に合ったなと再認識させられた。

頑張っているときはわからないけど、少し環境が変わると上手くなっていたことがわかる。加えて、そのときになって周りから、それが上手い人というラベルを貼られることに気がつくし、振り返ると上手くなったなと気がつく。上手くなりたいと憧れた、あの頃の自分からすると今の自分は割といい線行ってるんじゃないかと思う側面がある。全部が全部上手くなってるわけじゃないけど。

この頃は、上手くなった先に何があるのかということをちらほら考える。幸せがあると思っていたのだが、実際のところはどうなんだろうか。今は体力と好奇心と自尊心がボトルネックになって、ボトルネックになってることがそれらを削っていくんじゃないかと思う。また、自分が上手くなるのにかかる時間が実感を通して認識できたことで、自分の限界を認識するようになるのだろう（僕はまだ認識してない。アカデミアのスターにも総理大臣にも、経済界のドンにも縁があればなれると思ってる。巡り合わせに依ると思ってる時点で擦れているのかもしれないけど）。

僕はアニメを見て、アニメの感想ではなく内省をアウトプットしたくなってしまうので自分から進んでアニメの話をしたくならない。聞かせるのは悪いなという気持ちとなんか恥ずかしい気持ちがある。日付が変わってしまいそうなのでこのくらいで。ところでフロムザバレルは甘い。干し芋っぽい風味がする。

明日はランニングしよう。午前中に走ってみる。

2023-07-05

プロトタイプベースのオブジェクト指向言語について、哲学の方面から議論したエッセイを読んだ。クラスベースなのは古典的なアリストテレス的な分類の考え方に基づくもので、プロトタイプベースなものはヴィトゲンシュタインっぽい考え方に基づくとのこと。

アリストテレス的な考え方では、物事は分類できて、しかもいろんな分類があったとしても最高の分類みたいなものがある、みたいに捉えるそう。分類の中でその類を象徴する代表みたいなものも取れてしかるべきみたいな。一方でヴィトゲンシュタインっぽい考え方ではアリストテレス的なのには割と無理があって、そんな考え方が通用するのは数学の概念くらいとしていて、分類は観察する主体に依るし、文化とかの影響を受けるもので「科学」みたいに自然に導かれるようなものではない、みたいな考え方をするらしい。

リアルワールドを表現、分類しようと思うと確かにヴィトゲンシュタインの方がしっくりくるというか、矛盾が少なさそうな雰囲気がする。だけど、独自の世界を作ろうと思うとヴィトゲンシュタインの考え方に基づくのは骨が折れそう。

では、関数型言語とか意味論の人たちの視点だとどうなるだろうか。オブジェクト指向は哲学の話に基づいて議論しているみたいだが、型システムとか意味論は論理学をベースにしがち。型は命題でプログラムは証明。

ところで

型は命題でプログラムは証明。

この標語はしっくりきていない。型に入る_項_を僕は証明だとは思えない。依存型は項に依存する型だとは思えるけど、証明に依存する型と言われるとなんだかなと思う。まあ、その項にも型をつけるので、その型の証明にはなっているのだけど。Numみたいな型を命題というのがしっくりこないのと同じか。

依存型でも依存する項の型が関数型とかの命題っぽい型だったら証明に依存している雰囲気を味わえるかもしれない。帰着を考えればいいのかな。この命題が成り立つなら、これこれが成り立つ。これは依存型じゃないな。帰着は型をとって型を返すだけなので、type operatorだ。

ところでラフロイグの10年おいしい。

nが2より大きい、みたいな命題は依存型がないと表現できないか。簡単だ。

\Pi n: Nut. (n > 2 -> \Pi x,y,z: Nut. x^n + y^n != z^n)

ここで _ > _ は依存型。普通だね。

話を戻す（ラノベだったらここで閑話休題って言ってた）。オブジェクトと抽象化の話をしていたのだった。オブジェクト指向では、分類を動的な性質としてみるきらいがありそう。それに対して関数型っぽい世界では、分類は静的にできる型判断でしかないイメージ。型によって動的な振る舞いは変わったり変わらなかったりするけど、とりあえず型は静的につけるものだと思う。その情報を実行時まで持ち越すかは好きにすればいい、くらい。

動的メソッドディスパッチはいまだにしっくりこないし、メタプログラミングに関しては勝手にやってくれって思ってしまう。

ディレクトリの構造で投稿の分類を決めるのはよくないと思う。分類なんて書いているうちに変わるのだし、その方が便利そうなので全てはフロントマターにお任せしてしまえばいいと思った次第。そんなこという子はhugoユーザには要らないのだろうから、そのうち独立するのがいいんだろうな。

明後日が七夕だ。花金なので会社の人と七夕のみをできるかもしれない。

七夕は織姫と彦星が一年に一回逢瀬を重ねられる日。天の川に橋がかかるんだったか川の水が引くんだったかで会える。ここでは皮の水が引く説を採用する。

旧暦では時期的に川の水が引いたかもしれないが、現代では7月の頭はまだまだ梅雨みたいなもので川は元気だ。このままでは織姫と彦星は約束の日に会えない。かわいそう。なのでいつも夏の大三角に心を癒してもらっている僕たちは、せめてもの恩返しに川を飲み干して、逢瀬を支援することにした。これが七夕のみ。幸いなことに梅雨の雨で薄まった川はアルコール度数が比較的低く、ほろ酔いくらいのイメージ。だからこの日は梅雨がもたらす潤沢な量のほろ酔いを飲む。

エンジニアリングは手段でしかないと今は本心で思っている。とはいえ、プログラミングやエンジニアリングをしていて幸せを感じるタイミングもある。このギャップはエンジニアリングの成果を確かめることにあると思う。

例えば家に電気が通っていることは感動的なことだと頭ではわかるが、その恩恵を享受することは特に幸せだとは思わない。それに対して、新しくプログラミング言語を学んで、これまではできなかった表現でこれまではできなかった解決策を実現するのはとんでもなく楽しい。さらにはこれまでは明らかではなかった解決の方法を明らかにするのは結構な幸せだ。

このギャップは成果を確かめること、差分を観測することにあると思う。微分係数が大きいときが一番やりがいを感じる、みたいな話に通じる気がする。

  • 会社の人の親切に触れたこと
    • 一人だけじゃなくて4,5人くらい
  • 会社じゃない知り合いとちょっと仲良くなれたこと
  • ラフロイグがおいしいこと
  • オブジェクト指向の話が面白かったこと
  • 権八に行けたこと

こんなしょうもないことを書いていたせいで、今日の元気が終わってしまった。ラフロイグに完敗。またこんなことをインターネットで公開するおかげで恥の概念がなくなってきた。これは良し悪しありそう。

2023-06-29

crate.ioに初めてコードを登録した。cargo install で入るから便利。ちょっとしたCLIツール書く体験がなかなか良い。 copilotが面倒なことやってくれる。

crates.io

Railsとか書いてると深いところに元からあるファイルをコピーしたいことがちょいちょいある。そのときに長いパスを2回打ちたくないので作った。

2023-06-24

macのタイムゾーンの設定が狂っていて、今日の投稿がこれと前回の二つに分かれてしまった。

今日はmacの設定と、以降に伴って壊れたちょっとしたCLIツールの修正した。昔Rustで雑に書いたもので、エラー処理が辛そうだったので少し勉強して改善した。 anyhowを使ってみたい気持ちが湧いたけど、まずは基本的なところからということでトレイトオブジェクトを使うことにした。type Result<T> = std::Result<T, dyn Error>みたいな感じにすることで、いろんなエラーを孕んだresultに?を使うことができて幸せ。

一箇所ムムッとなったのが、クロージャの中で?を使う箇所。dyn Errorの気持ちで書いていたら、推論器はもっと具体的な型を推論していたみたいで、二つ目のエラー型の式に対して?したら型エラーになってしまった。こういうときはアノテーションをつければ良い。 Rustの型推論の割り切り方に慣れていない。

2023-05-13

もともとbashで書いていたスクリプトを拡張したくなって、普段ならPythonで書くところを今日は新しいことをしてみようということでRustをつかってみることにした。

Rustはまったく初めてと言うわけではなくて、ちらちらドキュメントを読んだり、ノリで学校の課題をRustで書いてみたり（痛い目にあった）したことがある。所有権のあたりで苦労はあまりしなかった（というかPythonっぽくヒープを贅沢に使うコードを書いた）のだが、Result / Optionの変換で発狂しかけた（メソッドが定義されていることに思いをはせられずに自作してしまった）。

あまり苦労しなかったと言いつつ、所有権のあたりで困りはしている。参照を受け取るコンストラクタに、その場で作ったオブジェクトを渡したいときに、一旦変数に束縛しないと、渡すオブジェクトが即死してしまっていけない問題が面倒。名前をつけるまでもない、式が体をを表しているような値にまで名前をつかないといけないのはしんどい。コンストラクタが所有権を奪うようにすればよいのだろうか。いらないから参照にしたのだよな…。

今ではそこそこなれてきて、代数的データ型とまともな型検査器がついたPythonくらいの書き方はできるようになった。 Rustのライブラリがイケイケに作られていて（エラー処理周りは辛いと感じるけど）、プログラムを書いていて楽しい。すごく汚く書いてしまった。当面の目標はまともにかけるようになることかな？ちょっとしたCLIでは大差ないのかもしれないけど。

ブログのGitHubのプログラミング言語構成比がカオスなことになってきた。

ここ何日か胃腸炎でつらい。今日はだいぶ回復して、Rustを勉強できるくらいになったけど、まだつらみを感じる。とはいえ三食たべても大丈夫な体に戻りはしたので問題なし。何日か会社に行けなかったのがなかなか悲しい。

今日は以前もらい忘れた診断書を書いていただいた。前回の診療に対して診断書を出してもらうことはなんだか難しそうで、もう一度診察していただくことになってしまった。自分の中では治ったと思っていたけど、見ていただいたらまだ治っていないとのことだったし、今はそう感じる（流されやすい性格なのか？）ので、忠告していただけてよかったと思うことにしている。

病院の帰り道で食器のフリマ的なことを日本料理屋さんがやっていた。普段使っている食器を入れ替えるのかなにかで、安く売り出してくださっていたようだ。胃腸炎になるまえに、会社のランチで「おいしそうな自炊の写真はくろっぽい器が大切」とのアドバイスを頂いていたことを覚えていたので、これは運命だと思い食器を購入した。黒っぽい器はどんぶりしか出会えなかったけど、それがなかなかいい感じだし、白っぽい器もいい感じのにいくつか巡り会えたのでほくほくしている。

あとはおいしそうなご飯をつくればよい。

夕飯につかってみた。いい感じ。味噌汁のお椀（蓋付き）が小さいやつで、フリーズドライの味噌汁一杯分しか入らないやつ（褒めてる）。感動している。

（アマプラ）。グレンラガンの監督？が制作しているらしい。ノリが楽しい。

2023-05-02

DDD周りを最近漁っている。原著はオブジェクト指向で説明されているけど、関数型で説明している本を直近で読んでいる。僕はプログラミングを関数型から始めた人間だし、集合論や関数解析が好きだったからかオブジェクト指向があまりしっくり来ない。インターフェースとかクラスでモデルする気持ちはなんとなく分かる気がするし、拡張性とか再利用性を考えたときに既存のコードをできるだけ壊さずに機能追加できるのは強いと思う。なんだけど、そういう変更ありきで書かれたコードが素直に対象を表現しているとは思えなくて辛さを感じてしまう。それに対して型とか関数型のあれこれを考えるときは、まだ分かる感じがして救いがある。モナドとかが普通のプログラミングに入ってくるとやはりこんがらがってくるのだけど。きっとパラダイムの問題ではなくて、抽象化になれてないとか親しんでないみたいなところが問題なのだろう。

話をDDDを漁っている件に戻そう。オブジェクト指向と関数型のそれぞれで同じようなことを表現しようと思ったときに使う言語機能を比べられて楽しい、ということを言いたかっただけなのだった。こういう見方をしていると、代数的エフェクトやエフェクトシステムのもたらす幸せがもっと浮かんできて本当に欲しくなるし、どんな側面が役立ちそうで、どんなところは妥協して良さそうかが感じ取れるようになってくるような気がする。

Ulauncherを使い始めた。とりあえずはただのランチャーとして使うけど、拡張機能をpythonでかけるのでターミナルの代わりのCLIとしても良いかもしれない。

2023-04-28

今日は意味論の直感が少し生えたので機嫌がいい。寝て起きたらもう少しまじめに考えよう。

完全に忘れていた。一回捨てた継続渡しスタイルで考えるのがやはり良いだろうという直感のもとでの考えだった。細かいことは忘れてしまったが、少し考えれば再現できる程度だったと思う。継続フレームを生むときと、式を評価するタイミングを明示的にわけるとか、反対にそういうくくりで共通化することでこれまで見えていなかったアスペクトが表面化していい感じになりそう、みたいな直感だった気がする。

2023-04-02

CPythonの開発者向けドキュメントがとてもよい。今はコンパイラの構成に関する部分を読んでいる。抽象構文木の扱いやメモリ管理の方針など、コンパイラ開発の方針を説明している。ドラゴンブックとかからは得られない、開発手法の知識を得られて幸せ。

好きな言語にドキュメントがたくさんあることは本当に嬉しい。

2023-03-19

最近AIが流行っていて、精度がすごいと話題で、生活が多かれ少なかれ変わっていくのだろうなという感じがする。ああいう機械学習ベースのAIは学習で直感を鍛えて、それに基づく出力をするものだと僕は解釈している。人間が頭を使うときには直感を論理とか議論で検証して、主張の穴を見つけて改善するサイクルを回すはずだ。今の機械学習っぽいAIは直感で得た主張を論理で解釈しないだろう（NECがそういうことを考えていそう。それができればAIはもっとつよくなるはずだし、そういうAIを見てみたい。

実現するためにはAIの入出力に使う「言語」に解釈を入れることと、それをもとにして論証を行うことが必要だろう。今のAIは抽象構文木を操作の対象にしていて、それを意味を解釈するようにしたらいいんじゃないかという想像だ。

今ある論理が世の中の事象を扱うのに十分かはわからないし、多分結構不足しているはずだ。機械学習AIのための論理体系の研究とかあったら楽しいだろう。NIIとかでやってないだろうか？

おととい届いたBig Peatがとてもおいしい。明日の研究室飲み会にもっていこう。ちょうど二年くらい前に部活の先輩に勧めていただいたのだが、懐具合の問題で飲めずにいた。少し無理してでも飲んでおいたほうが良かったかと思うくらいには好き。ストレートで飲んでもおいしいし、ハイボールにしてもおいしい。天才か？ ぼくはスコッチウイスキー？が好きなのかもしれない。

学部2年のころ、確率論基礎の試験の前日にウイスキーを飲む会に誘っていただいたとき、ラフロイグ・ロアを味見させていただいて半分感動したのを覚えている。あのころは二十歳になりたてでお酒のおいしさは今よりも分かっていなかったのだが、それでもいいかんじなことは分かった。それからラフロイグ・ロアには縁がなかったのだが今気になっている。数量限定なようで、毎年11月ころに発売されそうな雰囲気がある。今もアマゾンで売ってるが、転売価格に見えるので時期がくるまで我慢しよう。

ちなみにBig Peatと一緒に勧めていただいたジョニーウォーカーのグリーンラベルはすでに飲んでいて、 やはり好きな感じだった。

エフェクトハンドラの良さと実用性について

エフェクトハンドラで継続や代数的エフェクトを扱う必要性は一ミリもなくて、実用的にそれらが欲しくなることはないか、あるいは限られていてそこまで一般的な機能を提供する必要はないんじゃないかと感じている。

このあたりを議論するために

  1. エフェクトハンドラの嬉しさ
  2. 意味論の歴史的経緯
  3. 改善ポイント

を考える。

なお、この記事はとくに裏付けもなく書いている。気が向いたら裏付けをしようと思っているが、この記事の目的は僕の考えの整理であって、世に主張をしたいわけではない。

記事の内容は不正確なことを留意されたい。

エフェクトハンドラが実際的 (practical) なプログラミング言語でエンドユーザに使わせたくなるのは

  • エフェクトシステムと相性のよい意味論
  • 動的束縛

を提供したいからではないだろうか。エフェクトハンドラを言語に入れれば、それで表現できる操作は自動的にエフェクトシステムで追跡できるし、ハンドラを用いることでエフェクトをローカルに使えるのは特筆するべきだろう。汎用性とlocal reasoningのしやすさはエフェクトハンドラのもつ良い性質だと思う。

エフェクトハンドラで実現できる動的束縛はとても使い勝手が良い上に、エフェクトシステムで追跡することで使い勝手が上がりそうだ。動的束縛のためだけのエフェクトシステムではなく、もう少し凝ったことができるエフェクトシステムがつくとなお幸せだろうから、エフェクトハンドラみたいな抽象度の比較的高いフレームワークで実現するのは幸せなんじゃないかと感じる。

エフェクトハンドラと呼ばずに “algebraic effects” とか “algebraic effects and handlers” とか呼ぶ流派、時代がある。歴史的には

  • algebraic effects
  • algebraic effects and handlers
  • effect handlers

みたいな流れで登場したはずだ。最初はハンドラはなくて、モナドとかの話をするような人たちが副作用にモナドではない別の表現を与えようとしたんだったか。ここでいうモナドはモナド則とかを真面目に考えるような数学のモナド。代数的エフェクトもその流れの中に（このころは）あったはず。そもそも代数的エフェクトの代数とは、操作が（0だか1こ以上）あって、それらに等式制約を課す。それを満たすようなモデルを持つのが代数 (algebra) である、みたいな世界だっと思う。群とか環は代数だけど、体は代数じゃないみたいな話を聞いたことがある。そういうのりの代数として、エフェクトを表現したらモナドの合成みたいなことを考えるときに幸せだ、という主張がことの発端だった気がする。

ここまでは数学とかモデル理論？とかの話によっていて、あまりプログラミング言語っぽい雰囲気がしない。ハンドラとか継続が入ってきた経緯はしらないが、多分、プログラミング言語に代数的エフェクトを入れるにあたって、モナドのbindやreturnみたいなものを定義するように、エフェクトに意味を与える仕組みとしてハンドラが考えられたんじゃないかと思う。このあたりは論文をまじめに読めば分かるはず。これが確か2014年くらいのこと。

2000年くらいだったかから考えられていたエフェクトシステムとの相性に目をつけたからか知らないが、「代数的エフェクトとハンドラ」を取り入れた言語が2014年ころに登場し始める。2017年くらいにでてくる印象がある。 EffやKokaはこのへんな気がする。このあたりで、エフェクトが代数的であることはとくに気にされなくなっていき、エフェクトシステムと例外ハンドラがうまいこと組み合わさる限定継続演算子くらいの気持ちで代数的エフェクトとそのハンドラが捉えられて、やがて代数的ではないことが気になる人々がエフェクトハンドラと呼ぶようになったのではないかと思っている。

限定継続は本当に必要だろうか。もっとやさしい概念を提供するのにとどめるのはいかがだろうか。ワンショット継続とかに限定する言語もあるが、それは正しい方向性だろうか。

僕たちがほしかったものは、local reasoningしやすいエフェクトシステムとそれで健全に管理できる意味論なんじゃないかと思う。エフェクトハンドラはその条件を満たすけど、もっと使い心地のよい意味論があるはずだと思う。

最後の文をメモしたくてこの記事を書いた。それ以外は文脈である。

2023-02-26

Golangをすごく久しぶりに書いた結果、構造体の要素がコピーされることを忘れておりデバッグに時間を溶かした（コピーした構造体のフィールドを書き換えて、コピー元に変化が起きると思い込んでいた）。最近はPythonやTSか、関数型言語ばかり書いていて、Cっぽい構造体の扱いをしていなかったので忘れてしまっていたのだろう。忘れていたけど、CやGoのように構造体の要素をコピーする意味論は好き。直感的というか、明示的にポインタを表現することが好きなのだろうか。