3D使うのはそこだけだったので、addChildされたとき上方のperspectiveProjectionを全てnullにしつつ、ルートの表示オブジェクトのみ値を設定して結果を合わせた。けどなんか気持ち悪い。。

var o:DisplayObject = this;
while (o.parent != stage) {
  o.transform.perspectiveProjection = null;
  o = o.parent;
}

リキッドの場合は、プロジェクションセンターも更新しないと意図通りにならないかも・・。

private function onResize(evt:Event):void {
  var proj:PerspectiveProjection = root.transform.perspectiveProjection;
  var pt:Point = proj.projectionCenter;
  pt.x = stage.stageWidth * 0.5;
  pt.y = stage.stageHeight * 0.5;
  proj.projectionCenter = pt;
  root.transform.perspectiveProjection = proj;
}

最後の参照を消すとき、

_instanceVar = null; //これでいつか解放されるはずだが・・

と書いているところを、

//常に戻り値のnullが代入されるが、同時に漏れを確認
_instanceVar = GC.shouldBeGarbage(_instanceVar); // 以降、ゴミとして回収されるべき！

と書くことにします[*注]。これで参照の消し忘れがあれば、直後にエラーになってくれます。多分。

ちなみにFlexでは子SWFがアンロードされると、以下のように表示されるのでこれの出番は少ないかもしれません。

[SWF のアンロード]Users:masuda:Documents:Flex Builder 3:Test:bin-debug:child.swf

以下にいくつかサンプルを挙げます。
ドキュメントクラスのコンストラクタに書かれているコードだと思って下さい。

ローカル変数はGCされる:

var o:DisplayObject = new Sprite();
GC.shouldBeGarbage(o); //=> GC succeeded: 4489216 => 4771840

インスタンス変数に退避したため延命され、GCされない:

var o:DisplayObject = new Sprite();
_instanceVar = o;
GC.shouldBeGarbage(o); //=> Error

表示リストに残っているため、GCされない:

_instanceVar = new Sprite();
addChild(_instanceVar);
//removeChild(_instanceVar); //この行が必要だった
_instanceVar = GC.shouldBeGarbage(_instanceVar); //=> Error

ローカル変数はクロージャに延命され、クロージャはstageに延命されるのでGCされない:

var o:DisplayObject = new Sprite();
addChild(o);
removeChild(o);
GC.shouldBeGarbage(o); //=> Error
//o = null; //この行が必要だった
stage.addEventListener(
  Event.ENTER_FRAME,
  function(evt:Event):void {/*どの変数も参照してなくても害*/}
);

クロージャとメモリリークについての親切な解説はこちら:
http://www.imajuk.com/blog/archives/2008/04/post_3.html

以下、ソースコードです:

package {
  import flash.display.Sprite;
  import flash.events.Event;
  import flash.net.LocalConnection;
  import flash.system.System;
  import flash.utils.Dictionary;

  public class GC {
    private static var sprite:Sprite = new Sprite();

    public static function start():void {
      try {
        new LocalConnection().connect('foo');
        new LocalConnection().connect('foo');
      } catch (e:*) {}
    }

    public static function shouldBeGarbage(value:Object):* {
      try {
        //テストは1フレ後だが、この時点のスタックトレースがほしい
        throw new Error('Probably, it is not garbage:' + value);
      } catch (e:Error) {
        var dict:Dictionary = new Dictionary(true);
        dict[value] = true;
        value = null;

        var before:uint = System.totalMemory;
        GC.start();

        var err:Error = e;
        sprite.addEventListener(Event.ENTER_FRAME, function(evt:Event):void {
          evt.target.removeEventListener(evt.type, arguments.callee);
          for (var key:Object in dict) throw err;
          trace('GC succeeded:', before, '=>', System.totalMemory);
        });
      }
      return null;
    }
  }
}

[*注] 以下の例は、全ての参照を消すのに先だってshouldBeGarbageを行うためGCが成功しそうにありませんが、実際のところ、このように書いてもテストをパスします。

GC.shouldBeGarbage(_instanceVar);
_instanceVar = null;

恐らく、LocalConnectionによる強制GCの発動は即座に行われずに、一度Flash Playerに制御を戻した後行われているのだと想像しています・・。そうなると、shouldBeGarbage(x)の意味合いとしては、「現在実行中のコードを抜けた後には、xはゴミとなり回収されるべきだ」といったところでしょうか。

以下は0〜2個の引数を取るMath.random:

(defn rand
  ([] ((. Math random)))
  ([n] (* n (rand)))
  ([a b]
    (if (< a b)
      (+ a (rand (- b a)))
      (+ b (rand (- a b))))))

(rand -1 1) ;=> -0.689156367443502

要は引数のパターンに応じた振り分けと同時に変数束縛されるようですが、これが再帰関数の場合には特に便利で、例えばリストをペアに区切ったリストにして返す手続きは:

(defn pairs [l]
  (apply
    (fn
      ([x] (list (list x)))
      ([x y] (list (list x y)))
      ([x y & z] (cons (list x y) (pairs z))))
  l))

(pairs '(1 2 3 4 5)) ;=> ((1 2) (3 4) (5))

ところで、las3rでは{:x 200 :y 400 :time 0.5}と書くと内部的にはMapというオブジェクトになってしまうようなので、Tweener.addTweenの第二引数に渡せません。MapからObjectへ変換するそれらしき関数も見つからなかったので、試しにObjectリテラルに近い書き方ができるマクロを書いてみると:

(defmacro obj [& elts]
  (let [o (gensym)]
    `(let [~o (new Object)]
      ;;fnやletのパラメータはdestructuring-bindされる雰囲気。
      ~@(map (fn [[var exp]] `(set! (. ~o ~var) ~exp)) (pairs elts))
    ~o)))

