http://d.hatena.ne.jp/m-hiyama/20130128#c1359767497 : データベース技術者が「これを知らないのは不幸」と思えるので、（可能な範囲で）紹介はしようかな、と。 「これ」とはもちろんスピヴァックの関手的データモデルです。「データベース技術者」つうより、データベースに多少とも関わるすべての人にとって関手的データモデルは福音となる可能性があると思っています。RDBに限らず、現存するほとんどすべてのデータベース的システムに対して、極めて単純で統一的な記述を与えてくれます。データマイグレーションのように、これまでは途方に暮れていたような現実的な問題を鮮やかに解いてくれます。 「これ」を紹介する／説明する価値は十分にあります。僕自身が、すぐにでも実務的に使いたいと思っています。しかし、スピヴァックの論文群を要約したら関手的データモデルの説明になるかという

昨日、デイヴィッド・スピヴァック（David I. Spivak）の圏的情報学／関手的データモデルを紹介しました。スピヴァック理論は、検索を繰り返すうちに見つけたものです。では、どんな動機で何を探していたのでしょうか。そのあたりの経緯と背景を記しておきます。 少し前に「サービスプランニング」という言葉を提案しました。サービスプランニングは、フロントエンド側とバックエンド側に大きく分けることができます。それぞれを（仮に）、インタラクションプランニング、エンティティプランニングと呼んでいます。インタラクションプランニングについては、境界付き有向グラフを水平1-セル、グラフの準同型を2-セルとするモノイド二重圏を使えば形式的モデルができそうだと見当が付きました。 しかし、エンティティプランニングについてはどうも分からない。単純なキーバリューストア（KVS）や、いわゆNoSQLデータベースも考慮に

最近、「おおおー、これは凄い、すんばらしい！」と思ったことがあるので、それについて書きます。 最初に言葉についてのお断り； "categorical"の訳語をどうしようか？ と。片仮名で「カテゴリカル」が無難ですが、漢字で書きたい。「圏論的」が落ち着きがいいようですが、必ずしも「論」の意味を含まないときもあります。そこで、以下、「圏的」を使います。 [追記 date="2013-02-12"]入門的解説を書きました。→「衝撃的なデータベース理論・関手的データモデル 入門」[/追記] スピヴァックと関手的データモデル デイヴィッド・スピヴァック（David I. Spivak, http://math.mit.edu/~dspivak/）は、MITの研究者です。 彼は圏的情報学（categorical informatics）を提唱しています*1。圏的情報学の中心的な概念が関手的データモデル

うちの子供たちの話題といえば、サッカーかお笑いばっかり。最近だと「ワンピース」が少し入るくらい。 ところが、次男が『素数ゼミの謎』という本を読みだして、 素数ゼミの謎 作者: 吉村仁出版社/メーカー: 文藝春秋発売日: 2005/07/12メディア: 単行本購入: 6人 クリック: 85回この商品を含むブログ (66件) を見る 次男：「おにいちゃん、素数って知ってる？」 長男：「あー？ なんか、そんなん習った気もするなー」 次男：「約数って知ってる？」 長男：「なんか、あったような気もするなー」 次男：「あのね、…(説明)…」 それを聞いていて、最近話題の次のアニメーションを思い出して、iPadで見せてあげた。 Animated Factorization Diagrams - Data Pointed 予想よりずっとウケた。次男は「おーっ、素数きた！」「次くるぞ、素数うー」とか騒いでい

