デイヴィッド・スピヴァックはデータベース界の革命児か -- 関手的データモデル - 檜山正幸のキマイラ飼育記 (はてなBlog)
最近、「おおおー、これは凄い、すんばらしい！」と思ったことがあるので、それについて書きます。 最初に言葉についてのお断り； "categorical"の訳語をどうしようか？ と。片仮名で「カテゴリカル」が無難ですが、漢字で書きたい。「圏論的」が落ち着きがいいようですが、必ずしも「論」の意味を含まないときもあります。そこで、以下、「圏的」を使います。 [追記 date="2013-02-12"]入門的解説を書きました。→「衝撃的なデータベース理論・関手的データモデル 入門」[/追記] スピヴァックと関手的データモデル デイヴィッド・スピヴァック（David I. Spivak, http://math.mit.edu/~dspivak/）は、MITの研究者です。 彼は圏的情報学（categorical informatics）を提唱しています*1。圏的情報学の中心的な概念が関手的データモデル
最近のブラウザは、ネイティブJSONサポートがあるんだね - 檜山正幸のキマイラ飼育記 (はてなBlog)
JSONをデータとしたAjax通信の実験をしようと思ったのですが、Ajax通信以外に何もやらないので、Ajaxのみのライブラリを探してみました。 すこし古め（2010年11月）の情報ですが次の記事を見つけました。 Ajax(XHR)如きにjQueryは重過ぎ!!な時の軽量ライブラリ集 ここで紹介されている microajax - Tiny AJAX library はほんとに小さいライブラリです。それを僕が膨らませてしまったのが下に貼り付けたソースです。若干読みやすくしたのと、ネイティブJSONサポートを使ってみたところが変更点です。 JavaScriptで書かれたJSON処理ライブラリがいくつかありますが、今ではブラウ自身が JSON.parse(text) と JSON.stringify(data) をサポートしています。古いブラウザへの考慮が不要なら、ネイティブJSONを使うとスッ
フローチャートをめぐる迷信と妄言と愚昧 - 檜山正幸のキマイラ飼育記 (はてなBlog)
2011年12月20日の記事で： [フローチャートについて書くのは] 僕にとっては定期ポストみたいなものです。年に一,二度はこのことを言っておきたい、みたいな。 と書きました。それから半年たってないのですが、なんかまたフローチャート・ネタをやりたくなりましたね。 そう思い立ったのは； 「フローチャートを復権させよう -- 2020年代のプログラミングへ」のブックマークに、羽生章洋(id:habuakihiro)さんが次のコメントを残しておりまして、 昔フローチャートについて講演したりポジティブなことを書いたりしたら偉い叩かれたなあ。似たケースにJavaScriptの記事書いたときも叩かれてその後gmail+ajaxブームが来たら一転したり。みんな原理原則より流行が好き。 いまさらながら当時の情報を探して読んでみたのですよ。2006年夏、羽生さんの講演について大森敏行記者が書いた記事が残って
大域名前空間を汚しまくっているJavaScriptライブラリを単一名前空間に押し込める方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
随分と以前に書いたJavaScriptのライブラリがありまして、それが大域名前空間を汚しまくっているわけです。当時はそれでも不都合はなかったし、罪悪感(?)もありませんでした。ですが、今見ると「これはないよなー」と。さらに悪いことに、実際に名前の衝突を起こしてしまったのです。 それで、このライブラリが定義する名前をすべて単一の名前空間に押し込めるように書き換えようと思ったのですが、けっこうな量があります。ウーン… めんどくさいなー、いじりたくないなー、と。変更は最小限にして、単一の名前空間の下に「名前のお引っ越し」をしたい。 ものすごく安直な方法でなんとかなりました。こんなんでいいんかいな？ とも思います*1が、まー、出来たは出来たのでやり方を紹介します。もっとうまい方法があれば教えてください。 例題 次はサンプルです。僕が昔書いたライブラリも、このサンプルと似たような書き方をしてます。_
なぜ僕は操作的意味論に傾いたか - 檜山正幸のキマイラ飼育記 (はてなBlog)
今日の昼前に投稿した記事「評価シーケントの論理計算と操作的意味論」において、操作的意味論に基づいた意味記述方式を提案してます。これは、CatyScript2.0を記述する目的で考えたのですが、なぜ操作的意味論を採用したかを書いておきます。 CatyScriptの意味を表示的（denotational）に記述することも出来なくはないでしょう。しかし、簡単な仮想機械を想定して操作的（operational）に書くほうが次の点で有利なように感じました。 処理系実装の方針を立てやすい。 コンパイル方式のヒントになる。 スコープ／可視性の定義が容易。 細かい振る舞いまで記述できる。 細かい振る舞いが書けるということは、煩雑で抽象度が低いという欠点でもあります。しかし、表示的には書きにくいことがあるとき、自然言語で注記するくらいなら操作的に書いたほうがマシだと思います。 操作的な記述をシーケント計算と
抽象的と具体的、自分の日本語が変で困った - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、「抽象的」と「具体的」という言葉を必ずしも反対語として使っていません。意図的にそうしているわけじゃないのですが、気がつくとそうなんです。どういう事かというと、僕の個人的な言葉使いでは： 抽象的の否定や反対語が具体的（具象的）ではない。 具体的の否定や反対語が抽象的ではない。 したがって、抽象的かつ具体的なものがあってもいい。 「あってもいい」というより、僕は「抽象的かつ具体的なもの」が好きなのです。日本語の使い方として変なので困ったなー、と思っています。なんかいい言葉使いがあったら教えて欲しいのですが、事情を少し書いておきます。 例えば、僕が話題にする圏やモナドは抽象的か？ というと、まー抽象的なんでしょう。抽象的だからこそ力がある、とも言えます。しかし、圏やモナドを持ち出したら“具体的じゃない”とか“具体性に欠ける”ってことにはなりません、僕の言葉使いでは。むしろ、ふにゃふにゃモヤ
フローチャートを復権させよう -- 2020年代のプログラミングへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「悟りやヒラメキがほんとに大キライだ 」という記事を書いた背景には、ユースケースの「主／副シナリオ」、「<<extend>>, <<include>>」とかの概念にウンザリしたことがあります。あれから後も、この件がどうも気にかかっていて、『ユースケースの適用：実践ガイド』（asin:4894711869）という本を恵比寿の有隣堂で見つけてすぐ購入しました。 この本には、僕が疑問に思っていた点が説明してあって、理解に役立ちました。ある程度は理解できた事と、その内容に賛同するかどうかは別問題でして、（理解してもなお）納得のいかない点は多々あります。その話は、まーいずれするかも。 ところで、この『ユースケースの適用：実践ガイド』の第5章「ユースケースを図で表現する」の冒頭に次のような文があります。 これまで、長い時間をかけてユースケースのテキストを書いてきました。しかし、ことわざにもあるとおり、
JavaScriptでnewが不要なコンストラクタ - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日の「JavaScriptでシーケンシャルな作業をゆっくりと行う方法」で自作のtaskman.jsを紹介しましたが、最初は、JSDeferred（http://cho45.stfuawsc.com/jsdeferred/doc/intro.html）を使おうかと思ってました。やることを限定すれば関数2つで済んでしまうので、気まぐれでtaskman.jsを書いたのですが、もっと色々やりたいならJSDeferredのようなチャンとしたライブラリがお勧めです。 ところで、JSDeferredのソースに次の1行がありました。 function Deferred () { return (this instanceof Deferred) ? this.init() : new Deferred() } 最初、「ん？ なんだこれ」と思ったのですが、しばらく眺めて「オオオーッ、これはいい！」と叫んで
順序付き関係の圏 - 檜山正幸のキマイラ飼育記 (はてなBlog)
型の計算をしているうちに、“順序付き関係の圏”とでも呼ぶべきものに出会いました。Ordered Relations でORelと書くことにします。集合の圏Set、順序集合の圏Ord、関係の圏Relと、圏ORelのあいだには次のような関係があります。 Set -- Gr --> Rel | | Disc Disc | | v v Ord - OGr --> ORel 矢印はいずれも関手です。Grはグラフ化、OGrは順序付きのグラフ化（グラフの順序的閉包を取る）、縦方向の矢印は集合に離散順序を入れる関手です。2本の縦矢印は違う関手を表しますが、似ているので同じ名前Discをラベルにしています。これらの圏と関手について説明します。プロ関手との関係とかにも触れますが、とても急ぎ足です。 内容： 関係の圏の素早い復習 順序集合の圏の素早い復習 反対順序と直積 上方閉集合と下方閉集合 順序付き関係の圏
悟りやヒラメキがほんとに大キライだ - 檜山正幸のキマイラ飼育記 (はてなBlog)
ソフトウェアの設計は僕の仕事の一部なんだけど、モデリングとか高水準の設計手法とかに興味がない。いや、正確に言うと、そのテの手法とか流儀とかには、僕を苛立たせるものがあって、精神衛生のために避けている傾向があるってことです。 参照の必要があって、モデリングや設計手法の情報をWebや書籍で調べると、たいていはイライラしてきて最後まで読みきれず、腹を立てて放り投げてしまいますね。 なんでか？と言うと、僕が嫌いな「悟り」や「ヒラメキ」の要素が含まれることがあるからです。「最初は意味不明でも、我慢しているとある日わかってしまう」ような体験 -- それを想定しているような説明がほんとに嫌いなんです。「ある日わかってしまう」経験は僕にもあります。でも、それは僕の能力が足りないからです。つまり、本来なら分かるはずのものが「理解力の不足ゆえに分かってなかった」という事実があるだけ、「遅れて理解した」という事
Wiki処理系を作る前に知るべきこと／考えるべきこと - 檜山正幸のキマイラ飼育記 (はてなBlog)
Wiki構文（Wiki記法のルール）は山にようにイッパイあります。 「新たにもう1つ構文を付け加えても別にいいだろう」と考えるか、「これ以上新しい構文を増やしてはいけない」と考えるかは人によるでしょう。僕は、「集約・統合してWiki構文を減らすべきだ」と考えています。それで、標準的なWiki構文としてWikiCreole 1.0を採用し、KuwataさんがCreoleパーザーを実装しています。 ところが、WikiCreoleの構文記述が曖昧過ぎてサッパリわからんのです。Kuwataさんもイライラしている様子。このような状況はWikiCreoleに限りません。たいていのWiki構文の記述はイイカゲンです -- いやっ、仕様書があるだけでマシなのです。イイカゲンな仕様に適合した（conformantな）処理系を作れと言われてもそりゃ困りますわな。 WikiCreole仕様の曖昧さは以前にも話題
1年たって、手書きから自動描画へ - 檜山正幸のキマイラ飼育記 (はてなBlog)
今から1年と少し前に「Webサービスを設計するための単純明快な方法」という記事を書きました。そのなかで次のような手書きの絵を出しました。 「Webサービスの設計：Webの状態遷移図の描き方」では、図に関する説明を追加しました。 上の図で番号が付けられている各部の名称は次のとおりです。 トリガー リクエスト辺 アクションノード レスポンス辺 状態ノード このような絵を、僕はもう手書きしなくて済みそうです。状態、トリガー、アクションなどの繋がり具合を記述するファイルから、状態遷移グラフを生成できるようになりました（Graphvizを使っています）。 このグラフのもとになるデータは単に図のための記述ではありません。それ自体がWebアプリケーションの設定ファイルになっています。“設定”というより、Webアプリケーション“そのもの”だ、と言ってもいいかもしれません。なぜなら、Webアプリケーションの
檜山正幸のキマイラ飼育記 - 論理を身に付けるには
論理（学）の話を少し。ここでいう論理（ロジック）は、記号論理学、形式的論理学、数学的論理学などと呼ばれる分野のことです。この意味での論理を学んだからといって、通常の（世間的な）意味での“論理的な人”になれることはまったく保証できません。 こころがまえ五箇条 さて、記号論理学を受け入れる気持ちになるには、とりあえず、次のようなことを心にとめるべきかと。 無意味な記号の無意味な操作を認める。 しかし、記号と操作に意味を与えられることも認める。 記号／操作の意味付与（解釈）には、なんらかの“世界”が必要なことを知る。 （現実の、または架空の）とある“世界”で、なにごとかが“正しい”かどうかの判断（judgement）ができると信じる。 意味・解釈を根拠とした記号操作も、意味を剥＜は＞ぎ取って「無意味な記号の無意味な操作」だとみなせることを知る。 機械的な記号操作 無意味な記号の無意味な操作は味気
『抽象によるソフトウェア設計』とAlloy、第一印象報告 - 檜山正幸のキマイラ飼育記 (はてなBlog)
『抽象によるソフトウェア設計 -- Alloyではじめる形式手法』の献本をいただきました*1。書店に並ぶ前、7月9日に届きました。訳者のみなさん、ありがとうございます。 抽象によるソフトウェア設計−Alloyではじめる形式手法− 作者: Daniel Jackson,中島震,今井健男,酒井政裕,遠藤侑介,片岡欣夫出版社/メーカー: オーム社発売日: 2011/07/15メディア: 単行本（ソフトカバー）購入: 8人 クリック: 274回この商品を含むブログ (35件) を見る 「序文」、「監訳者序文」、「訳者あとがき」、そして第1章「はじめに」あたりを読んで感心しておりました。第1章はわずか4ページですが、素晴らしい、実にいいことが書いてあります。それで僕はスッカリ満足して（残りは読まないままで ^^;）いました。 金曜日（7月15日）にid:bonotakさんに、「アンタ、いくらなんでも
XPathの構文を割と具体的にまとめておく - 檜山正幸のキマイラ飼育記 (はてなBlog)
「XPathの要点を少し抽象的にまとめておく」より： 以上のような「概念的にどんなものか」が分かれば、あとは構文を調べながらなんとか使えるでしょ。 というわけで、構文を調べたりしたのでまとめておきます。 XPathの正式な構文は、まーまー整合的なんですが、書くのがとても面倒。それで省略形を使うことになります。省略形は書くのにとても便利ですが、意味がわかりにくくなります。そんなわけで、XPathを使うときは、正式な記法と省略形のあいだの翻訳に慣れておくとよいようです。 XPathの正式な構文 XPathロケーションステップの正式な構文は、軸、ノードテスト、述語（predicate）という3つの部分からなり、次の形です。 軸::ノードテスト[述語] 述語は条件式です。ノードテストも条件式ですが、頻繁に使う条件をノードテストにしたって感じですね。述語が不要なら、正式記法であってもブラケットごと省
その後の秘密基地 - 檜山正幸のキマイラ飼育記 (はてなBlog)
前の話： 増員計画の失敗 父親：「まだ秘密基地は作っているの」 次男：「作っているよ。一番新しいのは山手通り」 父親：「えー、山手通りに隠れるような所はないでしょ」 次男：「うん、みんなからまる見え」 父親：「それじゃ、秘密じゃねーよ」 次男：「だいたい、山手通りだと場所がないんだよ」 父親：「じゃ、どうしてんだよ？」 次男：「道路のわきに板が置いてあるんだよ、基地の目印に」 父親：「板一枚、そ、それだけ？」 次男：「うん」 父親：「ショボイなー、それ」 次男：「しょうがないんだよ、たくさん作らなきゃならないから」 父親：「その秘密基地、形骸化してるな」 次男：「ケイガイカ？ おとうさん、わざと難しいこと言ってるね」 父親：「あー、わざと言ってるよ。もっと言うとね、粗製濫造、本末転倒だ」
トレース付き対称モノイド圏とはこんなモノ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「絵算で見る「カザネスク／ステファネスク／ハイランド／長谷川の定理」」にて： トレースについて今は説明しませんが、次のような公理で特徴付けられます。 バニッシング（アクション性） タイトニング（自然性） スライディング スーパーポージング（強度性*1） ヤンキング たまたま次の論文で、トレース付き対称モノイド圏の絵を見つけたので、少し説明します。 Title: Diagrammatic Representations in Domain Specific Languages (2001) Author: Konstantinos Tourlas URL: http://www.lfcs.inf.ed.ac.uk/reports/02/ECS-LFCS-02-426/ECS-LFCS-02-426.ps pages: 158 僕が常々面白がっている話題の割には言及が少ないな＞トレース付き圏
はじめての圏論 第8歩：順序集合の埋め込み表現 - 檜山正幸のキマイラ飼育記 (はてなBlog)
新年の挨拶なんてのは省略。「はじめての圏論」シリーズいってみよう。 なんか、米田の補題（The Yoneda Lemma）について書きたくなった（単に気まぐれだけどね）。が、具体的に手でいじれる事例が欲しい。そこで、次のような方針にしました。 事例としてはやせた圏（thin categories）を使う。 “やせた圏＝プレ順序集合”に関して、米田の補題に相当する結果を先に示しておく。 この具体例を適宜参照しながら、一般的な米田の補題を説明する。 というわけで、今回はやせた圏（特に“とてもやせた圏＝順序集合”）の性質を多少詳しめに調べます。これは、米田の補題に向けての助走路となります。なお、やせた圏について「第3歩：極端な圏達」で紹介しているので、前もって読んでおくが吉。 内容： 記号と用語の復習 やせた圏のハッセ図 順序集合と上方集合／下方集合 典型的な順序集合 順序集合の表現 プレ順序集
不快感をもよおす衒学的文章とはどんなものか - 檜山正幸のキマイラ飼育記 (はてなBlog)
http://d.hatena.ne.jp/m-hiyama/20100225#c1267490716 ： 何人かがご指摘なさっているように「郡司さんは真剣なんだ／真面目なんだ」を否定する気は全然ありません（そうなんだろうと思っています）。であるなら、どうしてデタラメを書くんでしょうか？ デタラメという表現方法でしか真意を語れないのでしょうか？ -- 僕はそんなことはないと思います。痒いところに手が届かないような語り口でも、デタラメよりは効率的なコミュニケーション方法はあるはず。 以前、bonotakeさんもおっしゃっていた事ですが、「それで誰が幸せになるのか？」です。郡司さんになんらかの「真意」があるにしても、晦渋で難解、デタラメな用語法・推論では「真意」の理解者を減らすだけだろうし、「こけおどしの装飾」との評価もいたしかたないでしょう。 と、なんか「親切な忠告」風なことを書いてしまいま
型チェックと型推論 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「ソフトウェアの意味論は何のため／誰のために必要か」において、意味論（モデル）は精神衛生上の理由で必要だ、みたいなことを書きました。そればっかり強調すると、また変に誤解されかねないので、技術的／実用的な観点からの意味論の必要性についても敷衍＜ふえん＞しておきます。 意味論と対＜つい＞になる言葉は構文論です。構文の議論をちゃんとやろうとすると、意味論が必要です。以下、Catyについて話しますが、Catyでは型システムの役割が大きいので、型システムの構文論／意味論を話題とします。 内容： 型チェックがなぜ必要か 型推論と静的な型チェック 型宣言を書く動機付け 型推論演繹系と意味論 実行時チェックを併用するわけ 型チェックがなぜ必要か Catyでは、到るところで型チェックを行います。「どうして型チェックをするのか」というと、まず第一の理由は、人間の間違い（ミス）とそれに起因するトラブルを少なくす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
