HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2012
1008
甘酒バグでしょうか・・・?19解決


甘酒

リンク

2012/10/8(Mon) 00:36:48|NO.49843

ウンコード・マニアというサイトにて
http://unkode-mania.net/view/50719b8ea753b5de7a000004
このようなコードを投稿したのですが、某氏が「ん?」と思いまして、下記のようなコードを作成しました。

a = 4 if (a == 2){ print "A" }else{ print "B" }else{ print "C" }
すると、「B」が表示されます。
そして次に、

x = 1 y = 1 if(x=1){ mes "1" }else{ mes "2" }else{ mes "3" }
しかしこれだと、「1」と「2」が表示されてしまうのです。
これはバグなのでしょうか?



この記事に返信する


ma_comu

リンク

2012/10/8(Mon) 00:43:54|NO.49844

以下のコードで実験を行いましたが、elseはあくまで直前の分岐が実行されなかったらという基準だと思われます。

x = 1 y = 1 if(x=1){ mes "1" }else{ mes "2" }else{ mes "3" }else{ mes "4" }else{ mes "5" }
結果
1
3
5



甘酒

リンク

2012/10/8(Mon) 00:45:18|NO.49845

どうやら3.31正式版がリリースされたようですね。気づきませんでした
http://www.onionsoft.net/wp/archives/786
3.31RC1版で上記の症状が発生しましたが、正式版でも修正されてないようです。



てん

リンク

2012/10/8(Mon) 02:04:00|NO.49846

バグというか言語仕様をこえただけな気がします。
最初のelse以降は意味が定義できませんから、これは構文エラーと呼んだほうがいいのでは。



てん

リンク

2012/10/8(Mon) 02:11:22|NO.49847

問題を簡単な形に帰着してみました。

mes "検証:真の場合"//A,Cが表示される if 1 { mes "A" } else { mes "B" } else { mes "C" } mes "\n" mes "検証:疑の場合"//Bが表示される if 0 { mes "A" } else { mes "B" } else { mes "C" }

結局、elseが「〜ではないなら」の意味合いを持つとしたら、
elseのelseは (条件式)は真「ではないのではない」なら実行されるということになります。
ですから、elseが偶数回続いた後の命令文は、条件式が真のときに実行されて、何ら問題は無いかと。


まぁ結論言うと、「こんな表記するな」って言うことですね。

結局、開発者が想定していないことを利用者がして「おい誤作動起こしたぞ!」ってなったら
それは、開発者の想定が甘かったのか、利用者が異常な利用をしたのかのどちらかです。
今回は異常利用と言わざるを得ないでしょう。



hoge

リンク

2012/10/8(Mon) 03:35:56|NO.49848

だとすると

x = 1 y = 1 if(x=1){ mes "1" }else{ mes "2" }else{ mes "3" }

はなぜ"1"、"2"なのか。



KA

リンク

2012/10/8(Mon) 04:15:53|NO.49849

>>なぜ"1"、"2"なのか

else が多いからでしょう。



通りすがり

リンク

2012/10/8(Mon) 04:40:12|NO.49850


x = 1 y = 1 if(x=1){ mes "1" }else{ mes "2" }else{ mes "3" }

で表示されるのは"1", "3"の2つでしたよ?
先の結論でも、elseは直前の分岐を通らなかったら実行する、ということになってたかと思います。

スレ主さんの誤字か何かだと思うんですが、"1"、"2"が出力される環境があるということでしょうか?



KA

リンク

2012/10/8(Mon) 09:07:38|NO.49853

>>表示されるのは"1", "3"の2つでしたよ
失礼、確かにその通りでした。
「仕様外の使い方なので、どうなるか分からない」という意味です。

そもそも質問者は、どういう結果を期待していたのかが不思議です。
先に出ているように、見やすく編集して質問してくれれば良かったのに。



ヒロソフ

リンク

2012/10/8(Mon) 12:08:20|NO.49860

スレ主の知り合いです。
これについてですが
C/C++などの他言語のコンパイラはコンパイルエラーになるのに
なぜHSPのコンパイラではコンパイルエラーにならないのかという疑問です。



てん

リンク

2012/10/8(Mon) 12:45:33|NO.49863

だから仕様なんですって
何をエラーとして、何を正常であると定義するのか、その線引きはコンパイラが決めます。
当然、コンパイラによってエラーとなる時もあれば、エラーを通過するときもあります。
例えばC言語だと、複数種類のコンパイラがあって、コンパイラAでは通ったコードがコンパイラBだと通らない
なんて事もあります。

ですから、
>>なぜエラーにならないのか
というのが「エラーにならない原理」だとすれば、それは、「そのように定義されているから」です。

「エラーにしなかった意図」を質問しているのだとすれば、それはちょっと不明ですね。
おにたまさんに聞くのが一番早いかと。


まぁ個人的には論理体系としては整っているからこれは悪くはないと思いますけどね。
スレ主のウンコードの例だとバグフィックスがしにくくはなると思いますが。



hoge

リンク

2012/10/8(Mon) 15:31:32|NO.49869

> だから仕様なんですって

「コンパイラが通すから仕様」という論法自体が既にアレなんだが。。

まぁいいや、ここは「仕様」という表現にしよう。

だとして、ここで疑問を呈してる人間の殆は、

 「どうしてそんな残念な仕様を作っちゃったのかね。
  意図的?考慮漏れ?考慮誤り?」

