まだ、NYAGOS 4.2 は出せない

Luaインスタンスのクローンについては今のところ問題は出ていない。 無論、不具合の一つ二つは出たが、 確認当日中にあっさりと解決できて、この程度で済むのなら上出来だったと思う。

また、もう一つの懸案も解決できた。

これは Args[] を Windows 風の一枚引数文字列に展開する際の二重引用符の扱い方のために、 FIND コマンドが期待するような「検索文字列の前後には二重引用符をつける」という仕様を呼び出し時に満たすことができないという問題だ。

この issue 自体は最近起案したものだけれども、Args[] の展開を自前でやるというのは前々からの課題だった。 やろうと思うと、API の CreateProcessW を呼ぶライブラリから作られなばならないと思っていたので、 すぐには実現できないと思っていた。 が、Go のライブラリのソースを見てたら、実は Args[] の展開を自分でやる手段が提供されていることが分かり、 思わぬタイミングで懸案は解決した。 詳細は前に書いた記事を参照のこと。

というわけで、結構大きい課題が二つの解決して、満を持して 4.2.0 をリリースしたいところだが、もう一つ欲張りたいところがある。

それは foreach とか if ~ then ~ endif とかの制御構文。 nyaos-3000 は、その辺をちゃんと実装していたが、nyagos は Lua で全部やればいいからと完全にスルーしてしまった。 ところがユーザの傾向を見ると、Lua だからカスタマイズの仕方が分からない、調べれば分かるが、学習コストに見合わないという人が多い。 完全に計算違いだった。

foreach を実装するには、コマンド列の任意の位置へ移動できなくてはいけない。 そのためには shell パッケージは単品のコマンドの実行だけではなく、前後のコマンドも含めたセッションも管理して、 コマンド列の移動可能箇所をマーク&移動できるようにしなければいけない。 これまでは一連のコマンド列の管理は mains パッケージ(旧mainパッケージ)で行っていた。 昨日・今日で、それをようやく shell パッケージ(旧interpreterパッケージ)側に移動した。 結果、mains パッケージからは「shell.Loop(コマンド列読み込みオブジェクト)」だけを呼ぶだけとなった。

これ、日本語で書くと簡単に見えるが

  • shell パッケージは Lua へ依存させてはいけない。Lua への依存は mains パッケージが隠蔽するか、注入するかしてやらないといけない
  • インタラクティブシェルか、スクリプトかの管理に shell パッケージは関与してはならない

とか制約が多くてたいへんだった。が、最終的にはコマンド列読み込みインターフェイス

package shell

type Stream interface {
    ReadLine(context.Context) (context.Context, string, error)
    GetPos() int
    SetPos(int) error
}

をベースにうまいこと実装できた。おかげで shell パッケージは奇麗さを維持できた。 が、mains パッケージはかなりグダグダである。 「依存性」が全部 mains パッケージに集まってるのだから仕方がない。