Rebol 2 解析ロジックのバグのようです。最初の入力を見て<
、後続の入力を TAG であるかのように解釈し始めます! 終了が見つかるまで(HTMLタグのように)入力します>
。これに注意してください:
>> length? op-map
== 2
>> op-map/2/1
== <]
<= [>
>> type? op-map/2/1
== tag!
したがって、Rebol の 2 の心には、次の行に沿ってさらに何かを書いた場合に似ています。
op-map: [
>= [<a href="http://hostilefork.com">]
]
ブロックだけじゃない!この問題がある場合、PAREN で発生します。それも:
>> op-map: first [(>= (<) <= (>))]
== (>= (<) <= (>))
>> length? op-map
== 2
Rebol 3でこれを機能させているルールが何であるかは完全にはわかりません.タグ内の括弧を禁止していません:
>> print <[o]>
== <[o]>
...しかし、ソースで一致しない閉じ波括弧を使用することはできませんが、開き波括弧は許容されます。
>> print <]>
** Syntax error: missing "[" at "end-of-block"
** Near: (line 1) print <]>
>> print <[>
<[>
...しかし、引用符で囲まれている場合は、一致しない終了を使用できます。
>> print <"]">
<"]">
さらに見知らぬ人ですが、一致しない閉じ中括弧のみを含むタグをプログラムで作成できます。
>> print to-tag "]"
<]>
そのため、このようなケースではより良い動作をしているように見えますが、「修正」に関して正式なロジックが実際にあったかどうかを判断するのは困難です。新しい規則には、同様の、しかしより微妙な問題のクラスがある可能性があります。それまでの間、安全のために、Rebol 2 でこれらの演算子を扱うときは、文字列からそれらを作成してみることができます。
op-map: compose/deep [
(to-word ">=") [(to-word "<")]
(to-word "<=") [(to-word ">")]
]
もっと冗長です。ただし、文字列区切り記号が存在すると、パーサーは<
and>
をタグ区切り記号として解釈しようとしなくなります。