週刊mosh - 0.2.7への目標 / Win32プロセスAPI

mosh

Open for developmentということで散発的にいろいろやっています。

0.2.7予報

年末〜来年初頭にリリース予定の0.2.7では以下のような機能が導入されるかも。

  • Win32と互換のプロセスAPI
  • wxWidgetsのサポート
  • OS固有機能のためのインフラ

以下は開発初期段階なので入るかどうかは完全に未定 :

将来展望としては、Clangを取り込むことでC++をfirst classにサポートし、moshでmoshをセルフホストするのが目標。Schemeで書いたSchemeはかなり柔軟に色々なことが出来るけど、それと同様の効果を可能な限り楽に手に入れることができそうなので。
I/Oフレームワークは、現状のR6RS Portを直接実装したI/Oレイヤではファイルリダイレクトのような重要な操作が効率的に実装できないのが動機。

プロセスAPI

現状の(mosh process)はWin32で使うには色々と不便なので、似たAPIでありながらクロスプラットフォームなものを検討中。
portを渡すのは地味に難しいことが判明したので、I/Oフレームワーク側で吸収する仕組みにしそう。どちらにせよリダイレクトの問題が有る。
一応、(mosh process)による実装も用意しているが、どうもstdoutやstderrに#tを渡してバッファリングさせると正常に動かないようだ。

(import (rnrs) (nmosh process))

(define x (process-launch "ls" #f '() #f #t #t))

(process-wait x)

(display (process-stdout x))(newline)
(display (process-stderr x))(newline)

(display "OK")(newline)

Windowsでも、プロセスが日本語を含む結果を返すと困ったことが起る(SHIFT-JISで結果が返ってくる)。そのうち、Win32のcodepageに対応したtranscoderを提供することで解決したい。。

codecのeqv?

(ここでのcodecはR6RS用語で、文字コード間の変換機構を指す。)
しかし、Win32のcodepageに対応したtranscoderを提供しようとすると、同じコーディングシステムのcodecは互いにeqv?であるというR6RS 8.2.4の規制に対応する必要がある。
moshは、transcoderのTypeを決め打ちにしており、そのままでは拡張の余地が無い。

    enum Type {
        UTF8,
        UTF16,
        UTF32,
        LATIN1,
    };

このTypeを

        if (o1.isCodec()) {
            if (o2.isCodec()) {
                return o1.toCodec()->type() == o2.toCodec()->type();
            } else {
                return false;
            }
        }

のように比較している。
簡単には、TypeをObjectにし、enum値の代わりにシンボルやリストを格納するように変更するのが良い気がする。
Windowsのtext-codecはCode page値で表現することができるので、Objectとして(win32-codepage 932)のようなlistを設定し、eqv?比較の中で再帰的にeqv?するのが好ましい。多分、iconvでは(iconv "eucJP")のように表現されるだろう。
極論として、(他のerror-handling-modeやeol-styleといったプロパティ同様、)codecも単なるシンボルとしての役割りに留めて、transcoderに実際の働きをさせる方が論理的な気がする。