タグ

ブックマーク / m-hiyama.hatenablog.com (6)

  • JavaScriptで説明するオーバーロード解決 - 檜山正幸のキマイラ飼育記 (はてなBlog)

    型クラスの話をしました。 入門的ではない型クラスの話:Haskellの型クラスがぁ (´^`;) オーバーロードは何故にかくも難しいのか:Haskellの成功と失敗 Haskellの型クラスに関わるワークアラウンド Haskellの型クラスは元祖・型クラス*1なんですが、なんか残念な仕様です。整合性が歪んでいる理由は、オーバーロード機能を優先しているからです。その分、構造としての型を記述する機能は犠牲になっています。トレードオフだから仕方ないけど。 ところで、オーバーロードの解決(多義性の解決)って、どうやるんでしょうか? そのメカニズムをJavaScriptのサンプルコードを使って説明します。 なお、「多相とオーバーロードはどう違うか」とかの話は、どうでもいい割に議論すると消耗してバカバカしいので一切触れません。(ちなみに、「並列と並行の違い」なんて議論も時間の無駄。暇つぶし以上の意味は

    JavaScriptで説明するオーバーロード解決 - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • 「技術者/プログラマのためのラムダ計算、論理、圏」ならどう? - 檜山正幸のキマイラ飼育記 (はてなBlog)

    情報があっちこっちに散乱すると、参照の便が悪いので、「技術者/プログラマのためのラムダ計算、論理、圏」に関連することは、このエントリに集約することにします。日付を入れて後ろにドンドン追記していきます。 告知は別なエントリーとしました。 12月20日の「反省とか、まとめとか、資料公開とか」を今日投稿する予定でしたが、作業的に間に合わなかったので、明日以降にします。ごめんなさい。[追記]翌日投稿しました。[/追記] それはそうと、20日にアンケートを書いていただいたのですが、そのなかに、次のようなご意見が含まれていました; 参加者の目的や予備知識を檜山がどのように想定しているかハッキリしないので、参加すべきどうかの判断がしにくい。 あー、なるほど、あんまり気を配っていませんでした。場違いの所に来てしまうのも、それはそれで面白い経験では? とか僕は思うけど、「こういう人に対し、こういうことを伝え

    「技術者/プログラマのためのラムダ計算、論理、圏」ならどう? - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • 技量、理論、方便にまつわる2つの困難 - 檜山正幸のキマイラ飼育記 (はてなBlog)

    技量(スキル、何事かをなしとげる能力)は、“理論”を通しては伝えられないこともあります。もちろん、技量の背後に理論が皆無ってわけではないでしょうが、技量の要素を網羅し、それらを体系的に整理できるかというと、そうとも限りませんよね。仮にロジカルな理論があっても、それが教育/トレーニングにおいて効果的かどうか分かりませんし。 それで、しばしば方便が使われます。例えば、子供に逆上がりを教えるとき「オシリの穴をすぼめる感じ」とか、走るフォームについては「親指で鼻を触るつもりで手を振る」とか。でも、逆上がりとオシリの穴に質的因果関係があるかというと疑問です。ほんとに親指で鼻を触りながら走ったらバカみたいだし。 それでも、「××な感じ」とか「△△のつもりで」とかは、技量を伝えるうえである程度の効果を発揮します。伝達/教示の方法論として許されるものでしょう。つうか、たいていは方便が入り込んでしまいます

    技量、理論、方便にまつわる2つの困難 - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • 下層ほど複雑でリッチ -- 型階層 - 檜山正幸のキマイラ飼育記 (はてなBlog)

    型理論や仕様論は一番好きな話題かもしれないな(背後にあるインスティチューションが好きなんだろうが)。続き物にする気はなかったのだけど、また型理論の話を少し。 昨日のエントリー「もっと型理論」で: "types as specifications/theories"の立場では、サブタイプ/スーパータイプの定義は複雑になります。 問題は、サブタイプ/スーパータイプ概念が、extendsだけで尽きているわけではないことです。まだ説明すべきことが残っているのです。 と書いたけど、extendsだけも分かること/説明できることは随分あります。それと、少し工夫すると、サブタイプ/スーパータイプ概念をextendsだけで説明することもできるのだった(“工夫”の部分があるから、簡単かどうかは別問題だけど)。 「もっと型理論」で説明した意味で「型」「仕様」「extends」「拡張」などの言葉を使うとして、い

    下層ほど複雑でリッチ -- 型階層 - 檜山正幸のキマイラ飼育記 (はてなBlog)
    emosei
    emosei 2008/02/15
  • あの福井市の小学生、その驚くべき発見とは (3) - 檜山正幸のキマイラ飼育記 (はてなBlog)

    (前のエントリーの続きです。) ●面積公式になじむ まずは、 面積 = 内部点の個数 + 周囲の長さ/2 - 1 がどうやら成立しそうだという“感じ”をつかんでおきましょう。(“感じ”だけ。) 内部点が十分にあるようなタイル領域、つまり、細くなくて大きなタイル領域の場合、内部点を勘定して面積の近似値にするのは悪い考えではありません。次の例だと、(僕の勘定が間違ってなければ)内部点が60個、面積は81(タイルが81枚)です。領域をもっと拡大すれば近似の精度は上がります。 円の面積(下の図は1/4だけ描いてあります)の場合、タイル領域で近似し、その内部点を勘定する方法で割といい近似値が得られます*1。 しかし、細い領域の場合は、そもそも内部点がなかったりするので、内部点の個数で面積を近似するわけにはいきません。次の細長い長方形で見てみると、面積の値は長い辺の長さと同じです。眺めていると、面積

    あの福井市の小学生、その驚くべき発見とは (3) - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • DI(依存性注入)を白紙から説明してみる - 檜山正幸のキマイラ飼育記 (はてなBlog)

    「DI(依存性注入)からどこへ行こうか その1」において: DI(依存性注入)については、雑誌や書籍で随分紹介されているので、そういうのを見てください。 こんなこと[注:DI化]して何がうれしいかって? それは、ファウラー先生とかその他エライ人とかエラクない人とかに聞いてください。 と書きましたが、DI(Dependency Injection; 依存性注入)そのものについても説明を試みてみましょう。具体的なサンプルを使うことにします。そのため、サンプルの説明が長くなってしまうのが困ったことですが、まー、単なる能書きよりはサンプルがあったほうがいいでしょ。 内容: サンプルはテンプレート処理系 レクサー(字句処理系) レクサーをインターフェース経由で使う サービス・ロケーター 依存性が消えてない! DI(依存性注入)登場 DIが、かつてIoC(制御の逆転)と呼ばれていた理由 ●サンプルはテ

    DI(依存性注入)を白紙から説明してみる - 檜山正幸のキマイラ飼育記 (はてなBlog)
    emosei
    emosei 2008/01/29
  • 1