Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…
Introductory resources to type theory for language implementers
This post briefly tours resources that helped introduce me to type theory, because I’m frequently asked by others for resources on this subject (even though I never had a formal education in type theory). Specifically, these resources will focus more on how to implement a type checker or type inference algorithm. Also, my post will be biased against books, because I don’t tend to learn well from r
Optics vs Lenses, Operationally
Optics vs Lenses, Operationally (Update: I’ve given a talk about this blog post, which can be found here.) I’ve been thinking a lot about lenses and optics. They’re both abstract gadgets that model various sorts of bidirectional processes. They are found in machine learning, game theory, database systems, and so on. While optics are more general, it’s understood that they’re equivalent to lenses i
圏論的レンズ 最初の一歩： ストリング図を中心に - 檜山正幸のキマイラ飼育記 (はてなBlog)
プログラミングにおいて、レンズ〈lens〉と呼ばれる構造が使われる機会が増えているようです。古典的なレンズが幾つかの方向に一般化されていて、「レンズってなに？」と聞かれても答えにくい状況になっています。 一番簡単な（と僕が思っている）ストレージの例からはじめて、具象レンズを導入し、それらのあいだの関係を調べます。記述と計算にストリング図を使用します。 内容： 元祖レンズ 元祖レンズの圏 元祖レンズ達はホントに圏なのか？ Webサーバーモデル 具象レンズ 元祖レンズと具象レンズ おわりに シリーズ目次（リンク）： 圏論的レンズ 最初の一歩： ストリング図を中心に（この記事） 圏論的レンズ 2： 具象オプティック 圏論的レンズ 訂正と補足： 具象レンズ＝具象オプティック 圏論的レンズ 3： レンズ／オプティックのための描画法 圏論的レンズ 4： テレオロジー圏 圏論的レンズ 5： オプティック
依存型と総称型の圏論的解釈 - 檜山正幸のキマイラ飼育記 (はてなBlog)
去年〈2020年〉の10月に「多相関数と依存型をちゃんと理解しよう」という記事を書いたのですが、基本的な用語を間違っていました。[追記]いや、間違いでもないようです。この記事のコメント欄参照。[/追記] 記号 間違った 呼び方 1 正しい 呼び方 2 別な呼び方 $`\prod`$ 依存積型 依存指数型／依存関数型 パイ型 $`\sum`$ 依存和型 依存積型 シグマ型 $`\prod`$ だから積、$`\sum`$ だから和だろうと安直に思い込んでいて確認しなかったのです。ごめんなさい*1。[追記]「ごめんなさい」は、間違いかどうかの確認もちゃんとしてなかったことです。[/追記] 正しく別な言い方は、$`\prod_{x:X}F(x)`$ は非依存指数型（普通の指数型）の依存版だから依存指数型、$`\sum_{x:X}F(x)`$ は非依存積型（普通の積型）の依存版だから依存積型というネ
The visitor pattern is essentially the same thing as Church encoding
The visitor pattern is essentially the same thing as Church encoding This post explains how the visitor pattern is essentially the same thing as Church encoding (or Böhm-Berarducci encoding). This post also explains how you can usefully employ the visitor pattern / Church encoding / Böhm-Berarducci encoding to expand your programming toolbox. Background Church encoding is named after Alonzo Church
多相関数と依存型をちゃんと理解しよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
比較的最近（今年の9月）、多相関数の記事を書きました。「多相関数」「総称関数」という言葉は知っていても、理解があやふやな人もいそうです。基本的なところを復習しましょう。話を明確にするために、少し圏論を使います。 [さらに追記]下の追記における「間違いです」が間違いだったようです。用語法の流儀が複数あるので、どっちも許容でした。追記内の表は、2つの用語法の対照表になります。[/さらに追記] [追記] この記事内で使っている言葉「依存積型」と「依存和型」は間違いです。申し訳ありません。正しい呼び名は次のとおりです。 記号 間違った 呼び方 1 正しい 呼び方 2 別な呼び方 依存積型 依存指数型／依存関数型 パイ型 依存和型 依存積型 シグマ型 「依存型と総称型の圏論的解釈」の冒頭で釈明(?)説明を書いています。 間違いも記録として残しておく方針なので、お手数ですが、本文内の「依存積型」を「依
多相関数： 補遺 - 檜山正幸のキマイラ飼育記 (はてなBlog)
2020年9月に書いた一連の記事があります。 蒸し返し： アドホック多相 vs パラメトリック多相 多相関数の「パラメトリック性 vs 満足性」 多相関数と型クラス これらは多相関数に関する記事です。昨日の記事も多相関数を扱っています。 多相関数と依存型をちゃんと理解しよう 9月のシリーズ記事と昨日の記事では、多相関数の定義が違います。これは混乱を招くかも知れないので、この記事で追加の説明をしておきます。 内容： 定義はTPO依存 関手性と自然性 多相関数の少し一般的な定義 9月の記事での多相関数 昨日の記事での多相関数 パラメトリック性 定義はTPO依存 同じ言葉を複数の記事で使い、それらの定義がズレていたのですが、僕はそれが悪いとは思っていません。ただ、関連性が強い記事で異なる定義を採用していると混乱を招くリスクがあるので、断り書きはするべきでしょう。 言葉と定義に関する僕のスタンスは
多相関数と型クラス - 檜山正幸のキマイラ飼育記 (はてなBlog)
面白い偶然が起きることがあります。 ごく最近、次の記事を書きました。 2020年9月7日 蒸し返し： アドホック多相 vs パラメトリック多相 2020年9月8日 多相関数の「パラメトリック性 vs 満足性」 そして9月8日と9月9日（昨日）、4年前の記事にkhibinoさんからコメントをいただきました。 2016年9月28日 入門的ではない型クラスの話：Haskellの型クラスがぁ (´^｀;) これらの話題は無関係じゃないんですよね。奇遇。 4年前の記事の背景として、僕には“指標とモデルの圏”の話をしたい動機がありました。それに対して、Haskellの型クラスは用途が制限され過ぎていて気に入らない、といったことを書きました。今思えば、「気に入らない」という感情が先行していて、「君の型クラス vs ワシの型クラス」みたいになっていて、「不毛」とまでは言わないまでも、薄毛な（不毛に近い）議
蒸し返し： アドホック多相 vs パラメトリック多相 - 檜山正幸のキマイラ飼育記 (はてなBlog)
一年ほど前に「「アドホック多相 vs パラメトリック多相」をマジメに考えてはいけない」という記事を書きました。多相性を二種類に分類できるわけではなくて、パラメトリック性（あるいはアドホック性）はしょせん程度問題だ、という話です。「関数定義がひとつで済む多相はパラメトリック多相」なんていう曖昧な定義はあまり意味がありません。 しょせん程度問題だとすると、その“程度”を測って比較したいとは思います。「「アドホック多相 vs パラメトリック多相」をマジメに考えてはいけない // それでもマジメに考えたいのなら」に次のように書きました。 多相関数を自然変換として定式化して、自然変換のあいだの関係をアドホック性を計る尺度に用います。実際、いくつかの方法で自然変換のあいだの順序を定義できます。その順序は、アドホック性の程度とみなせます。 上記の方法でパラメトリック性（アドホック性）を実際に測って比較し
モノイド圏上のテンプレート・オペラッド：具体例とソフトウェア的解釈 - 檜山正幸のキマイラ飼育記 (はてなBlog)
とあるソフトウェア的な動機から、圏論的な代数系を構成してみます。この代数系は、通常の圏〈ordinary category〉とは違い、横結合、縦結合、モノイド積の3つの演算を持ちます。通常の圏は結合だけしか持たないし、モノイド圏は結合とモノイド積しか持ちません。では、モノイド2-圏〈monoidal 2-category〉*1かというと、そうではありません。モノイド二重圏〈monoidal double category〉*2かというと、そうでもありません。 横結合は、複圏〈オペラッド〉の結合であり、縦結合とモノイド積は、複圏の結合と整合する形に定義されます。こういう構造を何と呼ぶのかな？ とりあえず「圏上の複圏〈オペラッド〉」と呼んでおきます（つまんねー呼び名）。複圏とオペラッドは同じものです。複圏とオペラッドを区別する人もいます*3が、僕は同義語として使います。以下、複圏＝オペラッド
なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記
How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ
「アドホック多相 vs パラメトリック多相」をマジメに考えてはいけない - 檜山正幸のキマイラ飼育記 (はてなBlog)
「アドホック多相」、「パラメトリック多相」という言葉は、覚えておけば便利に使えます。が、これらの言葉は、軽率に気分的・雰囲気的に使うものであり、違いや定義をマジメに議論すべきものではありません。 内容： nLabを見てもモンヤリ オーバーロード、多相、総称 多義的名前と識別インデックス アドホック多相は複数の関数定義（なの？） それでもマジメに考えたいのなら nLabを見てもモンヤリ nLab（https://ncatlab.org/nlab/show/HomePage）は、数理科学*1の概念・用語に、できるかぎり圏論的な、できるかぎり厳密な定義を与えようとしているサイトです。そのnLabでも、「多相〈polymorphism〉」のエントリーには、よくある説明しか載ってません。 https://ncatlab.org/nlab/show/polymorphism 多相〈polymorphi
F# vNext は何が "ヤバい" のか: Monadic Programming の新時代 - Qiita
.NET 5.0 が発表されて F# 5.0 の機運も高まってきた今日この頃ですが，型クラスの orphan instances が作れるようになるやつとか，applicative functors 用のシンタックスとか，ジェネリック等価判定・比較の高速化とか，どれも便利で面白そうだけど最近あんまり動きが見られないなあ，と思いながら Candidate for F# vNext を眺めていたところ，そんなアンニュ〜イな気分を根底から吹き飛ばすヤバい機能が実装されつつあることが先日判明し，わたしは今，冷静さを欠いています． その機能とは，これです． [WIP, RFC FS-1072] task and state machine support by dsyme This inserts a heavily modified (but semantically almost complet
さようなら遅延評価 - あどけない話
Haskellがとっつきにくい原因の一つに遅延評価がある。入門書では、無限リストと遅延評価がことさら強調される。しかし、Haskellを業務で使ってみると、遅延評価が煩わしくなってくる。遅延評価なしでもほとんどのことは実現できるし、メモリーの使用量は推測できないし、あまりいいことはない。 Haskellの評価戦略が、他の言語と同じように正格評価だったらよかったのに。 今まで、このようなセリフを何度聞いたか分からない。 そもそも遅延評価が役立つことはあるのだろうか？ ある。お世辞抜きに、少なくとも以下の3つでは本当に役立つ。 リスト(あるいは類似のデータ構造)処理 純粋性に対する暗黙のテスト 効率的なCAS 1.はよいだろう。2.は純粋さを守るために必要だが、コンパイラを開発する人にとって重要なのであり、ユーザには関係ない。3.は、並行プログラミングの奥義である。atomicModifyIO
自作言語の型システムの話 - Qiita
のように変形するだけで動作が変わってしまう. Haskell 方式 言語の中では計算順序を 定めない. 実際にどう動作させるかはコンパイラが決める. 利点は設計が超簡単な上, やろうと思えば合流性4など様々な嬉しい性質をもたせられること. 欠点は実装が超大変で考えることが多いこと. 具体的な実装として GHC を挙げる. GHC では現実世界との相互作用を行なう IO モナドは次のように定義されている5. つまり, RealWorld を状態とした State モナドの一種である. しかし, これは現実世界のモデルとしてはある意味 壊れている. なぜなら, GHC は RealWorld 型の値をユーザに一切触らせないようにすることでプログラム実行の線形性を担保しているからだ. もし触れたとしたら, 値をコピーすることで現実世界を 分裂 させたり, なかったことに したり, 過去に戻って
圏論とSwiftへの応用 / iOSDC Japan 2018
iOSDC Japan 2018 (Sep 2, 2018) https://iosdc.jp/2018/ https://fortee.jp/iosdc-japan-2018/proposal/45b858e0-753c-4387-9210-5837cff6da7a iOSDC Japan 2018 「圏論とSwiftへの応用」発表スライドメモ - Qiita https://qiita.com/inamiy/items/3e0c10d5eaf234b41c3d iOSDC Japan 2018 で発表した「圏論とSwiftへの応用」の補足 - Qiita https://qiita.com/inamiy/items/c4e85f22273e98b8db26 エラッタ： p60. https://twitter.com/inamiy/status/1413894710372888577
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tackling the Awkward Squad for Reactive Programming | Lambda the Ultimate
Amazon.co.jp: 圏論入門 Haskellで計算する具体例から: 雪田修一: 本
The Little Typer
