こんにちは､びしょ〜じょです｡
関数型まつりお疲れ様でした
発表あざした､さらっと流す予定だがガッツリ飛ばしたよもやま話
今回はこんなテーマで発表させていただきました｡
会場3つに分かれてましたがたくさん聞きに来てくれた方々がいらっしゃって大変ありがとうございました｡ 一方 俺 は発表直前までスライドを作っており何をしているのか｡小学校の夏休みの宿題かって｡ いい加減にしなさい｡
スライドを直前まで作っていた皆さん……… めっちゃわかります ｡ 何がわかる念という感じですが､分かり手させてもらいます｡次も頑張りましょう｡
さて､今回はLLM言語とりあえず作るンゴw→その後サーベイという流れだったんで､既知の成果をとりいれられてなかった｡ ってかさあLLM向けの言語というのが(ホンマに必要なんですかというのも含め)未開拓なんで､とりあえずこういう話があるんで煙のないところに火を灯すというモチベの発表でした｡
よもやま話は半分妄想で書いてたんだけど喋りたくはあった｡
型システムはリッチすぎるとLLMくん困っちゃうなんてある?
型システムおよび型エラー報告がLLMのコード生成ループの品質を上げるという話をした｡ でもさーw 型システムが強すぎると直せないとか人間もあるやないですか｡ 特にLLMは簡単な四則演算や単語中に含まれる文字を数え上げるといった人間の小学生ならできそうなことが不得意なことが知られている｡ なんで､依存型はLLMちゃんと書けるのか? というのと､エラーを見て修正というのが回せるのか? という疑問が個人的にある｡ 何らかのガードレールとか言語側の工夫があればいけんのかな? というふわっとした考えでした｡
またサブタイピング? もなんだかなあって感じだった｡ Nexus言語は例外の定義をまとめる機能としてexception groupというものがある｡
Scala2時代のADTsの定義っぽい感じですな｡ で処理系がセルフホストなんで､パイプラインごとにexception groupを定義して〜というのをやってほしいんだけど､ナイーブに実装してるところを見てたら全くexception groupを定義しない､または過剰なgroupを作ってしまうなど､人間様がちゃんと指示しないとアカンという感じだった｡ サブタイピングっつうとやや微妙かもしれんが､懸念としては神クラスとかね｡ プログラミングってか､状況に応じて過不足無いものを揃えるというタスクがそもそもLLM不得意そうだ｡ 不相応な言葉遣いやPRの過剰なチェックややることリストと思えば全然基本ができてへんやんけみたいな…おなじみですね｡ ただ､この辺はガイドラインをうまくひけばなんとかなりそうだ｡
とはいえ難しければ全部ムズいってわけでもなさそうだ｡ 文字みたいなトークンをさらに分解して探索というのはムズい一方､エフェクト列や集合から要素を発見するというのはまあまあできてそう｡ それと翻訳が得意なんで､型に状態をうまくエンコードしてステートマシン〜みたいなのはわりと得意分野そうだった｡ 人間が思うナイーブな型の難しさってよりかは､どんなタスクに帰着するのかって方向で見たほうがいいかもしれない｡
ユーザーレベル型エラー改善ブーム
今回のkonnさんの発表でも一瞬でてきたGHC.Type.Errorは型エラーのメッセージを変えられるすごいやつだよ
人間さんは嬉しいんですが､ AIとしてもcannot deduce hogehogehoge.....よりは､例えば次どう直すかが明らかなメッセージのほうがself-repairを回しやすく､読み込み→修正サイクルにかかるトークン消費量も抑えられるだろうと予想できる｡ リフレクションなどではなく型システムの上でやれているのが､Haskellのつええところですね｡ ScalaやRustなども､implicit parameterやtrait解決に失敗するときのカスタムエラーをアノテーションで書き換える機能があるらしい｡
他にも､(一見)強力な型を埋め込むことで送出できる型エラーの情報を豊かにできる｡ 近年流行りのエフェクトシステムの埋め込みがこれですね｡ 例えば､エフェクトシステムがないといえばない1TypeScriptにEffect-TSでエフェクトシステムを構築すると､いわゆる副作用による意図せぬ2エラーが型検査時に検知でき､LLMへのフィードバックが迅速におこなえる｡
プログラム変換の研究をしてたおかげで勘所がなんとなく分かるんで､よかったですね｡
Early return…どうかな
ここはもっと妄想なんで大した話でもない｡
人間と同じであんまりネストするとよくないねという程度｡
その程度ではあるが､巨大な式があり､subexpressionに潜っていき…という関数型ってか式指向な言語よりは､statement listのほうがいわゆる"行ごとに読む"ができてLLMのワーキングメモリーにも優しいのか? と少し思っている｡
で､そうなるとreturnという何気なくつかっているが強力なコントロール抽象は必須ですなあ｡
あるいは式指向の言語にバックポートしてもえんちゃうかなとか少し思ったりする｡
まず継続をaffinelyに､しかも末尾でのみ使えるtail-affine continuation monad(?)を用意し､関数は全てその中で評価され､全てのexpressionがそのmonadに持ち上がっておりいつでもreturnable…とすると意味論的にやれそうか?
でもすでにlinear typesがある言語とかどうなるんでしょうねHaskellとか｡returnをspecial formの式として扱い､return :: \a b. a -> b として return () + linearValue を…最高やな｡
ちなみに: 研究資金
最初とりあえずGeminiを使っていたが即limitひっかかり奴なんでVertex APIを利用したところ3万円くらいが数日で吹っ飛んだんで涙を流しました｡ その後Claude CodeのPro MAXに変更して毎月3万×5ヶ月吹っ飛ぶようになってやや涙が出ました｡ インターネットなどで私を見かけたら優しくしてください｡
ふーん､おもしれぇ発表…
さすがと言わんばかりの発表ばかりでした今年も｡
うおお日本でもOCamlを仕事にできるのかよ〜アサインが自分だけのプロジェクト故にやれてるという話でしたが､さらに拡大してOCamlの国を作っていってほしいですね｡ エフェクトハンドラをガッツリ使ってたりと実装もなかなか実践アドバンスドな内容だった｡
Extensible recordsの実装を､まずナイーブなものからだんだんunsafeを使って部分的になんでもアリにしたかと思えばlinearityで制約付けをおこなうことによりさらにperformantなコードにしていくという高度なだけでなく極めて実用的でワクワクする内容だった｡
弊ブログのファンボの方(!?)が自分の次に発表なさっておりウケた｡ TLA+をコンパイルターゲットとした言語を作っていくと､薄目に見るとTLA+が機械語に見えるというアハ体験があったり､自分の発表の｢言語を作るのは今も時期が良い｣を図らずも実践していたので発表後にメッセージの厚みが出て嬉しいです｡感謝｡
色んな方々と関数型プログラミングのみならず様々な技術トピックについて久々に話しまくれて大変啓発的な時間でした｡
ところでCMです｡株式会社HERPは関数型まつり2026にスポンサーしてました｡ 弊社は現在Haskellなどといった関数型言語を積極採用しておりませんが､関数型パラダイムのような人間の所与でない(諸説)プログラミングテクニックにも大きな関心を持って日々エンジニアリングに取り組んだりプログラミング技法を研鑽している方々をオールウェイズ募集しています｡
また株式会社ビットキー様と協賛でEffect-TSを採用するしないという軸で座談会をするらしいです｡ 基礎的な話を超えて採用するラインや活用方法など､エフェクトシステムのより実務的な内容について話が聞けるんじゃないかと､えー思っております｡ 枠が少ないのでお早めに｡
この記事は業務時間中に書かれました｡
投稿されたコメントはCC BY 4.0ライセンスの下で公開されます｡