2

Rebol 3がいつでもオープンソースになることを記念して-今（？）、私はそれをいじりに戻っています。演習として、PARSE方言で独自のJSONパーサーを作成しようとしています。

Douglas Crockfordは、JSONの発見に対するRebolの影響を認めているので、簡単だと思いました。中かっこを角かっこに置き換えてすべてのコンマを取り除く以外に、文字列で単に使用することの障壁の1つは、Rebolのトークナイザーの文字列のように見えるものを使用するLOADという事実です。SET-WORD!その後の違法な漂遊コロン：

{
    "key one": {
         "summary": "This is the string content for key one's summary",
         "value": 7
    },
    "key two": {
         "summary": "Another actually string, not supposed to be a 'symbol'",
         "value": 100
    }
}

基本的に、私は似ているすべてのケースを見つけて、コロンだけが続かない一致する引用符のペアを残しながら、"foo bar":それらを変換したいと思いました。foo-bar:

私がPARSEでこれに取り組んだとき（私は原則としてかなりよく理解していますが、まだあまり使用していません）、いくつかの質問が出てきました。しかし、主に、コードにエスケープして、パーサーの下からシリーズを変更できる場合の約束された条件は何ですか...特にRebol 3では？より一般的には、それは「仕事に適した種類のツール」ですか？

これが私が試したルールで、タスクのこの部分で機能するようです。

any [
    ; require a matched pair of quotes & capture series positions before
    ; and after the first quote, and before the last quote

    to {"} beforePos: skip startPos: to {"} endPos: skip

    ; optional colon next (if not there the rest of the next rule is skipped)

    opt [
        {:}

        ; if we got to this part of the optional match rule, there was a colon.
        ; we escape to code changing spaces to dashes in the range we captured

        (
            setWordString: copy/part startPos endPos
            replace/all setWordString space "-"
            change startPos setWordString
        )

        ; break back out into the parse dialect, and instead of changing the 
        ; series length out from under the parser we jump it back to the position
        ; before that first quote that we saw

        :beforePos

        ; Now do the removals through a match rule.  We know they are there and
        ; this will not cause this "colon-case" match rule to fail...because we
        ; saw those two quotes on the first time through!

        remove [{"}] to {"} remove [{"}]
    ]
]

それは大丈夫ですか？オープンコードで外部解析を台無しにする可能性はありますかchange startPos setWordString...この場合でない場合は、微妙に異なるものになりますか？

いつものように、教訓的な「この他の方法の方がよりクリーン/より短い/より良い」アドバイスをいただければ幸いです。

PSなぜそこにないのreplace/all/partですか？

4

3 に答える 3

2

のような新しいキーワードはchange、この種のことを容易insertにするはずです。removeこのアプローチの主な欠点は、シリーズをプッシュする際のレイテンシーの問題だと思います（操作するよりも新しい文字列を作成する方が速いという言及を見てきました）。

token: [
    and [{"} thru {"} any " " ":"]
    remove {"} copy key to {"} remove {"} remove any " "
    (key: replace/all key " " "-")
]

parse/all json [
    any [
        to {"} [
            and change token key
            ; next rule here, example:
            copy new-key thru ":" (probe new-key)
            | skip
        ]
    ]
]

期待どおりに変更を機能させることができないように見えるため、これは少し複雑です（changeではなくのように動作します）が、理論的には、これらの線に沿って短くして、かなりクリーンなルールchange/partを設定できるはずです。理想的なものは次のとおりです。

token: [
    {"} copy key to {"} skip any " " and ":"
    (key: replace/all key " " "-")
]

parse/all json [
    any [
        to {"} change token key
        | thru {"}
    ]
]

編集：周りの別のファッジchange-

token: [
    and [{"} key: to {"} key.: skip any " " ":"]
    (key: replace/all copy/part key key. " " "-")
    remove to ":" insert key
]

parse/all json [
    any [to {"} [token | skip]]
]
于 2012-10-19T15:13:54.193 に答える
2

もう1つの方法は、解析をEBNFを使用するコンパイラーコンパイラーとして考えることです。R2構文を正しく思い出せば：

copy token [rule] (append output token)

正しい構文を想定{"}し、文字列には含まれていません。

thru {"} skip copy key to {"} skip
; we know ":" must be there, no check
thru {"} copy content to {"} skip
(append output rejoin[ {"} your-magic-with key {":"} content {"} ])

より正確にはto、char by charの代わりに：

any space  {"} copy key some [ string-char | "\" skip ] {"} 
any space ":" any space {"} copy content any [ string-char  | "\" skip ] {"} 
(append output rejoin[ {"} your-magic-with key {":"} content {"} ])
; content can be empty -> any, key not -> some

string-char{\}and {"}、構文以外のものを含む文字セットになりますか？

R3がまだこのように機能するかどうかわからない...：-/

于 2013-01-15T17:50:47.407 に答える
0

他の人が質問に答えたのでparse、私はPSに答えます：

に追加されたことのない提案されたオプションがいくつかありますreplace。主な理由は、オプションの処理にオーバーヘッドがあり、この関数がすでに持っているオプションを処理するために、いくつかの興味深い最適化がすでに必要であるためです。APIを少し改善したら、関数をネイティブに置き換えようとしました。これは基本的にreword関数と同様の状況であり、最近まで最終的なAPIを決定していませんでした。なぜなら、replace私たちはまだその議論さえしていません。

この/partオプションの場合、これまで誰からも提案されたことがなく、既存の内部長の計算と統合するのは概念的に少し厄介かもしれません。/partオフセット参照の代わりに整数だけで、制限されたオプションを持つことが可能です。/part内部で計算された長さよりも長さが優先されるのがおそらく最善でしょう。それでも、調整されたAPIを使用することになった場合は、/partオプションは必要ないかもしれません。

于 2013-06-19T02:59:31.013 に答える