@sosoBOTpi 識別子とSELECTの定義において、マニュアルでは「1個以上の文字列リテラル」を必ず3個書かなければいけないように見えるのですが、2個だったり4個だったりしても良いんですよね?
— Ziphil Shaleiras (@Ziphil) 2017年3月22日
@Ziphil あっそこ補足し忘れてますね…何個でもOKです
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月22日
@Ziphil 修正しました。片方を4個にしました。（根本的な解決になっていないが、自然言語を1行でも増やすとリパライン訳の負担がFafs氏にかかるので）
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月22日
識別子とかの定義のところ、「1個以上の文字列リテラル」だった…。1個限定だと勝手に思っていた。
— Ziphil Shaleiras (@Ziphil) 2017年3月27日
@Ziphil 今のところただ単に（Cのように）連結されるだけです。将来の仕様拡張を可能にするためだけに現状のような仕様となっています。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月27日
@sosoBOTpi なるほど。では、「ident = "a" "b"」と定義された上での「ident "c" -> /x/ /c/」も「"ab" "c" -> /x/ /c/」と等価ですか?
— Ziphil Shaleiras (@Ziphil) 2017年3月27日
@Ziphil はい。変数を使わない場合、それは("a" "b") "c" -> /x/ /c/と書けます。一方、変換文で括弧外に直に書かれた文字列は結合されないので、"a" "b" "c" -> /x/ /c/は数不一致エラーとなります。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月27日
@sosoBOTpi 分かりました。ありがとうございます。
— Ziphil Shaleiras (@Ziphil) 2017年3月27日
@sosoBOTpi リンク先ツイートのように、選択肢の中に文字列リテラルだけでなく識別子が書けると便利だと思うんですが、実装の予定はありますか? ループ参照が怖いですが…。 https://t.co/wj0EKzyAtl
— Ziphil Shaleiras (@Ziphil) 2017年3月30日
「さて、そのほかに、一つ決めておきたいことがあります。（続く）」以降は未定の仕様についてなのでどうでもいい@Ziphil 選択肢に識別子を許すというののみの変更ということですね。実装は昔したので特に問題はありません。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月30日
ループ参照は当然明示的にエラーを吐かせましょう。（というか昔のコードはちゃんと検出して吐いています）
さて、そのほかに、一つ決めておきたいことがあります。（続く）
@sosoBOTpi 「abc」という文字列に「("a" | "ab") -> /x/」を施す場合のように、カッコ内や識別子にマッチする部分が複数あり得る場合はどうなりますか?
— Ziphil Shaleiras (@Ziphil) 2017年3月28日
@Ziphil 長くなるので順を追って説明します。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月28日
@Ziphil まず、これを変換するときには【4-4-2-2.「『文字列の集合とPHONEMEの対』のリスト」のとき】が適用されます。通過前のStat対配列をarrと書くと、「arrと["ab", "a"]という二つのリストを用いての二重ループ」が行われます。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月28日
@Ziphil それぞれの組み合わせについて変換関数が嚙まされ、新たなStat対配列が生まれますが、4-3.の2によりこのうちリストの後の方にある方が採用されます。つまり、("ab" | "a")と書くか("a" | "ab")と書くかによって挙動が変わってきます。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月28日
@Ziphil 意図してはいませんでしたが、仕様を見る限りそう解釈せざるを得ません。これは確かに非常に分かりにくいので、仕様書で具体例として解説しようと思います。的確な指摘、ありがとうございました。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月28日
@sosoBOTpi なるほど、ありがとうございます。基本的に右側から調べるってことで大丈夫ですか?
— Ziphil Shaleiras (@Ziphil) 2017年3月28日
@Ziphil 結論から言うとそうなりますね。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年3月28日
@sosoBOTpi 変換規則の ( | )で1つ以上の文字列となってますが、いまのところひとつの繋げた文字列を指定するのと同じ効果ですかね？
— 炭酸ソーダ (@na2co3_ftw) 2017年4月3日
@na2co3_ftw はい、「そこは」その通りです。もちろん、"a" "bc" "d" -> /a/ /bc/ /d/;では"bc"と"d"を繋げることができません。『しかし、』"a" ("b" "c") "d" -> /a/ /bc/ /d/;は可能で、bとcをつなげたものと同じです。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年4月3日
@sosoBOTpi 左辺と右辺をばらばらに書いてる弊害って感じですねー
— 炭酸ソーダ (@na2co3_ftw) 2017年4月3日
@na2co3_ftw 実際、Haskellのコード内ではわざわざ左辺と右辺を対応させる処理があります。snoj jsonではまとめて書く表記にしようと考えています
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年4月3日
@sosoBOTpi akrantiain変換部解説の4-3.3 は「aの後ろに『bと変換規則をmatchに渡し返ってきたStat」を結合し、返す。」の間違いですか？
— 炭酸ソーダ (@na2co3_ftw) 2017年4月5日
@sosoBOTpi あ、そんなことないですね合ってますね。
— 炭酸ソーダ (@na2co3_ftw) 2017年4月5日
@na2co3_ftw 仕様書の説明で合ってますね。 pic.twitter.com/o5qwdK7fW8
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年4月5日
明示した方が良さそう https://t.co/MpxaaMz8FW
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年4月11日
@sosoBOTpi CASE_SENSITIVEのような環境指定文も有効範囲はそのモジュール内だけですか?
— Ziphil Shaleiras (@Ziphil) 2017年4月11日
@Ziphil はい。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年4月11日
@sosoBOTpi "a" -> /A/; のようにセミコロンは不要なんですか？
— Ritchan(りっちゃん) (@aios_ciao) 2017年4月11日
@aios_ciao 仕様書にある通り、改行が後続する場合はセミコロンを省略できます。
— .sozysozbot.@n足のわらじ (@sosoBOTpi) 2017年4月11日