指し手 (moves) の要素について
gemmaro opened this issue · comments
JSONの形式 (Version 1.0)に以下の記述があります。
- moves
MoveFormat[]n番目はn手目の棋譜(0番目は初期局面のコメント用)
こちらについて、見方によっては0番目の要素と1番目以降の要素の型が異なることにより、一部のJSONライブラリでJSONからデコードする際に不自由が生じると考えています（例：Elmの Json.Decode）。
そこで、初期局面のコメントはトップレベルのフィールドに移し、指し手を0オリジンで開始するのはいかがでしょうか。
補足：なお、例に挙げた例でも「コメントのみを含む要素」と「指し手の要素」の列挙型を定義し、一時的にその型で一律にデコードすることは可能です。ただし、その場合1番目以降の要素が「コメントのみを含む要素」でないことを検証する必要があります。
Elm についてよく知らないのですが、maybeを使ってdecodeし、使う際には、存在の確認をすることになりそうですね。
指し手に初期局面用コメントが入っているのは、Kifu for JS 等の棋譜リスト部分が念頭にあってのことですね。使い方によってはmovesに入っていないほうが自然と感じられるかもしれません。ところで、moveがないのは投了等の場合(specialがある時)も同じですが、これは対局者による動作なので、指し手(moves)に入れておきたい気がします。そうなると、結局moveから?が取れません。
いずれにせよ、型で表現しきれない暗黙の制約が現在のJKFに多いことは事実です。例えば盤面の升目も {color?: Color, kind: Kind}より{color: Color, kind: Kind} | nullのほうがより曖昧さがないなど。もしJKFのメジャーバージョンアップをする際にはなるべく厳密になるようにすると思います。
ただ、現状では数年間この状態で公開しており(v1公開は2015年)、破壊的変更をすると新しい形式への対応と互換性コードをキープし続けないといけなくなる場合もある(例えばJKFの保存を許している場合)ので、慎重にやりたいところです。（まあ、それほど多く使われているは認識していませんが。）v2のドラフト案を作るというのは有意義かもしれません。
Elm についてよく知らないのですが、
maybeを使ってdecodeし、使う際には、存在の確認をすることになりそうですね。
はい、おそらくご認識の通りかと思います。
「補足」の具体例を挙げると、elm-shogi ではこちらのように通常の指し手とコメントのいずれかとしています。いったん全ての要素を MoveOrComments として、次に jsonKifuFormatKifu で最初のみコメントになっていることを確かめる流れです。
指し手に初期局面用コメントが入っているのは、Kifu for JS 等の棋譜リスト部分が念頭にあってのことですね。使い方によっては
movesに入っていないほうが自然と感じられるかもしれません。
なるほどです。個人的にはやや用途に寄せているように感じましたが、棋譜再生を考えると現行の仕様も自然ではあると思います。
これは対局者による動作なので、指し手(
moves)に入れておきたい気がします。そうなると、結局moveから?が取れません。
たしかにおっしゃる通りですね……。
moves に特殊な指し手を含めることは避けられないとして、Serde > Enum representationsを思い浮かべると、現状はUntaggedですが、それ以外も候補にはなりそうです。
特殊な指し手を moves の外側に移動するとなると、以下が思い浮かびますが、ちょっと微妙です。（特殊な指し手が常に一連の指し手の終端に来るとは決められない可能性がある、など。）
- 特殊な指し手の木構造中の位置をキーに、特殊な指し手の内容をバリューに持つマップ。
- 通常の指し手の次の手が特殊な指し手である場合、その内容を持つ。（意味論的にあまり良くない）
ただ、現状では数年間この状態で公開しており(v1公開は2015年)、破壊的変更をすると新しい形式への対応と互換性コードをキープし続けないといけなくなる場合もある(例えばJKFの保存を許している場合)ので、慎重にやりたいところです。
互換性についてもその通りだと思います。JKFでのダウンロード機能はちょくちょく見掛けるので、もしv2が出た場合も処理系は新旧どちらも対応できることが好ましいかもしれません。