3値または4値の論理の使いどころ - 檜山正幸のキマイラ飼育記 (はてなBlog)
論理に出てくる述語（predicate）をコンピュータの文脈で考えると、適当なデータ領域Dの上で定義され、真偽値（trueまたはfalse）を戻り値とする関数になります。述語を数学的な関数と捉えるなら、その論理計算は古典論理と同じようにできます。しかし、コンピュータによる計算だと、なかなか古典論理と同じにはいきません。 部分的にしか定義されない述語の計算 コンピュータのなかの関数はプログラムにより定義されます。プログラムにより定義された関数の宿命として、無限走行したり例外が発生したりで結果が得られないことがあります。つまり、述語の関数 D→{true, false} は部分関数となります。 部分（かもしれない）関数 f:D→{true, false} があるとき、未定義な部分では f(x) = ⊥ と考えます。⊥ は架空の値でボトムと呼ばれます。「f(x) = ⊥」という言明は、xのところ
もう一度、ちゃんとJSON入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様
はじめての圏論 その第1歩：しりとりの圏 - 檜山正幸のキマイラ飼育記
全体目次： 第1歩：しりとりの圏 （このエントリー） 第2歩：行列の圏 第3歩：極端な圏達 第4歩：部分圏 第5歩：変換キューの圏 第6歩：有限変換キューと半圏 第7歩：アミダの圏 第8歩：順序集合の埋め込み表現 第9歩：基本に戻って、圏論感覚を養うハナシとか 付録／番外など： 中間付録A：絵を描いてみた 番外：同期／非同期の結合 中間付録B：アミダとブレイド 番外：米田の補題に向けてのオシャベリ 一部のプログラミング言語の背景として、圏論（カテゴリー論）が使われたりするせいか、以前に比べれば多少は圏論に興味を持つ人が増えたような気がしなくもないような。でも、安直な入門的文書はあまり見かけないですね。もちろん、シッカリした教科書や論説はあるんですが、どうもシッカリし過ぎているような。例えば、圏の例として「コンパクト・ハウスドルフ空間と連続写像の圏」とか言われてもねぇ（この例はいい例なんです
bitbucketはもう信用する気になれない - 檜山正幸のキマイラ飼育記 (はてなBlog)
bitbucketは、分散バージョン管理システムのリポジトリと関連機能をホスティングしているサービス。Catyの開発にはずっとbitbucketを使ってきた。細かい不満はあるものの、「これはダメだ」というほどの問題点は感じていなかった。だが、最近の変更は酷い。それについては、既にKuwataさんが書いている。 http://return0.info/note/2012-10.html#id2012-10-10 http://return0.info/note/2012-10.html#id2012-10-19 Wikiの記法が、WikiCreoleからMarkdownに変わったのだが、互換性への配慮が一切されてない。ユーザーが今まで貯めこんできたデータが壊れる事態もヤムナシという判断らしいが、ヒド過ぎる。具体的に言うと、過去にWikiCreole記法で書いた（イシュートラッカーの）イシュー
JSONの可能性がグンと拡がるぞ！ JSONスキーマ - 檜山正幸のキマイラ飼育記 (はてなBlog)
JSON（http://www.json.org/）データはけっこうよく使うので、何度か話題にしたことがあります（例えば「もう一度、ちゃんとJSON入門」）。でも、JSONには型情報／メタ情報が付けられないのがとても不満で、JSON改なんてもんを考えたこともありました。（後でXIONに改名） JSONデータに対するスキーマ定義の仕様がかたまりつつあることを、ごく最近になって知りました。 http://json-schema.org/ JSON本体はRFC 4627になっていますが、JSONスキーマの標準化のステータスは、あまりハッキリとは分かりません（僕には）。http://groups.google.com/group/json-schema?pli=1 を覗き見した感じでは、現状ワーキングドラフトという位置付けらしいです。 なかなか面白いし役に立ちそうなので紹介します。ただし、僕にとっ
檜山正幸のキマイラ飼育記 - プログラマのためのJavaScript (0)
ジジイの手習いで、JavaScriptを勉強中でございます。その動機は「結局、ブラウザベースRIAかよ」のようなこと。非ブラウザベースのリッチクライアントへの期待を失ってしまったんですね。短期的・現実的な策としては、Ajax的な手法によるRIAなのかなぁ、という気分。ただし、「短期的」が“1年”と“5年”ではえらい違いです。今のところ僕には、「短期的」の実際の期間はわかりません。 僕のJavaScript調査の結果は、「初心者でも使えてプログラマでも困惑するJavaScript 」などに書きました。これらの続きとして、「プログラマのためのJavaScript (*)」というタイトルで書こうかと予定してます。あくまで予定、気まぐれでモノグサな僕のことだから、…… “プログラマのための”というのは、C, C++, Java, C#など“普通の”プログラミング言語にある程度慣れていることを前提に
論理的であるかのごとくに装って、根拠のないイチャモンをつける 13+2 の方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと挑発（コレの最後）してみたけど、どうせ反応はないだろな。しらけてしまわないうちに自分でテンション上げて解説を書いてみました。 内容： 前がき 本編 定義の違いを真偽の議論にすり替える 言ってもない事を否定して印象操作をする 傾向や量に関する主張に、勝手に全称限量子を付けてしまう とある階層でなされた主張を、別な階層で否定する 権威や前例に訴える 権威や前例に訴える 別バージョン 論点ズラシ、意図・論点の曲解 論点ズラシ、意図・論点の曲解 感情バージョン 意味もなく自分の経験や知識を強調 問題点を他の事情により帳消しにする 意味不明でもいいから難しそうなことを言ってみる 普通とは異なる解釈を持ち出す 反論されたときは最小コストでごまかす 余計なお世話な悪口も辞さない 言い張る 後がき 前がき すぐあとに続く「本編」では、ホントに「根拠のないイチャモンをつける方法」、もう少し正確に言う
Erlangの型記法（Type Notation） - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記 date="翌日"]帰る間際にあわててアップロードして、いくつか細かいミスがあったので修正しました。[/追記] Erlangは静的な型チェックをまったくしないプログラミング言語ですが、データにはもちろん型（タイプ）があります。コンパイラはデータ型を気にしなくても、ドキュメンテーションではデータ型の記述が重要です。そこで、ドキュメンテーションのため（ひょっとすると、将来の型システム拡張のため？）に、型を記述する記法が使用されています。 Erlangの型記法は慣習的（conventional）なものなので、だいぶ“ゆらぎ”や“不整合”があるのですが、なるべく合理的な線を探りながら説明してみます。ネタ元は、アームストロングの本"Programming Erlang"の付録Aです。この型記法は、Erlangのmanページや一部の開発ツール*1で使用されています。 型の名前 型の名前は小文字
EmacsでJavaScriptソースを快適に読むために：js2-modeとエグズーベラントCtags - 檜山正幸のキマイラ飼育記 (はてなBlog)
「横道にそれすぎ」に書いた事情で、EmacsでJavaScriptソースコードを読む環境を少し整えようかと。 次の2つのツールを導入してみよう、っと。 js2-mode： http://code.google.com/p/js2-mode/ エグズーベラント（EXUBERANT）Ctags： http://ctags.sourceforge.net/ 内容： より良いEmacs JavaScriptモード -- js2-mode 強烈なタグファイル作成ツール -- エグズーベラントCtags エグズーベラントCtagsを調べてみる EmacsでJavaScriptソースを読む ●より良いEmacs JavaScriptモード -- js2-mode 以前（2006年7月）、ひげぽんさんの記事で、「ecmascript-mode.el ＜ javascript.el みたいだ」と書いてあった
Back to XML (2) - 檜山正幸のキマイラ飼育記 (はてなBlog)
過去に蓄積されたXML技術のどのあたりを檜山が面白いと感じ、再評価・再発見してみたいと望んでいるのか？ それは、また次ね。 前回、こんな文面で終わってしまったので、「それはどこ？」の話をせざるを得ないでしょうね。だから実際しますけれども、論理的な順序から言うと、その前に話しておくべきことがあるのだった。まー、いきがかりだから論理的順序は無視します。したがって、解説としては若干不親切で、幾分錯綜した感じになりそう。致し方ない。 話は前世紀まで遡＜さかのぼ＞るのだが 「過去に蓄積されたXML技術」という言葉は、なにか特定単一の仕様を意味してるわけではありません。いまだ脈ありと僕が思っているものがいくつかあるわけです。そのなかで第一の候補を挙げれば、… … XLinkです。 XLinkは、XML 1.0仕様とほぼ同じ時期から構想されているものです。XMLの初期のドラフトでは、XLink仕様がXM
Back to XML - 檜山正幸のキマイラ飼育記 (はてなBlog)
一時期、ある狭い範囲内では「XMLの檜山さん」だったわけですが、ここんところ、XMLにはご無沙汰で、事実上何もしてない。個人的な事情もあるけれど、期待したほどには XML everywhere、everything in XML という状況にはならないし、XML技術が変に矮小化されたり、トンチンカンな使い方をされたり、不毛な議論があったりと、デスパレートな気分にもなりますわな。 じゃ、XMLにまったく興味を失ったかというと、それはないです。不本意に別れた昔の彼女に未練があるくらいの感情は残っています。あわよくば復縁したい、とね。そうは思っていても、行き違いや誤解や不運とかが重なってなかなか復縁できなかった、とそんな感じでしたね。 最近になって、XMLに戻れるかな、もう一度なんらかの形でコミットしようか、と思いはじめました。その事情を話す前に、XML技術がどう使えるか、どう使うべきかを述べて
檜山正幸のキマイラ飼育記 - 世界で一番か二番くらいにやさしい「モナド入門」
気まぐれと偶然となりゆきで、ここ2,3回はモナドを話題にしました。googleで「モナド」を引いてザッと眺めると、「モナドはむずかしいー」とか「モナドで挫折した」みたいな雰囲気が感じられて、説明芸人の血が少し騒ぎましたね。「なら、予備知識ゼロでモナドの説明をしてやろうじゃねーか」と。 タイトルはだいぶ煽っちゃった…… けど、ハッタリじゃないつもり…… けど、実際はどうかな？ ※印刷のときはサイドバーが消えます。 内容： とりあえず、あたりさわりなくモナドの来歴を紹介する こんな課題を考えてみよう：副作用付き計算 カウントアップする関数達 カウントアップしたい意志を戻り値で伝える それでは、いったい誰がカウントアップをするのだ 関数の引数の型をCountup型にまで拡張する そして、これがモナドだ とりあえず、あたりさわりなくモナドの来歴を紹介する 今からここで説明する「モナド（monad）
もっともお手軽な対話的JavaScript処理系 - 檜山正幸のキマイラ飼育記 (はてなBlog)
nak2kさんが、次のエントリーでWindows環境での対話的JavaScript処理系を紹介しています。 Win版インタラクティブJavaScript - nak2kのメモ帳 InteractiveJS その２ - nak2kのメモ帳 これは、「JavaScriptによるJavaScriptインタプリタ」という感じのもの。このnak2kさんのエントリから参照されている SpiderMonkey で JavaScript のインタラクティブシェル - bkブログ には次のように書いてあります。 インタラクティブシェルは JavaScript の基本的な動作を理解するのに非常に役立つと思います。 そう思います。僕自身はRhinoを使ってます。で、選択肢としては： SpiderMonkey (the Mozilla's C implementation of JavaScript)の対話的処理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
