アカウント名:
パスワード:
期日に拘って納得いかない仕様を盛り込んだり、不足したりするのを潔しとしなかったことかな?
Fortran も 6x は 66 になり、7x は 77 になり、野心的な仕様の 8x は 90 になりました。その後は 95, 2000, 2003, 2008 と続いていますね。
自然言語で仕様を記述するのが難しい訳ではなく、仕様を練るのに掛かった時間なので関係ないと思いますよ。仕様上未定義な部分が無いかとか、矛盾しないかとか・・・リファレンス実装を基にすれば未定義はなくせますが、そうするとバグの検証が必要になり、バグの検証には仕様の検討が必要になり、結局元に戻ります。
よくある「バグではありません. 仕様です」ってのが確定的になるだけですね.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
何が問題だったの? (スコア:0)
ボリュームかな? (スコア:1, 興味深い)
期日に拘って納得いかない仕様を盛り込んだり、不足したりするのを潔しとしなかったことかな?
Fortran も 6x は 66 になり、7x は 77 になり、野心的な仕様の 8x は 90 になりました。
その後は 95, 2000, 2003, 2008 と続いていますね。
Re: (スコア:1, 興味深い)
これだけ揉めた巨大仕様に基づいて現実の処理系を作ったら、混入するバグの数もハンパじゃないはずだろう?
(冗談じゃなく本気でそう思うぞ)
Re: (スコア:1, 興味深い)
自然言語で仕様を記述するのが難しい訳ではなく、仕様を練るのに掛かった時間なので関係ないと思いますよ。
仕様上未定義な部分が無いかとか、矛盾しないかとか・・・
リファレンス実装を基にすれば未定義はなくせますが、そうするとバグの検証が必要になり、バグの検証には仕様の検討が必要になり、結局元に戻ります。
Re:ボリュームかな? (スコア:0)
>仕様上未定義な部分が無いかとか、矛盾しないかとか・・・
ソース記述そのものを定義とすれば、少なくとも矛盾は無くなります.
>リファレンス実装を基にすれば未定義はなくせますが、そうするとバグの検証が必要になり、バグの検証には仕様の検討が必要になり、結局元に戻ります。
ソース記述そのものを定義とすれば、バグの検証など不要です. 他の方法で記述した仕様を元にコード実装したのではないのですから、実装段階のバグが入り込む余地はありません.
一見、いいことづくめのようなソース記述による定義が(簡単なアルゴリズムの議論以外には)用いられないのは、複雑・大規模なコンパイラの仕様記述に用いると記述が複雑になりすぎ、それを人間が理解した上で仕様について議論するのが難しくなるからです. 例えて言えば、開発者によるコンパイラ実装そのものが事実上の言語仕様となっているスクリプト言語のような状態になってしまい、第三者が仕様策定に関わるのが困難になってしまうのです.(やっぱり自然言語で記述した仕様がないと、共通の理解に基づく議論のしようがない)
自然言語での仕様記述が固まった後でリファレンス実装をおこない、それを正式の仕様とするとなると、今度はバグの検証だとかの問題も出てくるので、なかなかうまい方法はありません.
Re: (スコア:0)
それだと仕様上の矛盾や予期できない挙動が定義になるだけだー
それは矛盾や予期できない挙動であってバグではないっていわれても使いにくいのには変わらない
javascriptみたいに仕様決まってるけど実装されてない(コンパイラならまだしも、エンジンがわの実装状況がまちまちで結局使えないとかより)とかよりずっとましだけどさ
Re:ボリュームかな? (スコア:1)
よくある「バグではありません. 仕様です」ってのが確定的になるだけですね.