バグの出にくい言語仕様を考える２

Ｃ＋＋なら、クラスを定義すればモーマンタイ。

>>931
だから、実行時検査ならコンパイラなんていじらずにクラス定義で十分だって話だろ。

>>933
そんなこといちいちオブジェクトでやってたら無駄以外の何者でもないがな。

ほうほう、ではコンパイラだったら、どんな凄いことをしてくれるんだ？

やっと>>911に帰結したか。
>>935
クラスだとオーバーヘッドが大きいけど、現在の組み込み型では不足するような機能を新たな組み込み型として定義できるということだよ。
例えばC++0xのenumクラスとか。

おいおい、結局サブクラスで演算子をオーバーロードすれば良いだけだろ。
コンパイラがやったところで変らんだろ。
組込みだろうがライブラリだろうが、実行時にチェックするんだから変らん。

暗黙的にC++に流れが進んでいるのにﾜﾛﾀ
お前ら少しは他のパラダイムの言語を勉強しろよｐｇｒ

Haskellだって、Lisp(CLOSS)だって、演算子をオーバーロードできるぞ。

>>937 はクラスと組み込み型の違いがわかっていない

>>940
へぇ。じゃあ、賢い君が説明してよ。
範囲チェックの仕組みをライブラリでやるのとコンパイラがやるのとで、
何がどんだけ違うのか。++限定の話は++限定と明示してお願いね。

演算子をオーバーロードして値の範囲を限定する時には、
当然だが演算結果の範囲を指定することになる。

コンパイラが整数型の変数の値の範囲を限定する時には
演算結果ではなく、その変数への代入される値の範囲を指定することになる。

この違い、わかるよな？

そろそろ低レベルの話はやめようぜ

>>942
代入演算子のオーバーロードとの違いを教えてくれないか？

>>944
具体的にどの言語の話だ？

>>945
任せるよ。あんま突飛な例でなければ。

>>942
マシン語レベルで差がでるって言ってるのか？

代入演算子のオーバーロードができる言語なんてごく一部だろうに

もしかして
a=b+c+d+e+f;
てな式があったときに＋演算子オーバーロードなら4回、値の範囲の判定が必要だけど組み込み型なら1回ですむ。
という主張なのかなぁ

特殊な範囲の場合などにCPUのフラグや例外やその他特殊命令等を活用できる可能性のある組み込み型のほうが有利というなら理解できる

>>950 （= >>940 = >>942 = >>945）は、説明になってない、というよりただの空想。

ところで、XML Schemaには、型の拡張(extension)と、型の制限(restriction)がある。
プログラミング言語でもこれを取り入れるのはいい気がする。

そもそも、このスレは空想をするスレ。

実装する気はないという意味では空想だが、
意味を成さないデタラメという意味の空想は対象外。

>>951
D言語(MSのじゃなくて)

値域のチェックに、代入演算子のオーバーロードって話が出てたけど、
型の属性やアノテーションに特別な種類を用意して、
元の型からはダウンキャスト必須にして、
キャストの演算子オーバーロードを用意させる、って方が良い気がする。

int@odd o = (odd)13;
int n = o;//OK
int@odd p = n;//コンパイルエラー
int@odd q = (odd)n;//OK
int@odd r = (odd)24;//実行時エラー


annotation odd restricts int {
　　operator int(n) {
　　　　if (n%2==0) {
　　　　　　throw TypeCastError("%d is not odd number.", n);
　　　　}
　　　　return n;
　　}
}

>>955
書くエンジニアにとっては理解が分かれるけど，本質的には全く変わらない

んで、属性・アノテーションのパラメタが違えば、やっぱりキャストが必要で、
さらにパラメタに変数を使用可能。

double@MKS(0,0,1) time = (double@MKS(0,0,1)) 100.0;
double@MKS(1,0,-1) speed = (double@MKS(1,0,-1)) 10.0;

double@MKS(0,0,1) distanse = 100.0 * 10.0;//コンパイルエラー
double@MKS(0,0,1) distanse = time * speed;//コンパイルエラー
double@MKS(1,0,0) distanse = time * speed;//OK

