Orz日記 by Akio Morita

_ [SAD]Map1/Scan1実装

Joinに続き、Map1/Scan1の実装完了

で、データ操作系の典型的なユースケースを試していると以下のケースで、スタックを踏み抜く

• MapThread[f, {long-list, long-list}]
  • Map[f@@#&, Thread[{long-list, long-list}]]はOK
  • 多分、Threadは、いきなりリストコンテナを組み立てているからOKの模様
  • ScanThreadはテストしていないが、おそらくスタックに積み上げた出力列が溢れている
• f@@long-list (fは、Reduction operator)
  • fの評価式をApplyで組み立てる際に、引数列としてlong-listをスタック上に展開する(式をスタック上に展開して評価する関数評価呼び出しシステム上の問題)
  • Applyが、fがReduction演算であることを知っていれば、イテレータ処理に移譲できるが、ユーザー定義のReduction演算子には無力
    • 評価器のスタックベースの評価を止める or sequence containerによる式評価を導入する
      • 関数評価時の引数参照インターフェースの変更が必要
        • Apply等からの運用を想定すると、Head + Argument Containter渡しが現実解か？
      • 実装過渡期は、引数列参照渡しとStack渡しの両方をサポートする必要有り
        • 関数テーブルに引数型式属性を持たせて、評価時の呼び出しプロトタイプをDispatchさせる
    • Reduction演算を行う高階関数を導入する
      • 例えば、左再帰なReduction演算 LeftReduce[f, {arg1, arg2, args...}] := LeftReduce[f, {f[arg1, arg2], args...}] := f[f[...f[f[arg1, arg2], arg3]...], argn]
        • LeftReduce[f, {}] := f[], LeftReduce[f, {arg1}] := f[arg1] == f[f[], arg1] であるべきか…
      • 浮動小数点処理の場合、評価木の組み方で処理結果が異なる
      • 短縮評価可能な論理演算の場合、評価木の組み方で処理時間が異なる
      • n要素に分岐する再帰的な評価木もありえる