オープンクラスとはダイナミックスコープだという話。その２。 - 言語ゲーム
http://d.hatena.ne.jp/propella/20100825/p1 の続きです。長くなったので最初にまとめを書きます。 オープンクラスとダイナミックスコープは関係無かった。 オーバーライドとダイナミックスコープも関係なかった。 新しい疑問が生まれた。クロージャをオーバーライドするにはどうすれば良いだろうか。 前回オープンクラスがダイナミックスコープに似てるという話を書きました。しかし「クロージャの中で参照される変数がダイナミックスコープだったら」の辺りでなんか変だなと思ったんだけど、折角沢山ブックマークが付いたので、面白いからそのままにしておきます。 という事でテーマを少し修正。まず、オープンクラスに限らず継承も含めてメンバをオーバーライド出来る仕組み全体を考えます。そして、レキシカルスコープのある言語の変数名解決法と、継承やオープンクラスのある言語のメンバ名解決法、そし
Alloy - 言語ゲーム
Alloy というのが面白いらしいのでやってみた。ちなみに、これを書いている時点で Alloy というのが何なのか説明を読んでも人に聞いても全くさっぱり分かってないですが、とりあえず触ってみます。 alloy の構成 alloy は他のシステムに依存していて、次のような構造になっています。ダウンロードページからまとめてとってこれます。 alloy 本体 : java で書かれた言語と本体 Kodkod : java で書かれた SAT ソルバ SAT4J : kodkod のバックエンド? SAT ソルバと Kodkod SAT というのはある問題を表現する手法で、日本語では 充足可能性問題 と言うそうです。ようするに AND OR NOT を使って表現出来る範囲の問題という事なのかな？ Kodkod というのは、これを使って、first order logic、transitive cl
最近の開発の事 - 言語ゲーム
昨日は慣れない英語で慣れない Erlang と慣れない swf の事を書いて、寝不足で気分はどん底だ。でも趣味でやってるだけなので誰も恨めない。仕事では Pepsi という言語のための Socket インタフェースを書いている。これは結構面白く、IPv6 になって C の API が新しくなり、私がウェブの仕事をしていた頃より良くなっている。特に IP アドレスが隠蔽されているのは良い。 これをやろうと思った動機は、Pepsi と Squeak の間で通信をさせようと思ったからだ。Squeak で GUI を作るのは簡単なので、Socket を通じて Pepsi のオブジェクトを覗いたり、ツリー状に表示すれば役に立つし、頑張ればリモートデバッガだって出来る。これでありがちな鶏卵問題から抜け出したい。 これまでは Pepsi 用の開発ツールを Pepsi 自身で書くというの私の戦略だった。し
エディタのデザイン - 言語ゲーム
金曜日にプレゼンがあって、久しぶりに徹夜した物だから週末はめちゃくちゃしんどかった。ので、今日はほとんど一日寝ていた。まだしんどい。が、せっかくなので内部でプレゼンしたスライドをアップする。 エディタのような普通のアプリをどうやったら綺麗に記述出来るだろうかという話です。まー例えば入力が元のテキストとキーボードイベントで、出力がテキスト画像と変更後のテキストであるような関数をエディタだと考える事が出来ます。 これを素直にプログラムで書くと、こんな感じになります。上からイベントがやってきて、テキストの内部表現(TextBuffer)を変更します。それを画面に表示するにはレイアウト用のデータ構造(TextView)を作成して、さらにビットマップに変換してデバイスに送ります。確かに単純ですが、これを副作用抜きで毎回オブジェクトを作るとなると遅すぎて動きません。数百文字で挫折します。 という事で、
クロージャとオブジェクトは同じ物だという話 - 言語ゲーム
前に lambda lifting という言葉を聞いてから、ずっと妄想しているのは、クロージャとオブジェクトは「似ている」のではなく「同じ物」なのではないかという事。lambda lifting というのはクロージャをコンビネータに変形する操作の事で、多分簡単に書けば function f() { var a = 1 return function() { return a * 2 } } のような関数を function g(env) { return env.a * 2; } function f() { var a = 1 return g({a: 1}); } のように書き直してスコープをまたがる a のような変数アクセスを無くす事だと思います。で、これなんかに似てるなーと思ったら、オブジェクト指向言語のメソッドにそっくりです。python や perl のような言語ではレシーバを
なぜ属性文法が重要なのか - 言語ゲーム
http://www.haskell.org/tmrwiki/WhyAttributeGrammarsMatter 問題 属性文法が盛り上がる予感なので、Wikipedia にリンクがあった面白い記事を読む。テーマは、関数型言語は凄いけど、属性文法と組み合わせるともっと凄いという話。例として、ある数列の平均からの差を求める diff という関数が紹介されている。例えば、[1, 2, 3] を与えると、平均は 2 なので [-1.0,0.0,1.0] を返す。素直に Haskell で書くとこんな感じ。 diff0 xs = map (\x -> x - (avg xs)) xs -- 平均からの差 avg xs = sum xs / fromIntegral (length xs) -- 平均値 さてこれは気に食わないらしい。なぜかと言うと、sum, length, map で都合三回リス
タイルスクリプト進捗 - 言語ゲーム
さてインスペクタが要るので、GUI 更新メカニズムをどうしようかと考えている。多分まだ作らないけど、頭の中にあるのは FRP をオブジェクト指向に応用した画期的な方式で、http://d.hatena.ne.jp/propella/20070313/p1 でいう所の論理モデルの設計は次のとおり。 具体的には、モデルとビューの関係を単に木構造であると考える。一旦ビューから参照されたモデルは、他のオブジェクトへの参照を変更してはならない事。という風な制約をつける。変更したければ全体を作り直せばよい。そうするとオブジェクト間の関係は静的で、しかもループが無い事を保証出来る。静的でループが無いので、システムは物理的モデル(Observer pattern を使うのか、ポーリングを行うのか、コピーを持つかどうか等等)について参照を作る際に決定出来る。多分。プログラマに大事なのは、どの要素にどの要素が
Intentional Software - 言語ゲーム
http://intentsoft.com/technology/IS_OOPSLA_2006_paper.pdf これもアランさんお勧め論文。未来のプログラミング環境の話です。 まず現在の問題として、プログラマが全部プログラムを書くのはおかしい、プログラムを使う人もプログラムを書くべきだというのがあります。プログラマはプログラムには詳しくても使う人の業務の都合なんかよく分からないので、そんな事で使いやすいプログラムが出来るわけ無いという事です。このあたりhttp://d.hatena.ne.jp/propella/20071218/p2 で紹介したマーチンファウラーの記事を先に読んだ方が良いと思います。 Intentional Software とは関係ないけど重要なのでマーチンファイラーの話のポイントを書くと、ユーザが簡単にプログラムを書けるミニ言語 (DSL) には二つあって、 内部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
