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)
面白い偶然が起きることがあります。 ごく最近、次の記事を書きました。 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 パラメトリック多相」をマジメに考えてはいけない // それでもマジメに考えたいのなら」に次のように書きました。 多相関数を自然変換として定式化して、自然変換のあいだの関係をアドホック性を計る尺度に用います。実際、いくつかの方法で自然変換のあいだの順序を定義できます。その順序は、アドホック性の程度とみなせます。 上記の方法でパラメトリック性（アドホック性）を実際に測って比較し
なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記
How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ
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
本当はすごい newtype
FIVE社ピザ会で 2018/08/07 に発表した、Haskell の newtype に関する講演です。 GHC 8.6.1 で導入される DerivingVia 言語拡張の説明もあります。 ソースコード：http://github.com/konn/newtype-talk-five
Haskell入門という本を書きました - Pixel Pedals of Tomakomai
Haskell入門 という本を書きました。まだ店頭で買うことはできませんが、amazonでは予約を開始しています。また、電子版も早いうちに出ると聞いているので、そちらもあわせてお求め下さい。技術評論社さんのサイトではサンプルのpdfも読むことができます。 Haskellには すごいH本 というとても良い教科書がすでにありますが、「アプリケーションを作って楽しむ」という観点から書かれた本も欲しいなということを常々感じていました1。すごいH本でHaskellの考え方やプログラムの組み方は学べますが、例えば、プロジェクトを作成して開発を始めるにはどうするかであったり、必要なライブラリをどこから探してどのように自分のプロジェクトへ組み込むのかといった、開発に必要な基本的な事項は自分で学ぶ必要があります。今回執筆した Haskell入門 ではとにかくHaskellでアプリケーションを作ることにフォー
オーバーロードは何故にかくも難しいのか：Haskellの成功と失敗 - 檜山正幸のキマイラ飼育記 (はてなBlog)
名前や記号の多義的使用をオーバーロードと呼びます。オーバーロードとは「曖昧な表現を使う」ことだ、と言ってもいいでしょう。曖昧さを嫌うコンピュータに、曖昧な表現を理解させるのは難しいことです。コンピュータに関する技術や理論以前に、「我々人間は、曖昧な表現をどう使い／どう解決しているのか？」と問う必要があります。 内容： Haskellの場合 -- The・構造の仮定 要素とコレクションの事例 型クラスの境界線は引けるのか 名前・記号の問題は難しい Haskellの場合 -- The・構造の仮定 「入門的ではない型クラスの話：Haskellの型クラスがぁ (´^｀;)」において： 後知恵で言えば、[注：Haskellのオーバーロード・メカニズムは]「悪いお薬」だったと思います。服用するとモノ凄く元気になるが、長期的には心身を蝕んでしまうお薬だったと。 Haskellが実装した記号の乱用はやはり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tackling the Awkward Squad for Reactive Programming | Lambda the Ultimate
Amazon.co.jp: 圏論入門 Haskellで計算する具体例から: 雪田修一: 本
Typeclasses: A Tutorial on Typeclasses in Coq
Polymorphism, subtyping and type inference in MLsub | Lambda the Ultimate
MuniHac 2016: Beautiful folds are practical, too
3 01 A Functional Programmer's Guide to Homotopy Type Theory