double@MKS(1,0,-2) velocity = 眠いから略

annotation MKS(int m, int k, int s) restricts double {
　　operator *(double@(m, k, s) other) {
　　　　return (double@(this.m+m, this.k+k, this.s+s)) (this * other);
　　}
　　operator /(double@(m, k, s) other) {
　　　　return (double@(this.m-m, this.k-k, this.s-s)) (this / other);
　　}
}

>>956
いや、代入演算子だと、関数に渡すパラメタのチェックができない。キャストならできる。
ついでに、パラメタまで儲けて、>>957みたいな事も出来る。

ちょっとはHaskellの型と型クラスを勉強してあげてください

そしてやっぱり違いがわからない

Haskellにアノテーションなんてないし、アノ使わず型・型クラスでやるとしても、
Haskellで型パラメタに型じゃなくて値を取るなんてできたっけ？

違いがわからんというのは何と何の違い？

アノテーション使い始めたからアノテーションに括って話してるけど
本題は型の実体に対する制約だろ？

だから、アノじゃなくていいから、
Haskellの型パラメタに、型じゃなくて値を使える？例を示してみてよ。

>>954
kwsk

ググレ糟

キーワードキボンヌ

やっぱりHaskellでしょ。
コンパイルでほとんどの単純バグは弾かれるし、
おまけに、アホにはコードが書けないので◎。

バグを出す奴＝頭が悪い

と
何度言ったら分かるのかな？
おじちゃんわからないよ

（バグを出す奴＝頭が悪い）とかいって思考停止する奴＝頭が悪い

そのかわり、Haskellは一度バグが混入するとデバッグは地獄になるぞ。
かなり単体テストがんばらないと使いものにならない。

>>969
そうなのか…単体テストで頑張るのか…ちょっと興味があって調べて見たけど
Bug がどこに潜んでいるか検出するとして、

1. コンパイラが頑張る
　http://d.hatena.ne.jp/nekora/20080405
2. テストカバレッジで頑張る
　http://d.hatena.ne.jp/higayasuo/20080404/1207295959

静的型付け言語 と 動的型付け言語で
アプローチの仕方が変わってて、結局

rails テストカバレッジ
http://d.hatena.ne.jp/zariganitosh/20080306/1204791789
Ruby 型推論
http://rubykaigi.tdiary.net/20080626.html#p07

経験則の占める割合を見積もると、

http://d.hatena.ne.jp/ku-ma-me/20080623
http://blog.livedoor.jp/lisper/archives/cat_387238.html?p=2

文芸的プログラミングとか、凄く初等的な(古典的な?)方法に
行きつくとか、そんな落ちが待ってるような…むぅ。もうちょっと調べる

ある意味perlと一緒だな

バグはコード行数に比例する。
注意すべき点がマジックナンバー7±2 を超えて、プログラマの脳内から
溢れるために、バグは起こるのだ。

それは脳の仕様なので、プログラマが注意することで避けることはできない。
対策は、コード行数を減らすことだ。

ようするに、バグを出す脳はそれが仕様なので不可避ってことか。
そういう人はコーディングしないのが一番ってことだね♪

>>972
ほらそんなに書くから頭バグっちゃってるじゃない・・・///

デジタル的な技術に依存している仕組みでしか、仕様を考えられないのが
根本的な問題点である。

よくわからんけど、７行、いや、７トークン以上のプログラムが書けない言語を作ればいいわけか。

Perl はバグが少ない言語だ。
第一に、Perl のソースコードは他の言語より行数が少ない。
第二に、行数が少ないことの利点を理解しない大多数のプログラマは
Perl のソースコードを書けない。

ようするに机の上をきれいにすればいいということですね？

すべては無へと帰す

Perlはなにか触れてはいけないもののような気がして勉強するのを敬遠していたが、
バグの出にくい言語仕様を考える上で避けて通れないような気もする。

J言語もやっておいた方がいい