IO(入出力）の形式化はけっこう難しい問題です。ここでは、ラベル付き遷移系によるIO（あるいは通信）のモデル化を述べます。XとYがラベル付き遷移系のとき、あるインターフェースを通じてXとYはIO（通信）をします。「Xが出力命令を実行すること」と「Yが入力命令を実行すること」は必ず同時に起こります。2つのラベル付き遷移系において、出力命令と入力命令が同時に実行されることがIO（または通信）ということになります。 内容： ラベル付き遷移系 IOインターフェースを持ったラベル付き遷移系 IOインターフェースによるIO結合 圏論の観点からの課題 ラベル付き遷移系 SとLは集合、δ:S×L→S は写像とします。3つ組 X = (S, L, δ) をラベル付き遷移系といいます。Sは状態空間、Lはラベルの集合、δが遷移写像です。Lの要素は、アクション記号と呼ばれることもあります。遷移写像δは、部分写像や

Catyのメタ巡回的構造、あるいは内省機能を使ったスクリプトを比喩的に僕は「妖精さん」とか「小人さん」とか、詩的(?)に表現してきたわけです。 「妖精」で検索 http://d.hatena.ne.jp/m-hiyama/searchdiary?word=%CD%C5%C0%BA 「小人」で検索 http://d.hatena.ne.jp/m-hiyama/searchdiary?word=%BE%AE%BF%CD 実際に使い始めたら、なぜか呼び名がイヌネコになってしまった。Kuwataさんに先に書かれた。 http://return0.info/note/2012-09.html#id2012-09-13 簡単なテストなので「サルのような賢さは必要ない、イヌかネコにやらせればいい」と言ったので暫定名称「イヌネコテスト」。 10行くらいのスクリプトを2,3個組み合わせればイヌネコテストは出

「CatyScript2.0が完成」で述べたように、予定していたCatyScriptの機能は揃い、今は細かいところを調整しています。CatyScriptの主たる用途は次の2つです。 リクエスト処理を書く。 テストスクリプトを書く。 最近（ここ半年くらい）に実装した機能はテストスクリプト用のものであり、リクエスト処理部分は1年前と同じです。テスト用途だと、「try-catchの双対となる構造」で述べた、環境変数を操作する機能「unclose構文」が必須です。今朝も、unclose構文を手直ししていました。 というわけで、日記らしく今日の午前中やっていた事と、関連する話題を書きます。 内容： Catyの環境変数 環境変数に影響されるコマンドをテストする 簡易シェルを使う テストのためのスクリプト言語 Catyの環境変数 CatyScriptは、構文も使い方もOSのシェルとよく似ています。Cat

言語仕様を決めてから20ヶ月以上…。予定していた構文・機能は全部動くようになりました。バグはまー残っているでしょうし、パフォーマンスもこれから、後から追加した機能で中途半なモノもあります。が、擬似コード／机上コード（処理系なし）として書いたものが今は全て実行できます。 以下、スクリプトコードを羅列するだけ。 まず、2010年11月に机上で書いた無限FizzBuzz。2011年の時点で（「CatyScriptで無限に動き続けるFizzBuzzが書けた」）は代替手段を使って動いていたのですが、今は当初の予定通りの繰り返し制御構造begin/repeatで動きます。 module sample; /** 入力が、引数で指定された数で割り切れるかどうかを判定する */ command dividable [integer] :: integer -> (@True integer | @False

CatyScriptの総称機能がだいぶちゃんとしてきたので、それに絡めて総称ラムダ計算の説明をしておこうかな、と。 ここで言う「総称」は「型変数を含む」という意味です。そして、総称をサポートするとは次のことです。 型変数を含む型表現を扱う。 型変数を含むスクリプトコードを扱う。 総称をサポートする動機は、型定義／型宣言を容易にするためです。型定義／型宣言を（徹底的に）利用する動機は、実行時の安全性をできる限り保証したいからです。人間の間違いを早く発見したいのです。 内容： 総称型の概要 プロファイルの扱い方 総称の式（項）の扱い方 ほんとに大丈夫？ 総称型の概要 α、βなどは型変数を含むかもしれない型表現（type expression）とします*1。こういう表現（式、expression）を型スキームと呼ぶこともあります。Tを型変数として、ΛT.α を、型表現（型スキーム）αの型抽象だと

ツリー構造に対する簡単なテンプレート処理系を考えます。前半ではXMLベースで考えてみます。後半では、そのアイディアを通常のHTMLにマップして、ブラウザ上で動くようにJavaScriptで実装してみます。プルーフ・オブ・コンセプトの目的なので、プログラムは書いただけでろくに動かしてないです。ソースコードはたいした量ではないので最後に貼り付けておきます（修正したら*1、それはどっかに置きます）。 [追記]ソースは https://bitbucket.org/m_hiyama/yet-uncertain に置きました。[/追記] 5年前（2007年）の記事「圏論やモナドが、どうして文書処理やXMLと関係するのですか？」の続きと言えなくもないです。表立ってモナドは出てきませんけど。 目次： まずはXMLで考える 次にHTMLで考える 少しだけ実用性も その他細かいこと ソースコード まずはXML

2009年6月12日に、僕は分散バージョン管理システムMercurialについて短い記事を書いて、そこで次のような言ってます。 実は僕は、分散バージョン管理という発想と仕掛けを最初はまったく理解できず、「エエーッ？なんだそれ」「そんなんでうまくいくのかよ？」とかグダグダ言っていたのですが、いったん使い始めればラクチンラクチン。 要するに、最初は誤解に基づき否定的だったってことね。僕と同じような誤解をする人がいるような気はしたのですが、あまりうまく解説できそうにないので*1： 「四の五の言ってないで、使ってミソ」ってことです。 最近になって、ジョエル・スポルスキ（Joel Spolsky / 青木靖 訳）の「分散バージョン管理で間違いないって、ベイビー」という記事を目にしました。2010年3月17日に書かれた記事です。 なんと、あのジョエル・スポルスキも最初は誤解に基づき否定的だったらしいで

はてなダイアリーは「無料で広告の出ないブログ」として2011年9月まで運営してきましたが、2012年8月1日に広告の表示ポリシー変更させていただきます。目的は、今後も安定したサービスの存続と運営を実現することです。ご理解、ご協力いただければ幸いです。 まー、これはしょうがないか、と。 一時期、僕は有料オプションにしていたのですが、有料オプションの機能をひとつも使わないのに気がついて無料に戻しただけで、有料オプションに抵抗はありません。 広告が邪魔なので、「はてなダイアリープラス」にしようと思って、管理画面から →「有料オプション」→「プラン選択へ」→「ポイントが不足したらクレジットカードで自動引き落とし」をチェック、「自動引き落とし設定へ進む」ボタン→ と進んだら、そっから先に行けない、という。 「自動引き落とし設定」の画面て、「はてなダイアリープラス申し込み」とまったく別な系統の画面で、

「ハイパーメディア・アプリケーションをどう捉えればいいのか」において次のように書きました。 以上のような枠組みを使って状態遷移系を構成しているソフトウェアを、ハイパーメディア・アプリケーションと呼びたいと思います。この枠組みには、直接にはHTTPもURLも登場していません。しかし、実際上はWebシステムになることがほとんどでしょう。 現状において、ハイパーメディア・アプリケーションの大多数はWebシステムとして実現されています。これは否定しがたい事実です。しかし、だからといって「ハイパーメディア・アプリケーションがWebなしでは成立しない」というわけではありません。実際、World Wide Web の登場以前にもローカルで動くデスクトップ・スタイルのハイパーメディア・アプリケーションはありました（たぶん、今でもあるでしょう）。HTTPもURLも、ハイパーメディア・アプリケーションを実現す

「ハイパーリンクは何を繋ぐのか」と「ハイパーリンク設計をサーバーサイド設計に従属させるべきではない」では、既存の用語を使い、ある程度は現実っぽい例を出したりして説明をしました。 このようなスタイルの説明は諸刃の剣です。具体的で分かりやすく感じる反面、夾雑物〈きょうざつぶつ〉をイッパイ含んでいるので誤解と祖語齟齬のタネが満載。誤解と祖語齟齬を減らすには： 既存の用語を使わない。（新しい言葉を造るか、既存用語の意味をリセットしてから使う。） 抽象的な定式化をする。 当然に、これはこれで問題があるわけです。そもそも、聞き慣れない言葉を使い抽象的に語れば、興味を持つ人が誰もいなくなります（正確には、極端に少なくなる）。 まー、自分用のまとめと思って書いておきます。「ハイパーメディア・アプリケーションをどう捉えればいいのか」の後半で抽象的な定式化は書いておいたのですが、もう少し簡略化します。 前提と

[追記] この記事内で、既存の用語の意味をズラシたり拡大解釈して記述したところがあります。「既存の解釈に強く拘らない」というのがひとつの（僕が推奨する）方策ですが、「もう少し、ハイパーメディア・アプリケーションについて」も一緒に読んでくださるのがヨイかと。 [/追記] 昨日の記事「ハイパーリンクは何を繋ぐのか」の続きです。今日も落書きみたいな絵で説明します。昨日使った絵も再掲（流用）します。 僕にとっては、ハイパーリンクがリソース間のリンクだというモデルは受け入れがたいものです（それが昨日の記事の主張）。サーバーは利用者の相手はできません。利用者に機能性や利便性を提供する窓口はWebクライアントです。利用者（それが人間だとして*1）は、画面を見て、アンカーをクリックして次の画面に移り ……、とナビゲートされます。このとき、URLの綴りや発行したHTTPメソッドを意識しているでしょうか？ 「

[追記] この記事内で、既存の用語の意味をズラシたり拡大解釈して記述したところがあります。「既存の解釈に強く拘らない」というのがひとつの（僕が推奨する）方策ですが、「もう少し、ハイパーメディア・アプリケーションについて」も一緒に読んでくださるのがヨイかと。 [/追記] 『RESTful Webサービス』という本はよく参照しましたし、このブログ内でも何度か言及・引用しています。 RESTful Webサービス 作者:Leonard Richardson,Sam Rubyオライリー・ジャパンAmazon この本はたいへん勉強になりました。しかし、多少の違和感が残る、なんか不足を感じる点もあります。この本の著者達、リチャードソン＆ルビーと僕のあいだで、どこかに認識やメンタルモデルの食い違いがあるみたいです。それは（仮にあったとしても）微妙な点なので、なかなか明文化はしにくいものです。 最近また『

一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する

内容 レイフィケーション 形式化された証明と算術プログラミング メタプログラミングと妖精さん達 レイフィケーション 2006年の正月に、「ゲーデルの不完全性定理」に関する記事を何本か続けて書きました。 最初の記事： プログラマのための「ゲーデルの不完全性定理」(1) 3本目の記事である「プログラマのための「ゲーデルの不完全性定理」(3)：自己適用からゲーデル化へ」の「メタレベルも取り込むこと：レイフィケーション」という節に次のような絵を入れています。 この絵は、「記述される対象物」と「その対象物に関する記述」の構造が何段階かのメタ階層を作っている状況において、符号化により「対象と記述」が領域の内部へと埋め込まれる様子です。 この記事で既にレイフィケーションという言葉を使っています。 それから2年後、2008年の正月には、「いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ」と

ツリーに関する用語ですが： 木構造 根ノード 葉ノード この「木」「根」「葉」って、訓読みしますか、音読みしますか？ きこうぞう／もくこうぞう ねのーど／こんのーど はのーど／ようのーど 僕は「き」「ね」「は」だけど、音読みの人もいるみたい。

先ほど書いた記事を受けて、Catyに関する情報不足をナントカする試み。 技術的な背景や設計判断に関して述べることはいくらでもあるのですが、それ以前に、「それはなに？」「なにがうれしい？」さえも説明してない／できてないですね。 「それはなに？」「なにがうれしい？」のイメージがある程度は湧くように、次の2つのキャッチフレーズに絞って、どんなことがどのように出来るかを描き出したいと思います。 ミーティングが終わったら出来ている 作り方を作れる ミーティングが終わったら出来ている 例えば、新しいWebサービスに関してブレーンストーミングをするとか、顧客と業務システムの概要について打ち合わせをするとか、ひとしきりディスカッションをして、だいたいの合意が取れたとしましょう。「こんな感じかなー」というシステムイメージは、おおざっぱなロバストネス図として描けた、と、そうしましょう。 Catyではロバストネ