Orz日記 by Akio Morita

_ [雑記]本日よりサマータイム突入

3月最終日曜日となる本日午前1時からサマータイムへ突入しました。

現在の日本との時差は7時間です。

街中の一部の時計は、サマータイム突入前の時刻を指しているものが 見受けられる所を見ると、切り替えは自動ではない模様。

_ [SAD]スロットバグの修正

前にスロットの罠で報告した(#0.5)&が segmentation faultになる件だが、原因が分かったので修正した。

実は、スロット関数を使った表現Slot[0.5]&では、問題なく 受け入れられるのだが、この違いは、スロット演算子をsrc/tfeexpr.f経由で スロット関数に変換する過程で不正な参照を持ったスロット関数を 生成していることが原因でした。 また、表示はスロット演算子形式になるので、ToString[]して ToExpression[]すると問題が発生する罠。

詳細は、Ticket-11を 参照のこと。

_ [SAD]数値リテラルのトークン化の仕様修正

前にスロットの罠で報告した(#1.5.#2)&が ...#でプロンプト待ちになる件だが、原因が分かりました。

tfetok()の返すトークンを追跡したところ、#の次のトークンは 1で始まるので数値リテラルをトークン化する eval1()が 呼び出されるが、このサブルーチン何を思ったかトークン中に 2個目の.が出現するとそのままリターンしてしまいます。 したがって、#の次のトークンが謎文字列1.5.#2になることに...

eval1()は.で開始する実数リテラルをサポートするようなので、 この2個目の.を検知してアボートするロジックは、 RepeatedNull(..),Repeated(...)演算子を 見つけた際に実数リテラルとしてトークン化せずに上位ロジックに 制御を戻すためのものと思われますが、.の連続性を 検査していないので誤爆している模様です。

現在の実装の挙動はおかしいので仕様レベルの修正をRevision 1658で入れました。

具体的には、連続する.(つまり..)を見つけたら その直前で実数リテラルが終了するものと解釈します。 したがって、..で開始する文字列は実数リテラル部の長さが0と なるのでm=0を返して終了。 .を含む実数リテラルに.が継続した形2.5.は、 2.5までが実数リテラルとして解釈され、続く.は次のトークンの 開始文字になります。 また、.を含まない実数リテラルに..が継続した形12..は、 実数リテラル12と継続文字列..に分割されます。 なお、.の後に[^.eEdD0-9]が継続する場合は、.までが 実数リテラルとして解釈されるので、(2.A)は(, 2., A, )とトークン化され、Times[2., A]と解釈されます。

SADには正規の文法定義な存在していないので、バグと言うのも微妙なのですが、 標準的な表現には影響しないはずです。

ただし、ToString[]がコンソールへのエコーバックで使われる短縮形では、 各リテラルの短縮表現と後続リテラルの短縮表現を結合した際に生じる 文法的な曖昧性を考慮しないので、変換ToExpression[ToString[#]]&が 恒等変換で無いのは注意が必要です。

たとえば、(#2.0.#3)&はDot[#2.0, #3]&と解釈されますが、 ToString[]の結果は短縮表現((#2.#3)&)となり、 これをToExpression[]で解釈するとTimes[#2., #3]&と解釈されて しまいます。