(macroexpand-1 '(obj x 200 y 400 time 0.5))
;=>
;(las3r/let [G__1378 (new Object)]
;  (set! (. G__1378 x) 200)
;  (set! (. G__1378 y) 400)
;  (set! (. G__1378 time) 0.5)
;  G__1378)

(obj x 200 y 400 time 0.5) ;=> [object Object]

これで以下のようにだらだらと書かなくて済みます。

(. Tweener
  (addTween
    movie-clip
    (let o (new Object)
      (set! (. o x) 200)
      (set! (. o y) 400)
      (set! (. o time) 0.5)
      o)))

クリックすると画面上をランダムに移動する四角形はこんな雰囲気:

(import '(flash.display Sprite Graphics)
        '(caurina.transitions Tweener))

(def s ((. *stage* addChild) (new Sprite)))

(doto (. s graphics)
  (beginFill 0x0000ff 1)
  (drawRect 0 0 100 100)
  (endFill))

(. s
  (addEventListener "click"
    (fn []
      (. Tweener (addTween
        s
        (obj x (rand (. *stage* width))
             y (rand (. *stage* height))
             time 0.5))))))

最後に衝撃のfib(25)の時間比較:

• ABC
  => 88 msec
• AS3
  => 125 msec
• las3r
  => 5465 msec
• SICP4.1.7をASに移植したもの(比較用)
  => 11255 msec

なるほど・・・。
まだきっと伸びしろはありますよね！
速くなるといいなぁ。。

なお、計測の対象は以下の関数:

AS3:

private function fib(n:uint):uint {
  return (n < 2) ? n : fib(n - 1) + fib(n - 2);
}

ABC(hxasmを使用):

var ctx:Context = new Context();
ctx.beginClass("Main");
var tint:Index = ctx.type("int");
var m:* = ctx.beginMethod("fib", [tint], tint);
m.maxStack = 3;
ctx.ops([
  OpCode.OReg(1),
  OpCode.OSmallInt(1),
]);
var j:Function = ctx.jump(JumpStyle.JGt);
ctx.ops([
  OpCode.OReg(1),
  OpCode.ORet,
]);
j();
ctx.ops([
  OpCode.ODecrIReg(1),
  OpCode.OThis,
  OpCode.OReg(1),
  OpCode.OCallProperty(ctx.property("fib"),1),
  OpCode.ODecrIReg(1),
  OpCode.OThis,
  OpCode.OReg(1),
  OpCode.OCallProperty(ctx.property("fib"),1),
  OpCode.OOp(Operation.OpAdd),
  OpCode.ORet,
]);
ctx.finalize();

var o:Output = new Output();
Writer.write(o, ctx);
var swf:ByteArray = o.getBytes();

var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, function(evt:Event):void {
  var klass:Class = ApplicationDomain.currentDomain.getDefinition('Main') as Class;
  callback(new klass().fib); //この引数がコンパイル済みfib
});
loader.loadBytes(swf, new LoaderContext(false, ApplicationDomain.currentDomain));

las3r:

var rt:RT = new RT(stage, new OutputStream(trace), new OutputStream(trace));
rt.loadStdLib();
rt.evalStr(
  '(defn fib [n] (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2))))) fib',
  callback //fnを評価するとコンパイル済みfibがcallbackに渡る
);

SICP4.1.7をASに移植したもの:

var fib:Function =
  eval("(define (fib n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2))))) fib");

/*evalの定義は長いので略*/

構文的な違いが結構あり戸惑ったのですが、こちらを見ればだいたいつかめると思います。

Schemeじゃないから当然かもしれませんし、ABC的に実装に難があるからかも分かりませんが、残念ながら:

• 末尾最適化なし (末尾再帰にはrecurを使えばスタックを消費しない)
• 継続なし

しかし、それを差し引いてもASにない以下の特徴を楽しむことができます:

• マクロが使える
• 動的コンパイル

しかも、Emacs向けにlas3r-modeが用意されていて、起動中のSWFに対し修正を動的に反映できます。
以下手順:

1. etc/las3r-mode.elをEmacsのロードパスへ配置
2. もしなければ、以下もDLしてロードパスへ配置
   http-get.el, http-cookies.el, http-post.el
3. .emacsに以下を追記
   (autoload 'las3r-mode "las3r-mode" "Major mode for las3r." t)
   (add-to-list 'auto-mode-alist '("\\.lsr$" . las3r-mode))
4. src/lsr/boot.lsrの最終行、;;(connect-to-eval-pipe)をコメントインしておく
5. etc/eval_pipe.rbを起動しておく
6. 対象のSWFを起動しておく
7. Emacsにて*.lsrの編集中にF5 (すると、バッファ全体がevalされる)

この手の試みがじわりじわりと増えてきているような気がしますね・・。
今後が楽しみです。

関連メモ:
http://hg.mozilla.org/tamarin-central/file/d92e466aed84/esc/src/
元?

http://eval.hurlant.com/
上記のAS3版だと思う。las3rはこれの一部を使っている。

http://ariyan-harhid.cocolog-nifty.com/blog/2008/10/tamarin-esc-c-2.html
上記の改良版。実行時エラー情報を詳しく教えてくれたりetc

http://happyabc.org/
OCaml製のSchemeコンパイラ

http://www.bitbucket.org/SumiTomohiko/actionpython/overview/
これは・・？

http://haxe.org/com/libs/hxasm
haXeのABCアセンブラ

http://www.sephiroth.it/weblog/archives/2008/07/expressions_evaluation_at_almost_nati.php
上記のAS3版を基礎としたシンプルな電卓デモ

http://www.anotherbigidea.com/javaswf/avm2/AVM2Instructions.html
見やすい

http://code.google.com/p/as3c/
インラインアセンブラ

この辺りの話を聞くのは今回が初めてであったという方には、私のプレゼン内容が(メディア)アートと思われてしまうとまずいので、コマーシャルであると断っておきます。プレゼンの最初で口頭でも言い訳していたのですが、ちょっと言葉足らずであったと反省しております。。個人的にはかなり貴重な体験をさせていただいて大満足なのですが、やはりだいぶ役不足感満天でしたね・・。江渡浩一郎さんはとっくの昔にメディアアート作品にRubyを活用しておられましたし、少しでもメディアアート事情を知っていた方には非常に残念な発表となることは流石に自覚しておりましたが、折角お話をいただいたので、えいや！と発表した次第であります。。。。

あともう一点補足です。NON-GRIDさんを中心に企画・制作され、GUIの実装に関わらせていただいたInteractiveMirrorですが、一部でバーチャルで試着できるかのように解釈されてしまっているようですが、そんなことはありませんｗ そんな発言をしたつもりはなかったのですが、、おかしいですね・・　

ところで、これが初めてLLのイベントを見る機会となったのですが、内容が高度過ぎてついていけない話題が多かったもののプレゼン技術の異様に高い方ばかりで楽しませていただきました。InterCommunicationで以前に久保田教授が触れていたライヴパフォーマンスのインターフェースとしての関数型言語(Haskell + SuperCollider)、多分ポイントフリースタイルの簡潔さ辺りを評価しているのではと推測しますが、もしそういった形態のライヴであればいかにも楽しんでいただけそうであると感じました。音楽的知識が皆無過ぎるので言ってみるだけですが！

VJをするなら、fluxusのデモのようにあからさまに副作用あるとピュアじゃないとお叱りを受けそうですので、視覚的な構造は図形言語方式で記述し、時は代入でなくストリームで扱うことになるでしょう。まんま以下の形です:
http://www.ipa.go.jp/jinzai/esp/2005youth/mdata/99-02.html

もう既にどこかにいるような気がしますが、パフォーマーとして誰かがこの道を進んでくれるならすごく見てみたいし、美しいプロセスだと思ってしまうのですが・・。

実は最近になってようやくProgressionを勉強しています。ver3からの入門です(汗)。3本柱の一つであると聞くキャストですが、今まで表示オブジェクトのサブクラス化を好んで行わない(= リンケージしないでインスタンス名つけて操作する)スタイルで制作していたという極めて個人的な理由で食わず嫌いしていたのですが、その考えはすぐに変わることになりました。

リンケージの手間を惜しむ私のような人間には、リンケージ一括設定(特に接尾辞プロファイル！)が以前から提供されていたようですし、開発予定の画面ではなんかキャストのテンプレートを自動生成してくれそうな雰囲気すら漂わせているように見えますが(気のせいでしょうか？)、もしそのようになればキャストのサブクラスを作る負担はかなり減ることになるので期待が膨らんでしまいます。さらにキャストはonCastXXXの処理中に追加したコマンドを同期化してくれるだけかと思っていたものの、実はjp.nium.display系の便利機能を継承していたことを知り、主な機能をチェックしてみようと思ったわけでした。

IEventIntegrator

removeAllListeners(completely:Boolean = false):void
restoreRemovedListeners():void
これら二つを用いて、イベントの配信停止と再開が手軽に実現できるようです。ただし、addExclusivelyEventListenerで追加された場合この限りではないようです。

IExDisplayObject

このインターフェースを実装しているクラスのインスタンスは、jp.progression.casts.*の以下の3つのパッケージ関数によって表示ツリーの階層を問わず簡単に取得できるようです。

getInstanceById(id:String):DisplayObject
表示オブジェクトにidを設定しておくと、階層問わず参照できるようです。getElementByIDみたいですね。

getInstancesByGroup(group:String, sort:Boolean = false):Array
表示オブジェクトにグループ名を設定しておくと、階層問わず集められるようです。

getInstancesByRegExp(fieldName:String, pattern:RegExp, sort:Boolean = false):Array
任意のフィールドで正規表現にマッチした表示オブジェクトを階層問わず集められるようです。例えば、ボタンごとにインスタンス名をつける代わりに以下のように参照することもできそうです。

//同一シンボルを1つしか配置しないため、クラス名からインスタンスが一意に決まる
CastButton(getInstancesByRegExp('className', /^AboutButton$/)[0])
.sceneId = aboutScene.sceneId;

追記: 先ほど試してみたところ、これらの3つのメソッドはaddChildしてステージに追加しなくても使えるみたいです。ということはid設定したら自己責任でexDisplayObject.id = null;などとしてコレクションから消さないとGCされないのかな・・？

setProperties(props:Object):DisplayObject
プロパティの一括設定を行えるようです。CastSpriteの表示アニメーション以前に行う座標などの初期化をすっきりとまとめられそうです。

ExDisplayObject

toBitmapData(transparent:Boolean = true, fillColor:uint = 0xFFFFFFFF):BitmapData
表示オブジェクトの内容をBitmapData化したものを取得します。

以上の操作は、ExLoader, ExMovieClip, ExSprite, ExTextFieldなどで利用できる感じです。このうち、コンテナ系のものであれば以下も利用できる感じです。

IExDisplayObjectContainer

children : Array
DisplayObjectContainerの子の走査は面倒でしたが、これで随分楽になりそうです。IExDisplayObjectContainerは、必ずしもインデックス値が連続している必要はないため、あらかじめ大きな値を設定しておいて最前面を確保したいときなどに便利そうです。となれば、走査するにあたってnull要素を除いた子のリストが欲しくなるでしょうが、こいつがそれを提供してくれるっぽいです。

contains(child:DisplayObject):Boolean
指定された表示オブジェクトを含むか、自身であればtrueを返します。孫、ひ孫・・とツリー全体をテストしてくれるようです。

removeAllChildren():void
全ての子を削除します。地味に便利です。

最後に、インスタンス化できるものでユニークだなと思った機能に以下があります。

ExSprite

isDragging : Boolean
startDrag()を使用中か否かを返します。

ExMovieClip

isPlaying : Boolean
ムービークリップの再生ヘッドが移動中か取得します。

repeat : Boolean
ループ再生するかを取得または設定できるようです。

switchAtPlaying():void
再生と停止を切り替えます。

ExTextField

appendTextAtCaretIndex(newText:String):void
テキストフィールドのキャレット位置に文字列を挿入できるみたいです。

displayパッケージの機能拡張は継承の苦しい裂目が見えてきて大変な部分だと想像しますが、ここまで使い勝手の優先を貫いていることに感心してしまいました。おかげで、各々の表示キャストはDisplayObjectと同一視できつつ、一方でIExDisplayObjectとしての顔も持つようです。しかし、これもProgressionのごく一部に過ぎないと思うと驚異的ですね！

各ライブラリの特徴をつかむため、以下のポイントについて共通で見ていくことにします。

1. 合成
   複数の処理を直列化・並列化した複合物を区別なく扱えるか？処理の入れ子はどのように実現されているか？
2. 並列実行
   複数の処理の同時実行と、完了の待ち合わせが可能か？
3. 例外処理
   エラーハンドラは追加できるか？エラーからの回復は可能か？
4. 続行
   エラー発生時に、現在の処理をスキップして、残りの処理を続行することが可能か？
5. 中止
   処理の中止は可能か？
6. 値の受け渡し
   処理の結果として得られた値を、後続の処理に受け渡す仕組みはあるか？
7. 冗長さ
   処理を追加する手順はどうか？クラスを新規に作るのか？クロージャを渡すのか？
8. 動的な処理の追加
   処理を追加できる有効なタイミングは？実行後にも処理を追加でき、実行キューのように振る舞うか？
9. 開始トリガ
   処理の構築と実行が切り離されていて明示的に開始するのか？それとも構築と同時に暗黙で開始されるのか？
10. 再実行
    同じ非同期処理を、2回以上実行可能か？
11. 進捗通知
    ロードなどの進捗を通知する枠組みがあるか？
12. イベントへの適合
    完了の通知は、AS3のイベントモデルに準拠して行われるか？
    逆に、イベントを各々の非同期処理モデルに適合させる方法は提供されているか？

flashrod Job

var job:Job = new Sequence(
	new Trace("begin"),
	new Concurrent(new URLGet("http://www.google.com/"),
	               new URLGet("http://www.yahoo.com/"),
	               new URLGet("http://www.apple.com/"),
	               new URLGet("http://www.mozilla.org/")),
	new Sequence(new URLGet("http://www.cnn.com/"),
	             new URLGet("http://del.icio.us/")),
	new Trace("wait for 2 sec."),
	new Wait(2000),
	new Concurrent(new URLGet("http://tumblr.com/"),
	               new URLGet("http://flickr.com/")),
	new Trace("end"));
job.start();

非同期処理の同期化を助ける非常にシンプルな方法です。引数なしのstartメソッドで実行が開始され、完了時にfinishedを送出するものをJobとし、全てのクラスはJobを実装します。たとえ同期処理でも、完了時にfinishedを送出することが求められます。

1. 合成可。SequenceやConcurrentはJobインターフェースを実装している。
2. 並列実行可。Concurrentクラスを使う。
3. エラーについては扱っていない。
4. 続行可。たとえエラーが発生しても、finishedイベントを送出するようJobを実装すればよい。
5. 中止は扱っていない。
6. 値の受け渡しは不可。Job側で結果を保持しておく、などの必要があり。
7. traceすらもJobの実装クラスになる。クロージャ渡せるようにしたい人は各自でといった感じ。
8. 非同期処理の構築はコンストラクタでのみ行われ、その後の変更は不可。
9. Job#start()で明示的な実行を行う。
10. WaitやURLGetを除いた複合非同期処理は再実行不可。一度完了した頃には配列が空になるため。
11. 進捗は通知されない。
12. 完了通知はAS3のイベントモデルに準拠している。イベントからJobを作る汎用メソッドは特にない。

fladdict Command

var ar:Array = [];
ar.push( new Command(null, trace, ["start serial command"]) );
ar.push( new ASyncCommand(myLoader, myLoader.load, [new URLRequest("URL")],
	myLoader.loaderContent, Event.COMPLETE));
ar.push( new TimerCommand(1000));
ar.push( new XMLLoaderCommand({url:"hogehoge", dataScope:this, dataProp:"dataResult"}))

var command:SerialCommand = new SerialCommand( ar );
command.execute();

さきほどのものに近いアプローチだと思いますが、いくつか実用的な機能が備わっています。引数なしのexecuteメソッドで実行が開始され、完了時にcompleteを送出するものをICommandとし、全てのクラスはICommandを実装します。たとえ同期処理でも、完了時にcompleteを送出することが求められますが、単に同期処理を追加したいだけであればわざわざクラスを作らずとも、Commandというクラスのコンストラクタにスコープと関数と引数を指定してやるだけで済みます。一方の非同期処理はAsyncCommandでラップでき、Commandと同様のコンストラクタ引数に加えて、イベントディスパッチャと完了を通知するイベント名を指定して作成します。

1. 合成可。SerialCommandやParallelCommandはICommandインターフェースを実装している。
2. 並列実行可。ParallelCommandクラスを使う。
3. エラーについては扱っていない。
4. 続行可。たとえエラーが発生しても、completeイベントを送出するようなCommandを実装すればよい。AsyncCommandを利用する場合、ディスパッチャのエラーイベントについて関知しないことに注意。
5. ICommand.asを見るに、中止は予定しているように見えるが、未実装と思われる。
6. 値の受け渡しは不可。Command側で結果を保持しておく、などの必要あり。
7. 複合非同期処理の基底クラスであるBatchCommandには各種ショートカットメソッドがあり、後続の処理の追加を簡単にしている。
8. 非同期処理の追加を実行中にもできるが、実行後に追加した処理は開始されないと思われる。
9. ICommand#execute()で明示的な実行を行う。
10. 複合非同期処理の進捗状況を保存する_indexというカウンタがリセットされないため、再実行は想定していない操作と思われる。
11. 進捗は通知されない。
12. 完了通知はAS3のイベントモデルに準拠している。メソッドとその完了を告げるイベントをワンセットとして非同期処理を表現するAsyncCommandが提供されている。

Mochikit Deferred
JSになってしまいますが、ASへの移植も容易なため紹介します。MochikitのDeferredは以下が大変参考になります。
http://d.hatena.ne.jp/brazil/20080721/1216580402

本家TwistedのDeferredは、スレッドを意識せずプログラムするために生まれたのだと聞きますが、スレッドのないFlashにおいては単にaddEventListenerがアプリケーションコードに直接現れない形で、非同期処理を繋げていく仕組みとして理解することができます。JobやCommandに見られる、処理をオブジェクトとしてラップするアプローチに対し、Deferredは関数を直にコールバックチェーンに追加します。そして、callbackの呼び出しにより完了が通知されると、コールバックチェーンの要素を順番に呼び出していきます。呼び出しの結果、戻り値がDeferredであれば非同期処理とみなして残りの実行を後回しに、それ以外であれば同期処理と見なして次のコールバックを呼び出します。

ハンドラの追加は、実行が終わった後になってからも可能で、以下のような微妙な違いがあります。

//Mochikit Deferred
var d = new Deferred();
d.callback();
d.addCallback(function() {alert("hoge");}); //呼ばれる

//JSDeferred
var d = new Deferred();
d.call();
d.next(function() {alert("hoge");}); //呼ばれない

1. 合成可。コールバックの戻り値がDeferredの場合、チェーンの実行は一時停止され、子チェーンの完了を待機。
2. 並列実行可。DeferredListを使う。
3. エラーハンドラはaddErrBackで追加できる。ただし、ErrorEventが送出されたときにerrbackを呼ぶように作っておく必要はある。ハンドラ内で非Errorを返した場合、回復したものとしてコールバックチェーンを再開。
4. 続行可。addBothで、エラーが起こるにせよ起こらないにせよ実行したい後続の処理を追加すればよい。
5. 中止は可。何もしないと、現在の処理を終えてからようやく中止されるが、コンストラクタに適切なキャンセル関数を指定してやれば即座に中止するDeferredを作ることも可。
6. 値はコールバック関数の引数で受け取り、戻り値で後続の処理に引き継ぐ。
7. クロージャを追加できる。第2引数以降を指定すれば、引数を束縛した関数を追加することもできる。
8. 非同期処理の追加をいつでもできる。実行後であれば、追加した瞬間実行される。ただし、子チェーンであると判明したDeferredには以後コールバックの追加は許されない(Chained Deferreds can not be re-used)。Mochikitの実装でそれを許すと、処理の流れは2本に分岐してしまうからか？
9. Deferredを返す関数を呼び出して、非同期処理の実行を開始すると同時に、後追いでチェーンを構築するケースが多いと思う(暗黙的開始)。あるいは事前にチェーンを構築してcallbackを呼び出す(明示的開始)。
10. Deferredは1回しかcallbackが許されない(AlreadyCalledError)。Deferredを返す関数は毎回フレッシュなDeferredを使うのが原則と思われ、そのように実装している限りにおいて再実行は可能といえなくもないが、オブジェクトは再利用できていない。
11. 進捗は通知されない。
12. 完了通知をイベントに戻したければ、誰かにdispatchEventしてもらうことになる。イベントを一度だけリッスンしてDeferredを返す関数を定義しておけば、いろいろと便利になると思われる。

cho45 JSDeferred

next(function () {
    alert("1");
}).
next(function () {
    alert("2");
    // child Deferred
    return next(function () {
        alert("3");
    });
}).
next(function () {
    alert("4");
});
alert("0");

Mochikitの実装をもっとシンプルにできそうなので作ったとのライブラリです。こちらもJSですが、AS3へ移植したものもあるようです(並列処理を直列に繋ぐためのショートカットメソッドDeferred#parallelが加えられている点を除き同じかと思わる)。Mochikitとの違いとして、単方向リストを使用したミニマルな実装であること、nextをメソッドチェーンすると最後に追加されたDeferredを指すこと、上の例のように開始は即座でなく同期処理の後に先送りされること(さもないとチェインの構築が間に合わない？)、callやfailによるチェーンの再実行が許可されていること、チェーンの実行後にハンドラを追加しても自動的には実行されないこと、などがあると思います。

1. 合成可。コールバックの戻り値がDeferredの場合、このようにチェーンを繋ぎなおす。
2. 並列実行可。Deferred.parallelを使う。
3. エラーハンドラはerrorで追加できる。ただし、ErrorEventが送出されたときにfailを呼ぶように作っておく必要はある。ハンドラの中で改めてthrowしなければ、回復したものとしてコールバックチェーンを再開。
4. 続行可。エラーが起こる可能性がある処理の後に、何もしないエラーハンドラを追加すればよい。
5. 中止は可。ただし、直列化された非同期処理の中止は、現在実行中のDeferredをライブラリ側で関知してくれないため、少々やりにくいと思われる。
6. 値はコールバック関数の引数で受け取り、戻り値で後続の処理に引き継ぐ。
7. クロージャを追加できる。引数を束縛させる機能はないので、やりたければ自前でやる。
8. 非同期処理の追加を実行中にもできるが、実行後に追加した処理は開始されないと思われる。
9. 先頭のnextがディレイを噛ませた隙にチェーンを構築するケースが多いと思う(暗黙的開始)。あるいは事前にチェーンを構築してcallを呼び出す(明示的開始)。
10. チェーン先頭のDeferredを保持しておいて必要なときにcallすれば可。
11. 進捗は通知されない。
12. 完了通知をイベントに戻したければ、誰かにdispatchEventしてもらうことになる。イベントを一度だけリッスンしてDeferredを返す関数を定義しておけば、いろいろと便利になると思われる。

voidelement Chain

Chain.parallel({
	foo: { time:5, onComplete:"5000ms" },
	bar: {
		text:"http://www.google.co.jp/",
		onStart:"load text: start",
		onComplete:"load text: complete"
	}
}).
next( function():void {
	trace( this.data.bar );
});

JSDeferredのAS実装であるASDeferredをベースに、よく使う処理を簡単に書けるような工夫が施されています。直列処理の追加は、next(function() {...})のような基本的なメソッドに加え、イベントを一度だけ待つlistenや、アニメーションを行うtweenerといった各種ショートカットメソッドを直にメソッドチェーンできるようになっています。並列処理の追加は、辞書を渡すようになっており、それぞれの非同期処理にラベルをつけて結果を後から参照しやすくするついでに、定型的な処理であればそれも辞書で書いてしまおう、といった感じになっています。

1. 合成可。コールバックの戻り値がChainの場合、このようにチェーンを繋ぎなおす。
2. 並列実行可。parallelを使う。
3. エラーハンドラはerrorで追加できる。ライブラリで提供されているChainは、ErrorEventが送出されたときにエラーハンドラが呼ばれるようになっている。ハンドラの中で改めてthrowしなければ、回復したものとしてコールバックチェーンを再開。
4. 続行可。エラーが起こる可能性がある処理の後に、何もしないエラーハンドラを追加すればよい。
5. 中止は可。ただし、直列化された非同期処理の中止は、現在実行中のChainをライブラリ側で関知してくれないため、少々やりにくいと思われる。
6. 値はコールバック関数の引数ではなく、this.dataで受け取り、戻り値で後続の処理に引き継ぐ。戻り値のない処理がチェーンの途中に挟まっても、最後に得たdataを辿れるよう双方向リストになっている。多分。
7. nextやerrorでクロージャを追加できる他、よく使う処理の追加は専用メソッドで行える。
8. 非同期処理の追加を実行中にもできるが、実行後に追加した処理は開始されないと思われる。
9. 先頭のChain.hogehogeがディレイを噛ませた隙にチェーンを構築するケースが多いと思う(暗黙的開始)。あるいは事前にチェーンを構築してexecuteを呼び出す(明示的開始)。
10. チェーン先頭のChainを保持しておいて必要なときにexecuteすれば可。
11. 進捗は通知されない。
12. 完了通知をイベントに戻したければ、誰かにdispatchEventしてもらうことになる。ListenerChainを利用すると、イベントから簡単にChainを作れる。

secondlife Chain
試してみようと思っていたものの、ソースのリンク死んでる模様？?

beinteractive Thread

/* 前略 */

// リサイズ監視用スレッド
new ResizeHandlingThread(context).start();
// 検索制御用スレッド
new SearchControlThread(context).start();
// 初期アニメーション等を行うスレッド
new IntroThread(context).start();
// 3D 制御用スレッド
new PapervisionControlThread(context).start();

/* 後略 */

addEventListenerを隠蔽し、非同期処理を同期処理の感覚で書けるライブラリということですが、むしろ状態遷移の多いリアルタイム処理をスマートに書けるようにするためのフレームワークといった感じで、今までのものとはちょっと異質です。個々のThreadは自分の依存するリソースやイベントのことだけ考えればよく、それらの待機は同期処理の感覚で行えるため、時間的しがらみを超えてコントローラを分割できるようになります。また、ロード中やオーバー待ちといった状態を一つのメソッドと対応付けできるので、状態遷移図を素直にコードに落とし込むようにしてプログラムが書けるのもメリットの一つかと思います。

1. 合成可。SerialExecutorやParallelExecutorはThreadを継承している。
2. 並列実行可。ParallelExecutorを使う。
3. エラーハンドラはerrorで追加できる。第一引数には補足するエラーの型を、第二引数にハンドラを指定。ハンドラが設定されていなかったり、ハンドラ中にさらにエラーが起きれば、親スレッドに伝播。ハンドラが無事終了すると回復したものとしてエラーが発生する前に実行されていた実行関数から再開するが、ハンドラ内でnextを呼び出した場合はそこから再開。
4. 続行可。このようにする。SerialExecutorが途中でこけたとき、無視して続行するにはどうするんだろう？
5. 中止はinterruptで可。ただし、割り込みハンドラを設定していない状態で待機中のThreadを中止しようするとInterruptedErrorとなる。自作Threadを中止に対応させるにはcheckInterruptedで割り込みされたか調べて行う。
6. 値の受け渡しというか保持は、Threadごとの実装となる。例えば、URLLoaderThreadはloaderを保持する。それとは別に、遅延リソースの生産者と消費者を結合させないためにMonitorが使える。
7. スレッドを使うためのスレッドを書かなければいけないケースがほとんどだと思われる。まるでネズミk(ry
8. だんだん質問に答える意味がよく分からなくなってきたが、SerialExecutorのaddThreadは実行中にもできると思うけど実行後に追加した処理は開始されないと思われる。
9. Thread#startで開始。
10. startは一度しか呼び出せないので、新規のスレッドを作って再実行する。
11. 進捗はIProgressを実装した各種Threadからイベントで通知される。それらのトータルの進捗を通知してほしければ、それぞれをMultiProgressにaddProgressしてやる。ただし、重みを指定する必要があるので、ファイルサイズの比は事前に調べておく。
12. Threadを使っていろいろと処理した後に、続きの処理はイベントドリブンにしたいとか万が一あれば、EventDispatcherThreadを継承してdispatchEventする感じになると思われる。eventメソッドで特定のイベントが起きるまでThreadを待機させることができる。ただし、nextメソッドによって次の実行関数が設定された場合は待機しない。これをうまく利用して、読みやすい状態マシンを書くこともできるようだ。

マウスを動かすとアングルが変わるのですが、顔を横から見たときにサウンドスペクトルになっています。
勢いに任せたひどいソースは以下:
source code

GoogleCodeで提供されているCSVそのままだとちょっと重いので、上のソースに含まれているcsv2binary.rbを使っていろいろと都合のいいバイナリファイルに変換しています。具体的には:

• 「頂点数, X, Y, Z, 明度, X, Y, Z, 明度, X, Y, Z, 明度・・・」 の繰り返しの並び
• フレームを間引く (デモでは1フレ飛ばしでデータを作り、15fpsで再生)
• 明度が低い頂点を捨てる (デモでは60以下を捨てたため髪の毛がない)
• X, Y, Zは適当に16bitにおさめる
• モデルの中心あたりに原点を移動

Flash側はそれをロードし、ByteArrayから頂点情報を読み出して描画という感じです。音に同期させるため、(フレームレートに依存しない)再生時間を元にByteArray中の目的とするフレームを指すpositionを計算しています。

追記:
いちから解説をするべきでしょうが、以下に非常にシンプルなコードが紹介されていたため割愛します！

RadioheadのプロモーションがGoogle Codeで行われている理由

さらに追記:
今改めて未読消化してみるとFlash版の挑戦者はたくさんおられたようです。日付を見るにとても仕事速い！

http://blog.r3c7.net/?p=209
http://nutsu.com/blog/2008/071720_radiohead.html
http://aquioux.blog48.fc2.com/blog-entry-446.html

迷わず頂点を減らした私はなんだか反則してしまったような気持ちです。。

enum(0, 100).filter(function():Boolean {return false;}).forEach(trace); // => (何も起きない)
trace(enum(0, 100).filter(function():Boolean {return false;})); // => [object NullStream]

([]).forEach(trace);と同様な挙動と言われれば当たり前と思うかもしれない。

今のところ最低限のことしか実装してないけど、やはりこっちのアプローチの方があっちよりシンプルかも・・？
勉強ため、ソースの中で解説してみる:

//Stream.as
package masda.stream {
  public class Stream {
    private var _car:Object;
    private var _cdr:Function;

//Streamの実体は、先頭要素(car)と残りのStreamを返す関数(cdr)。
    public function Stream(car:Object, cdr:Function/*delayed object*/) {
      _car = car;

//毎回cdrを評価するのはコストがかかるので、
//memoProcで元の関数の戻り値をキャッシュする関数を得る(後述)。
      _cdr = memoProc(cdr);
    }

//carはそのまま返す。
    public function get car():Object {
      return _car;
    }

//cdrはアクセスされて初めて評価される。
    public function get cdr():Stream {
      return _cdr(); //force
    }

//forEachは終端を表すnilでない限りcdrを辿り、carをコールバックに渡す。
//再帰で書くとスタックオーバーフローするので反復で書くことにする。
    public function forEach(proc:Function):void {
      var s:Stream = this;
      while (s != nil) {
        proc(s.car);
        s = s.cdr;
      }
    }

//StreamからArrayにするには、戻り値にする配列にバインドされたpushをforEachに渡すだけ。
    public function toArray():Array {
      var ary:Array = [];
      forEach(ary.push);
      return ary;
    }

//要素の参照もforEachの要領で行う。
    public function ref(n:uint):Object {
      var s:Stream = this;
      while (s != nil && n > 0) {
        s = s.cdr;
        n--;
      }
      return s.car;
    }

//mapは、carにそれを写像したものを置き、
//cdrが要求されたときに残りをmapしたStreamを返すようなStreamを返す。
//自身がnilならnilを返す。
    public function map(proc:Function):Stream {
      if (this == nil) return nil;

      return new Stream(proc(car), function():Stream {
        return cdr.map(proc);
      });
    }

//filterは、carに述語を満たす要素を置き、
//cdrが要求されたときに残りをfilterしたStreamを返すようなStreamを返す。
//スタックオーバーフロー対策のために、述語を満たすまでwhileによる要素のスキップを行う。
    public function filter(pred:Function):Stream {
      var s:Stream = this;
      var e:Object;
      while (s != nil) {
        e = s.car;
        if (pred(e))
          return new Stream(e, function():Stream {
            return s.cdr.filter(pred);
          });
        s = s.cdr;
      }
      return nil;
    }

//メモ化関数は、引数に指定した関数の戻り値をキャッシュするような関数を返す。
    private static function memoProc(proc:Function):Function {
      var alreadyRun:Boolean = false;
      var result:Object = false;
      return function():Object {
        if (alreadyRun) return result;

        result = proc();
        alreadyRun = true;
        return result;
      }
    }
  }
}

//nil.as
package masda.stream {
//nilはNullStreamの唯一のインスタンスとする。
  public var nil:NullStream = NullStream.getInstance();
}

//NullStream.as
package masda.stream {
//NullStreamはStreamのサブクラス。
  public class NullStream extends Stream {
    private static var instance:NullStream;

//NullStreamはシングルトン。
    public static function getInstance():NullStream {
//インスタンスを遅延初期化。
      instance = instance || new NullStream(new PrivateKey());
      return instance;
    }

//carにnullを置き、Stream#refでインデックスが範囲外のときにはnullが返るようにする。
//cdrが要求されたら自身を返すようにする。
    public function NullStream(key:PrivateKey) {
      super(null, next);
    }

    private function next():Stream {
      return this;
    }
  }
}

//このファイル内でのみ可視なクラスを、コンストラクタをこじ開ける鍵として使う。
class PrivateKey {};

//list.as
package masda.stream {
//引数を要素とするストリームを作成する関数。
  public function list(...args):Stream {
//引数が底つきたらnilを返して終わりを告げる。
    if (args.length == 0) return nil;

//引数は、cdrにアクセスされるたびにそのcarに消費されて短くなる。
    return new Stream(args.shift(), function():Stream {
      return list.apply(null, args);
    });
  }
}

//enum.as
//startから始まり、stopを含む数までをstepの間隔で並べたストリームを返す。
//stopを省略すると無限リストになる。
package masda.stream {
  public function enum(start:Number = 0, stop:Number = NaN, step:Number = 1):Stream {
    function numbersStartingFrom(n:Number, step:Number):Stream {
      return new Stream(n, function():Stream {
        return numbersStartingFrom(n + step, step);
      });
    }

    function enumerateInterval(start:Number, stop:Number, step:Number):Stream {
      if ((step > 0 && start > stop) || (step < 0 && start < stop)) return nil;

      return new Stream(start, function():Stream {
        return enumerateInterval(start + step, stop, step);
      });
    }

    return isNaN(stop) ?
      numbersStartingFrom(start, step) :
      enumerateInterval(start, stop, step);
  }
}

# 文章を書くのが滅多にないためか、文体がコロコロ変わっちゃいますな。。

例えば引数に指定した数から始まる整数列を返す手続きはSICPだと:

(define integers-starting-from n
  (stream-cons n (integers-starting-from (+ n 1))))

これをAS3でやると多分こんな感じになる:

function integersStartingFrom(n:uint):Stream {
  return new Stream(n, function():Stream {
    return integersStartingFrom(n + 1);
  });
}

自分が以前似たようなことをやったときは、同様の関数が以下のような醜い姿に:

function count(start:uint):Iterable {
  return new Iterable(function():Function {
    var i:uint = start;
    return function():uint {
      return i++;
    };
  });
}

遅延リストの構造を「次の要素を返す関数を返す関数」から「cdrが遅延評価されるconsセルを使ったリスト」にしただけでこれだけのシンプルさが得られるなら、あれをもう一度書き直してもいいような気がしています、またいつか！

以下余談:

AS3は特殊形式を扱えないので遅延評価させたい式はいちいち無名関数で包むことになりますが、まあそれは仕方がないとして、末尾最適化がない（ですよね？）のでちょろっと再帰しただけで即スタックオーバーフローするのが終わっています。従って、ストリームの操作の中にはwhileと代入の形に翻訳せねばならないものがあるのが残念なところです。