terrario-js / terrario Goto Github PK

• find
• findAll
• 抽出する範囲をマークするAPI
• replace
• replaceAll

など

JavaScriptからライブラリを使用した場合でも、適切にエラーが吐かれるようにする

• APIリファレンス (英語)
  書けてきた

• APIリファレンス (日本語)
  まだない

• チュートリアル (英語)
  翻訳して追加した

• チュートリアル (日本語)
  途中

特定のアプリケーションではあるけど、
比較的実装の難易度が高いのでサポートがあると便利かも

select?引数でインデックスを指定したときに適切な型情報があるとちょっと組みやすくなりそう

初めて issue 投げます、kodai です。

terrario 0.9.0 のライブラリ本体の定義コードを写経していて気づいたんですが、
Parser<T>.map の定義は

map<U>(fn: (value: T) => U): Parser<U> {
  return createParser((input, index, children, state) => {
    const result = children[0].exec(input, state, index);
    if (!result.success) {
      return result;
    }
    return success(result.index, fn(result.value));
  }, [this]);
}

ではなく

map<U>(fn: (value: T) => U): Parser<U> {
  return createParser((input, index, [], state) => {
    const result = this.exec(input, state, index); // <-- children[0] ではなく this に
    if (!result.success) {
      return result;
    }
    return success(result.index, fn(result.value));
  }); // <-- children を空に
}

のように children を空にして this を直接参照するほうが、
children として実際に何が渡されているのか確認するために視線を上下に動かしたり、
children を渡し忘れても静的型チェックが通ってバグることが防げて、素直で読みやすいと思いました。

アロー関数式内での this はレキシカルスコープなので、
パーサの呼び出し場所等で this の参照先が変わることはないはずです。

fork して同様の変更を適用してテストが通ることは確認済みです。
PR 投げることもできるので検討よろしくお願いしますm(_ _)m

ブランチ：https://github.com/0918nobita/terrario/tree/simplify-use-of-createParser

=== / !== のほうが暗黙的な型変換が行われずバグが減らせてオススメです。

ブランチ：https://github.com/0918nobita/terrario/tree/triple-equals

APIセットは現時点で2つある:

• 文字列を入力として受け取るパーサーのAPIセット (string parsers API, 従来のもの)
• トークン列を入力として受け取るパーサーのAPIセット (token parsers API)

これらを同時に使うことは少ないため、パッケージを別々にすることでインストールサイズを削減できる。

使う予定がなくなった

API設計から検討する必要あり
現状では、とりあえず自分でParserのインスタンスを作れば状態を扱える(カスタムパーサー)。handlerの第3引数。

• #4

Env

Terrario v0.7.0

パース失敗結果に以下の情報を含めたい：

• 入力文字列の位置
• 期待していたパーサー名のリスト