仕事に使おうと思ったときに足りないもの

nmosh

個人的にはもうpsyntax-moshは使っていない。nmoshは多くの場合に適切なデバッグメッセージを出力するし、キャッシュの信頼性も十分高い。
ユーザにとって最も重要な違いは、psyntax-moshにloadが無いことだろう(不正なテクニックを駆使すれば再現できるが。。 http://d.hatena.ne.jp/mjt/20100225/p2 )。

シェル機能(特にglob)

moshのシェル機能はほとんどドキュメンテーションされず、nmoshのせいで対話シェルライブラリは廃止されてしまった。シェルと同じ見た目を提供するREPLを準備することは重要な課題だと考えている。
よく使うインフラストラクチャ(git, systemtap, gcc, ...)のbindingを書きやすいシステムが必要。

ネットワークとpack/unpack

デバッグプロトコルの類はバイナリコマンドで構成されるのでpack/unpackが無いとプログラミングが面倒。
socket APIは機能するが、シェルのパイプやUSBのI/Oと統合できる抽象化層が必要。

ドキュメンテーションシステム

HTMLのドキュメントはコマンドラインから参照しづらい。これもREPLに統合すべきだろう。

使いやすいrecord

いまだにrecordがつかいこなせない。あまりにもlistを使うので、cadarのような手続きを間違えることは殆ど無くなった。

静的なFFI(拡張モジュール)とcgen

動的ロードでは対応できないライブラリが時折存在する(主にC++で書かれたライブラリ)。
業務で扱うコードの99%はCまたはC++なので、Cのコードを生成(してコンパイル)するための良い手法が欲しい。

仕事で使うと思って改善しておいたもの

ビルド過程

nmoshのビルド過程はmoshにだけ依存している。このため、nmoshに手を入れるのは比較的簡単と言える。moshのVMやpsyntax-moshに手を入れるためにはGaucheが必要になる。
nmosh/nmosh-develブランチはout-of-treeビルドできる。このため、同一ツリーから組込みターゲット向けのmoshとネイティブのmoshの両方を生成できる。

キャッシュ位置のカスタマイズ

nmoshは$HOME以外にキャッシュすることができる。$HOMEをネットワークで共有したりdaemonとしてプログラムを動作させるようなケースでは役立つ。

統合ライブラリの生成

(これは公開していない)。nmoshはライブラリを一つに纏めたキャッシュを生成し、カスタマイズした実行バイナリを生成できる。daemonとして動作させるようなケースではファイルシステムの書き込みそのものを禁止したいケースも有るので有用。
syntax-caseを使っていない場合は、expanderそのものを組込まないnmoshバイナリを生成することもでき、実行バイナリのサイズを微妙に削減できる。