という視点の話をしてるんだと思うんだが。
「てん」さん、話題について行けてますかね。


何も疑問を持たずにNO.49863のような返答を入れちゃうことには、
正直なところ少々危険を感じる。



レノス

リンク

2012/10/8(Mon) 16:03:33|NO.49871

> なぜHSPのコンパイラではコンパイルエラーにならないのか
単に忘れているだけでしょう。
バグトラックに書いておけばいつか修正されるかもしれませんよ。



てん

リンク

2012/10/8(Mon) 16:18:11|NO.49872

確かに。仕様と言い切って思考停止していたら話が先に進みませんね。失礼しました。

「エラーとしてはじく基準を誰が決めるのか」の議論を先にしたかったのです。

ヒロソフさんのレスによると 論理的におかしい、と人間が感じた表現はコンパイラがはじく になるかと思います。つまり人間が基準を決めていることになります。

実際の仕組みとしては コンパイラが、おかしいと感じたものをはじく 仕組みになっています。人間がいくら感覚的に違うと思っても コンパイラが通したものは「基本的に」正解です。

ですから、バグと呼ぶのは語弊があるのでは。 むしろ、仕様がクソ、改善しろ、という話をすべきでは? という話をしたかったのです。

簡単に言えば

この言語の作者、おにたまさんが作った言語ルールは定義であり この言語ルールこそが、構文として正しいか誤っているかを見定める基準になる。 基準が間違ってるというのはそもそも議論するものではない。

という話です。

ただ、この論法は潜在的に 「コンパイラの設計ミスでエラーが通過してしまってもそれは仕様と言い切っていいのか」 というご指摘の通りの問題を含みます。

というわけで、「最終的には」こいつが
設計された仕様
なのか
意図せず起こってしまったバグなのか、コンパイラの挙動を改善すべきか
人間の感覚も含め照らし合わせるて議論する必要があります。

その点の議論にはまだ話は進んでいなかったかと思うのですが。
多分まだ、これはバグか?(原理として)なんでこんなことが起こるの?っていう段階だったかと。



晩御飯

リンク

2012/10/8(Mon) 16:47:34|NO.49873

仕様や規格と実装をわけて考えるところから始めてね



KA

リンク

2012/10/8(Mon) 19:02:41|NO.49877

今まで誰も騒いで無いから、良いんじゃないかな。

仕様書というマニュアルに規定されていないし、そういう使い方は出
来ないと思っていたから、騒がれずに修正もされなかったのでは。

変な所で悩んでしまう可能性は有るので、修正された方が良いのは確
かでしょう。

でも規定されていない書き方を、ここにバグ扱いで質問するのはどう
でしょうね。問題提起するのは良いんだけど、事前にマニュアルなど
で確認していない事の方が、個人的には悲しい思いです。



hoge

リンク

2012/10/8(Mon) 19:04:25|NO.49878

ええと、結局何を主張したいのか分からなかったので教えてね。

> 実際の仕組みとしては コンパイラが、おかしいと感じたものをはじく
> 仕組みになっています。

うん、ここまでは至極当り前のことを分かりやすく言ってるだけだよね。
で、

> 人間がいくら感覚的に違うと思っても コンパイラが通したものは
> 「基本的に」正解です。ですから、バグと呼ぶのは語弊があるのでは。

なんでこういう飛躍になるんだろう。

貴方の話をみると、どうも「コンパイラが仕様を忠実確実に100%再現し切っている」
という、なんの根拠だかよく分からない不思議な前提を置いてるように見える。

もちろん、実際にそうなのかも知れないけど、そういう考え方自体は非常に
「残念なこと」だと思うよ。

もしかすると、貴方は気づいてないのかも知れないが、開発者さんに失礼なことを
言ってるかもしれない。



KA

リンク

2012/10/8(Mon) 19:29:15|NO.49879

荒れ始める前に

「仕様外のコードでコンパイルが通ってしまうバグ」

と言う事にして、おひらきにしませんか?



てん

リンク

2012/10/8(Mon) 20:01:17|NO.49880

なんか、すいません。荒らすつもりはないのですが、結果的に荒らす形になってしまいました。

私はただ、コンパイラという形でおにたまさんが示した定義こそ正解である、という考え方を提示しようと言うつもりで先の説明をさせてもらいました。
それがバグなのか、意図するところなのかはおにたまさんだけが知るところであり、我々ユーザーが
バグと決め付けるのはいかがなものかという考え方です。
ただ、それがおにたまさんに失礼に当たるということまでは、どうにも思慮が及びませんでした。

すいません。お騒がせしました。



hoge

リンク

2012/10/8(Mon) 20:42:16|NO.49881

> それがバグなのか、意図するところなのかはおにたまさんだけが知るところであり、
> 我々ユーザーがバグと決め付けるのはいかがなものかという考え方です。

貴方は貴方で、真っ先に「仕様だ」と決め付けをしてたでないの。
結局上から下まで、貴方の主張の軸足が分からんじまいだった。

あと、「決め付け」で物を語っていた人間というのは、果たして誰のどの発言を
指してたんだろう。単に貴方が決め付けてるとミスリードしてただけのような印象。

何はともあれ、これにて消えます。



ONION software Copyright 1997-2023(c) All rights reserved.