【超高速】C/C++に代わる低級言語を開発したい 6

1 ：デフォルトの名無しさん：2010/05/16(日) 22:16:21

70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。

そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。

既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 5
http://pc12.2ch.net/test/read.cgi/tech/1273199795/

2 ：デフォルトの名無しさん：2010/05/16(日) 22:17:13

◆新言語の要件 v0.1◆

（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能

◆主な要望◆

・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件）　＞　構文の美しさ(読みやすさ、学習の容易さ)　＞　再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。

3 ：デフォルトの名無しさん：2010/05/16(日) 22:31:03

◆新言語の名称（仮）◆

Programming Language I

◆新言語の位置づけ◆

Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。

そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。

◆新言語でのリソース管理方針◆

・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい

※GCは手段であって上記が満たされていれば必ずしも必須ではない。

4 ：デフォルトの名無しさん：2010/05/16(日) 22:32:11

PL/I

5 ：デフォルトの名無しさん：2010/05/16(日) 23:22:18

このスレたてたやつアホすぎる。

6 ：デフォルトの名無しさん：2010/05/16(日) 23:42:01

アイちゃんカモーン

7 ：デフォルトの名無しさん：2010/05/16(日) 23:47:18

schemeのように言語仕様の大部分を最小限の言語実装の上に構築できればいいのにな。

8 ：デフォルトの名無しさん：2010/05/17(月) 00:27:36

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

9 ：デフォルトの名無しさん：2010/05/17(月) 00:33:03

「ハードウェア制御のような低レベル処理を行える言語」ってのが大前提なのに、
未だにVMだのJITだの言いだす奴らが後を絶たない。

10 ：デフォルトの名無しさん：2010/05/17(月) 01:12:42

>>9
C#で書かれたプログラムでHDDのファームウェアを更新するのだってある時代だぞ

11 ：デフォルトの名無しさん：2010/05/17(月) 01:15:03

ファームをC#で書いているわけではないだろ。

12 ：デフォルトの名無しさん：2010/05/17(月) 01:29:24

ファームは機械語で書かれてる
Cでも大きすぎる

13 ：デフォルトの名無しさん：2010/05/17(月) 01:34:49

少なくとも一つ以上のメーカーで、HDDのファームはCで書かれている。

14 ：デフォルトの名無しさん：2010/05/17(月) 02:33:16

>>13
kwsk

15 ：デフォルトの名無しさん：2010/05/17(月) 03:04:00

C++は除外しろっつーの。あんなものに代わる必要などない。

16 ：デフォルトの名無しさん：2010/05/17(月) 04:24:52

既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。

17 ：デフォルトの名無しさん：2010/05/17(月) 07:15:11

算術演算以外の演算子は後置ってどういうこと？

18 ：デフォルトの名無しさん：2010/05/17(月) 07:44:10

>>7
SC CiSE Template Haskell MetaOCaml CamlP4
Prologのマクロ、演算子定義
Dylan Nemerle Boo Cyan
Cleanで作るインタプリタ C式 Compact ftdop4

19 ：デフォルトの名無しさん：2010/05/17(月) 07:57:40

6ってことは、前に5スレは消費したんだよな
流れとまとめはどこだ

20 ：デフォルトの名無しさん：2010/05/17(月) 11:19:42

>>19
全部似たような流れの糞スレと見た

21 ：デフォルトの名無しさん：2010/05/17(月) 11:38:42

C言語レベルの低級言語なのにガベコレつくれとかそういう話だったな

22 ：デフォルトの名無しさん：2010/05/17(月) 12:24:17

発想というか試みとしては評価したいが
当然64bitマシン対応だよな

ニーモニックを直接書けるようメモリアドレス確保する専用の汗・逆汗変換機能が欲しいかもしらん

23 ：デフォルトの名無しさん：2010/05/17(月) 14:31:54

>>21
C--がそういうコンセプトだし珍しくなかろう。
竹内先生はOSやアーキテクチャがガベコレを支援して然るべきと言ってるし。

24 ：デフォルトの名無しさん：2010/05/17(月) 15:15:49

OS書くといっているのに、また、OS前提の話をはじめる。

25 ：デフォルトの名無しさん：2010/05/17(月) 16:33:36

アイちゃんばっか

26 ：デフォルトの名無しさん：2010/05/17(月) 17:52:33

ゆとりには自分でメモリ管理なんてできないんです。
ガベコレが無いとメモリリークで落ちるんです。
わかってください。

27 ：デフォルトの名無しさん：2010/05/17(月) 17:56:30

だからおまえはOSも保護もなにもない8086で仕事してればいいの

28 ：デフォルトの名無しさん：2010/05/17(月) 19:31:54

ガベコレ有りでも無しでも書ければいいよね

29 ：デフォルトの名無しさん：2010/05/17(月) 19:44:19

仕事でCでRAIDカードのファーム書いてた
ごく一部アセンブラ。C++ではない。
性能的にはハードの理論値90%以上は出せた
新言語はこれ最低ラインにしてくれ

30 ：デフォルトの名無しさん：2010/05/17(月) 20:22:03

性能の大部分は最適化にかかってると思う

31 ：デフォルトの名無しさん：2010/05/17(月) 21:38:33

>>29
SiliconImageのドライバの出来が悪いのはCで書かれてるからなのか

32 ：デフォルトの名無しさん：2010/05/18(火) 00:45:09

>>26
ガベージコレクションあってもメモリリークで堕ちることはあるが。

33 ：デフォルトの名無しさん：2010/05/18(火) 03:13:18

>>30
その通り。最終的にはプロファイルしながらuS以下の単位で手動オプティマイズ
>>31
SIじゃないよ。もっとマイナーｗ
でドライバじゃなくファームなｗ

34 ：デフォルトの名無しさん：2010/05/18(火) 14:16:28

だから前スレ埋めてからにしろ糞虫共

35 ：デフォルトの名無しさん：2010/05/18(火) 18:44:15

golangのunsafeいいけどGC有りが前提なんだよな。
http://golang.jp/pkg/unsafe

36 ：デフォルトの名無しさん：2010/05/18(火) 18:46:11

golangでロードバランサーのファーム書いてよ

37 ：デフォルトの名無しさん：2010/05/18(火) 18:58:38

GC有り無し混在させつつGCは完全なGCをしたい。
struct A { A a = new A(); A a2 = gcnew A();}
A a1(){ return new A(); }
A a2(){ return gcnew A(); }
A a = a1();
a = a2();
というようなことをしたとする。
どれがGC対象でどれがGC対象ではないかはアドレスで判断できる。
しかし、gcnewした値をnewした変数が参照している場合
GC対象にするにはどうしたらいいのだろう？
gc対象外のオブジェクトは保守的にGCする？
それとも、すべてGC対象にしつつ
deleteすればたとえ参照が残っていても開放する？
すべてをGC対象にする場合は完全に型情報を把握できる？
完全に型情報を把握できない場合はどうする？保守的GC？

38 ：デフォルトの名無しさん：2010/05/18(火) 19:29:40

んなもんGCに任せるだけだよ
それよりで混在の問題はGC型で確保したデータを返すゲネレータパターンの引数にデストラクタ処理されるデータを渡した場合の不整合のほうが深刻

39 ：デフォルトの名無しさん：2010/05/18(火) 19:31:09

>>35
コンサバティブだと思う
簡単なプログラムでだが
mmapしたメモリをsliceに
貼り付け出来て走ってたが。

40 ：デフォルトの名無しさん：2010/05/18(火) 23:03:02

分かってる振りしてレスするスレ

41 ：デフォルトの名無しさん：2010/05/19(水) 01:32:04

GCアリ用に書いたコードをGCナシ用に簡単に書き変えられたらいいな。
あと、その逆も。

42 ：デフォルトの名無しさん：2010/05/19(水) 01:37:07

それが無理だって話を今してるわけだが

43 ：デフォルトの名無しさん：2010/05/19(水) 01:40:07

無理というのは、そういう構文を設計できないという意味？

44 ：デフォルトの名無しさん：2010/05/19(水) 01:56:53

無理ではないが面倒

45 ：デフォルトの名無しさん：2010/05/19(水) 02:06:15

面倒というのは、
GCアリ用に書いたコードをGCナシ用に簡単に書き変えられる構文を設計するのが面倒ってこと？
それとも、
GCアリ用に書いたコードをGCナシ用に書き換えるのはどんな構文にしたとしても常に面倒ってこと？

46 ：デフォルトの名無しさん：2010/05/19(水) 02:22:40

GCありなら基本ありがいい。混在の構文とかややこしいだけ
でも管理エリア外のメモリはGC対象外ってことでいけんじゃね
ていうか、GCの問題はメモリ以上に、実行が途中で不定な時間止まることだろ

47 ：デフォルトの名無しさん：2010/05/19(水) 02:35:17

static変数がある言語でのGCなんておまじないみたいなもの

48 ：デフォルトの名無しさん：2010/05/19(水) 11:00:09

たとえば、言語仕様上は記憶クラスとしてcollectableを指定した変数はGCに回収されるようにしてはどうだろうか。

collectableとstaticやautoは同時指定できず、無指定時のデフォルトはauto指定。
行頭で collectable: と指定すれば、それ以降のスコープブロック内では無指定でcollectable指定。
同様に collectable{ ... } とすれば、そのブロック内では無指定でcollectable指定。
autoやstaticも同様に指定できる。

GCの実装はコンパイラ依存とし、既存GCライブラリのラッパーであっても構わないし、OSに投げてもVMに投げても良い。もちろん独自実装だって構わない。

GC指定された変数を非GC指定へ渡す際は要キャスト(というか、ハードコピー)とすれば、不整合は起こりにくく出来るのでは？
もちろん、その場合はメモリをちゃんとプログラマ側で確保してあげるべきで、自動化してはいけない。
その際の構文は...

('A`)ﾉｼ　ｱﾄﾊﾏｶｾﾀ

49 ：デフォルトの名無しさん：2010/05/19(水) 13:25:42

>48
>不整合は起こりにくく出来るのでは？
それだと不整合は起こりえるので全く使い物にならないから
言語サポートしたとはいえない
よく考えてから書け

50 ：デフォルトの名無しさん：2010/05/19(水) 13:30:28

new と gcnew の話をしているやつはC++/CLIで何か不都合があるのかな？

51 ：デフォルトの名無しさん：2010/05/19(水) 14:58:04

>>48
ブロック内でGCとか意味ないってことに気づけよ
変数単位じゃなく確保されたメモリ自体の管理だからな

gcnewとかいう半端な仕様なんて汚いだけ
ここはファームやドライバ書ける言語の話じゃねえの
Windowsしか知らないでプログラム組むならなんぼでも選択肢あんだろ

52 ：デフォルトの名無しさん：2010/05/19(水) 15:48:53

>>40
保守的GCだと管理外は回収されないってだけだよ
中みてないけどｗ
プログラム的には注意が必要だが便利ではある
特にでかいファイルをmmapできると行儀よく読むより速度が2桁変わるしな

53 ：デフォルトの名無しさん：2010/05/19(水) 15:53:22

GCの話してるときに、獲得メモリーの大きさで議論するのは
少し違和感があるんだけど、Windowsって大きなメモリー領域確保
すると遅くなるの？

54 ：デフォルトの名無しさん：2010/05/19(水) 17:00:33

大きさだけじゃなく、使い方かね
ほとんどのシステムで大きなメモリ領域をとると遅くなるが
抜け道的にGC対象外のエリアを使えるのと使えないのでは書ける範囲がだいぶ違う
例えばDBのエンジンとかその底のファイルアクセス部分とかね。
上の方はGCアリでいいが、下はむしろ有害だったりするし。

まあ俺はシステム屋、組み込み屋だからGCで不定時間停止とか
割り込みから使えない方が問題だがｗ

55 ：デフォルトの名無しさん：2010/05/19(水) 17:11:05

参照カウンタで十分

56 ：デフォルトの名無しさん：2010/05/19(水) 17:18:03

>>54
>ほとんどのシステムで大きなメモリ領域をとると遅くなるが
ならねーよ。バカ。

57 ：デフォルトの名無しさん：2010/05/19(水) 17:34:04

とりあえずなにか作ってみれば？
今要望が出てる機能だけで簡単(？)に作成してみればいい

58 ：デフォルトの名無しさん：2010/05/19(水) 17:58:19

あきらかに56がバカだ。

59 ：デフォルトの名無しさん：2010/05/19(水) 18:17:48

おれもそう思う。

60 ：デフォルトの名無しさん：2010/05/19(水) 22:09:05

作っているには作っているけど、簡単に作れません。
C++/CLIは.Net FrameworkのC++マネージ拡張を簡単にしたものなんだ。
知らなかった。orz
ポインタとハンドルがあって、ハンドルはGC対象ってわけか。なるほど。
ちゃんと触ってみるかぁ

61 ：デフォルトの名無しさん：2010/05/20(木) 01:04:35

>>56 >>57
理由言えバカ！勉強にならねーだろ。
56がバカかどうかわからないけど、
メモリ領域を大きく取る
　＝＞　物理メモリ外か？
　　　YES＝＞　エラー or スワップから変換
　　　NO ＝＞　アドレッシング解決による3サイクルアクセス

って感じで分かれないの？
ばかだなーって思ったやつは検索用語か読んどけ本書いていけ

62 ：デフォルトの名無しさん：2010/05/20(木) 01:18:30

>>61
何度も言うけどこのスレは勉強会のスレじゃないよ。
バカは黙ってろって何度言えば分かる？
勉強会のスレッドに不足してるわけでもないし、
このスレで勉強会始めるなよ。

63 ：デフォルトの名無しさん：2010/05/20(木) 01:36:00

記憶階層の勉強会かw
キャッシュ忘れんなよ
特に組み込みのCPUなんかで動画扱うと
桁変わる位速度が違う

64 ：デフォルトの名無しさん：2010/05/20(木) 01:59:48

勉強会のなにが悪いん？
学術的な話するのに勉強はするないうのはおかしいんじゃない？
勉強会スレってあるの？

65 ：デフォルトの名無しさん：2010/05/20(木) 02:01:34

バカバカうるさい

66 ：デフォルトの名無しさん：2010/05/20(木) 02:30:51

勉強会したいなら、どんなカスなレスでも調べてみろよ
中にはまともなの？もある
>>56みたいなのはバカといわれても文句は言えんな

67 ：デフォルトの名無しさん：2010/05/20(木) 02:32:25

俺もそう思う。

68 ：デフォルトの名無しさん：2010/05/20(木) 03:30:43

C++/CLIが内部でどうなってるのかわからないけど、
^がポインタ演算子ならぬ、ハンドル演算子みたいに働いてGC用型になり
ref classがGC対象クラスになるということが分かった。
GCなしがベースでGCありにしたいときに特別な修飾ができればいいんだな。
ポインタ操作はunsafeなライブラリが受け持つことにして隠蔽してしまえば
ハンドルとプリミティブだけでプログラムできる。
通常はjavaみたいにプリミティブと参照される型だけあるようにする。
A* a = new A()じゃなくA a = new A
stack A a = new A()等とするとスタックにメモリ確保されて
スコープから抜けると開放される。
A^ a = gcnew A
でgc対象にできるって感じでgc有り無し共存できたらいいかなぁ？
C#にアンマネージド機能を追加した感じで。

69 ：デフォルトの名無しさん：2010/05/20(木) 11:24:19

http://www.slideshare.net/authorNari/gc-4027176
Hot Spot VMでは参照マップを使ってポインタとそうでないものを区別してるそう。

70 ：デフォルトの名無しさん：2010/05/20(木) 11:52:47

直前の計算結果のフラグを条件にできる構文がほしい

71 ：デフォルトの名無しさん：2010/05/20(木) 15:25:23

carry(a = a << 2){}
とか？
a = a << 2
if(CARRY_FLG){
}
とかですかね？
フラグの値を取り出してboolとして扱えるような構文

72 ：デフォルトの名無しさん：2010/05/20(木) 17:43:23

そうそうそんな感じの、キャリー立ったら、とかオーバーフローしたらこうする、みたいなの
アセンブラだと自然に

a = a + b
if(OV_FLG){
a = INT_MAX
}

みたいにできるんだけど、Cとかだと

if (INT_MAX-b<a)
a += b;
else
a = INT_MAX;

みたいにやらないといけないことが多くてまどろっこしい

73 ：デフォルトの名無しさん：2010/05/20(木) 17:47:24

前スレの内容がループしてるんだけど、
ループしてまで、なんとかスレを伸ばしたいのかな？
そうまでしてスレを伸ばしたいのなら、勉強会始めなきゃ
良いのにって思う。議論が進みそうになると勉強会初めて、
ネタに尽きるとループっていうのは２ｃｈの悪い所。

何時までたっても同じところから前に進めない。

つまり、バカが書き込むのはよくないと思う。

74 ：デフォルトの名無しさん：2010/05/20(木) 18:00:44

>>72
#define INT_CLIP(x) (int)(MAX((long)INT_MIN,MIN((long)INT_MAX,(long)x)))
a = INT_CLIP(a + b);

こう書いとけばコンパイラが勝手に最適化してくれるぞ

75 ：デフォルトの名無しさん：2010/05/20(木) 18:14:16

>>73
おまえ・・・ループしてね？

76 ：デフォルトの名無しさん：2010/05/20(木) 18:17:46

>>74
それが結構してくれねーんだ
律儀にビット拡張して計算してコンペアして分岐してくれる

77 ：デフォルトの名無しさん：2010/05/20(木) 18:22:20

＞＞76
暗黙の型変換が仕様なので、暗黙の型変換後を最適化する
普通の最適化だと無理なんだよね。
字句解析→構文解析、この辺で情報が落ちてしまいがち
でも、これもコンパイラの勉強会の話ですれ違い。
バカはどっか行け

>>75
俺もそう思う

78 ：デフォルトの名無しさん：2010/05/20(木) 18:38:35

ではここで関数型言語とGCとC#の話題をどぞー

79 ：デフォルトの名無しさん：2010/05/20(木) 23:16:24

バカ = バカ + バカ
ってことで

80 ：デフォルトの名無しさん：2010/05/20(木) 23:31:41

twitterで呟いてたのを見たんだけどContinuation Based Cっていうのが
基本ブロック単位でプログラムできるようです。
これこそ超高速C言語なのかもしれないですね。
よくわかってないですが、基本ブロック単位で関数みたいに出来るのかな？

81 ：デフォルトの名無しさん：2010/05/20(木) 23:46:28

ここで求められてるのは、Cより高速な言語じゃなくて、
VMとかGCとか遅くなる要素が無くて、C程度に速いオサレな言語だから。

82 ：デフォルトの名無しさん：2010/05/20(木) 23:49:03

違う。C言語の問題点を克服したパラレルCだ。

83 ：デフォルトの名無しさん：2010/05/20(木) 23:55:12

CARRY_FLGとかいまいちカッコ悪いから、こんな感じがいいな。

現スレッドオブジェクト current
現スレッドのALUオブジェクト current.alu
現スレッドのALUオブジェクトのキャリーフラグ current.alu.flag.carry
現スレッドのALUオブジェクトのゼロフラグ current.alu.flag.zero

using current.alu.flag;

でcurrent.alu.flagを省略できるとか。

84 ：デフォルトの名無しさん：2010/05/21(金) 00:19:34

C#ならunsafeを使えばポインタも扱える。
ただ、クラスがあったりする。
ポインタを使いたい場合はunsafe内で使える。
だけどVM不要な人がいちいちunsafeは書きたくない問題が残る。
例えば、unsafe:って書いておけばunsafeになるくらいだといいのかもしれない。

class C{
　static void Main(){
　　unsafe {
　　　int n;
　　　int* pn = &n;
　　　byte* p = (byte*)pn;

85 ：デフォルトの名無しさん：2010/05/21(金) 00:20:41

>>82
CBCはC言語の問題点を克服したパラレルCなんですね。

86 ：デフォルトの名無しさん：2010/05/21(金) 01:49:18

>>80
面白そうだからみてみたら
これの継続って引数付きgotoですな
一応戻るようなのも書けるみたいだが
ループのたびに継続作るのは
まとまったコードを書くのはキツそう

87 ：デフォルトの名無しさん：2010/05/21(金) 01:55:10

>>83
なんだよ。現スレッドって。
キャリーやフラグは扱えたら面白いが
最適化で実行順が変わるとアウトだし
CPUで挙動が異なるのがねー

88 ：デフォルトの名無しさん：2010/05/21(金) 05:49:29

C#では
int* x = stackalloc int[N]でスタックからアロケーション可能だけど
すべてのオブジェクトはGCで管理されるのでGCによって消される可能性がある。
対策として
fixed(double* p = &c.re){
*p = 10;
}
等としてfixedの間はGCが行われないようにすることができる。
ということで、C#の場合はGCありきな言語でポインタ操作もできると。

89 ：デフォルトの名無しさん：2010/05/21(金) 06:04:07

未だに前スレ埋めてないお前らの糞さにビックリだよ

90 ：デフォルトの名無しさん：2010/05/21(金) 06:12:27

>>89
早漏の >>1 の後始末なんて知ったこっちゃない。

91 ：デフォルトの名無しさん：2010/05/21(金) 06:15:00

関数型言語のGCはビットタグが付いててアレなのでSML#いいよ
http://www.pllab.riec.tohoku.ac.jp/slides/ppl2007sli.pdf
SML#の#は.Net Frameworkの前からあってレコード演算子"＃"を象徴するものと

92 ：デフォルトの名無しさん：2010/05/21(金) 06:17:38

>>89
ビックリマン登場
参照の必要があればGCしないほうがいい

93 ：デフォルトの名無しさん：2010/05/21(金) 07:33:21

で、言語ってどうやって作ればいいんだよ

94 ：デフォルトの名無しさん：2010/05/21(金) 08:56:43

設計思想はPythonがベストだと思う。
言語自体を限りなくコンパクトにして、豊富なライブラリを標準で付ける。
ライブラリとして分離されていればメンテしやすいのは自明。後から新技術を採用するのも容易。

つまり、GCとかVMとかライブラリでどうにでもなることは後で考えろ、ということ。
まず決めるべきは上っ面、構文のみである。

95 ：デフォルトの名無しさん：2010/05/21(金) 09:07:07

そういう発想なら、構文も後付けでどうとでもなるLispかFORTHでおk 終了、だろ

96 ：デフォルトの名無しさん：2010/05/21(金) 09:08:19

>>94
あと、GCやVMに言語が一切関係してなくて、ライブラリで実現してる例ってあるのかな？
あるなら教えてほしいもんだが。

97 ：デフォルトの名無しさん：2010/05/21(金) 09:24:06

>>96
その前に何故GCやVMが「言語の機能」だと思い込んでるの？
そっちのほうが不思議だわ

98 ：デフォルトの名無しさん：2010/05/21(金) 09:47:13

>>97
その前に何故GCやVMが「ライブラリだけで実現」できると思い込んでるの？
そっちのほうが不思議だわ

99 ：デフォルトの名無しさん：2010/05/21(金) 09:49:11

コンパクションもできなければexactなGCもできないライブラリを示して、勝利宣言とかやめてねw

100 ：デフォルトの名無しさん：2010/05/21(金) 09:55:04

8bitマイコン用の言語ができたら教えて

101 ：デフォルトの名無しさん：2010/05/21(金) 10:15:23

>>98
実行時の機能だから
おまえは言語の機能とパーサ以降の機能を分離できてない

102 ：デフォルトの名無しさん：2010/05/21(金) 10:21:33

言語機能の一部がライブラリで実現されてる例なんて山のようにあるお。
頭のなかだけで分離していて現実を見てない人の気配がするお。

103 ：デフォルトの名無しさん：2010/05/21(金) 10:29:24

GCを欲しがる奴らはこんなド低脳ばかり

104 ：デフォルトの名無しさん：2010/05/21(金) 10:56:08

いまどき、自分でメモリを管理して悦に入っている奴は、重要なことが何かがわかっていない。

105 ：デフォルトの名無しさん：2010/05/21(金) 10:58:50

ド低能って、自分でメモリを管理して悦に入っている奴のことだよな。

106 ：デフォルトの名無しさん：2010/05/21(金) 11:20:55

ド低能はプロジェクトによってメモリ管理を自分でやるか誰かにやらせるかを判断できない

107 ：デフォルトの名無しさん：2010/05/21(金) 11:23:17

>>106
低能が我慢できずに反してきたか。
それだけしか言えないか？

108 ：デフォルトの名無しさん：2010/05/21(金) 11:58:26

>>102
だから組み込む必要はない(ライブラリでいい)ねって話だろ。何か問題でも？

109 ：デフォルトの名無しさん：2010/05/21(金) 12:03:53

>>107
うん。それ以外に言う必要ないし

110 ：デフォルトの名無しさん：2010/05/21(金) 12:06:21

このバカを張り付けておくためだけでも有意義だな、このスレは

111 ：デフォルトの名無しさん：2010/05/21(金) 15:58:01

GC 自体が欲しいんじゃなくて、
GC 必須になるオサレな構文が、

112 ：デフォルトの名無しさん：2010/05/21(金) 16:48:07

GC前提は言語の設計に影響する
VMは影響しない
低レベルでGCありならgolang
無しならCで決まりじゃね
C++の末えいはみな悲惨

113 ：デフォルトの名無しさん：2010/05/21(金) 16:48:57

バカ量産言語だしな

114 ：デフォルトの名無しさん：2010/05/21(金) 16:52:06

>>111
クロージャや継続ですねわかります

115 ：デフォルトの名無しさん：2010/05/21(金) 18:01:43

メモリーリークが発生するのは、やたらとヒープにメモリを取るからで
オブジェクトのインスタンスをスコープを外して永続化したいとき以外
newを使えなくしてしまえば良いんじゃないかな。
するなといってもしてしまうのが人の常なので、newの構文は長くしよう。

奇数行だと、new_allocate_heep_memory_i_need_I_want_majide_majde
偶数行だと、new_allocate_heap_memori_I_need_i_want_maide_majide
こうやって無茶苦茶書きにくく、長く書く必要があれば嫌な感じがして、
となれば使うのを控えると思う。

後、スコープを外れてメモリーリークを避けるために、ローカル変数への
代入は永続変数の代入が無ければ、コンパイルエラーってことにすれば
良いと思う。

116 ：デフォルトの名無しさん：2010/05/21(金) 18:10:34

もう列挙子やラムダ式の無い言語には戻れないｗ

117 ：デフォルトの名無しさん：2010/05/21(金) 18:26:02

それで何故、メモリーリークの混乱が起きるのか？
って考えると、オブジェクト指向のhave a関係が
大雑把過ぎると思うんだよね。

人間には手がある。とその人は本を持ってる。
英語だとどちらもhasで表現されるけども、日本語では
単語レベルで概念が分かれてて、「ある」と「持ってる」
違った単語で表現するよね。プログラミングでもこの概念を
分けないと駄目だと思う。

英語詳しくないんだけど、have theとhave aで良いのかな？
have the でそのインスタンスを明確化して、参照やポインタを
持つのはhave aで表現する事にすれば、良いのではないかな？

118 ：デフォルトの名無しさん：2010/05/21(金) 18:35:20

持っているというより、くっついているイメージなんだが。
equipmentじゃないかと。

119 ：デフォルトの名無しさん：2010/05/21(金) 18:37:41

>>117
という事で、クラス定義の文法は
class Human
{
　　have the char name[40];
　　have the int age;
　　have a　　int money;
　　have a　　car* private_car;
}
とすれば色々判って便利だと思う。

120 ：デフォルトの名無しさん：2010/05/21(金) 18:38:40

ガンダムのビームライフルは外せるが、
ガンキャノンのキャノンは外せない
外せたら、それガンキャノンやない、ガンや！

121 ：デフォルトの名無しさん：2010/05/21(金) 18:41:57

>>120
そういうこと、文法でそこを縛ってやれば、
メモリーリークも見つけやすく自動化も楽になると思うんだ。
プログラムも組みやすいだろうし。

122 ：デフォルトの名無しさん：2010/05/21(金) 18:51:00

それ単にオブジェクト間の関連の多重度の話だろ
考えられる多重度って
0..1と1の二種類じゃないし、構文だけでどうにかしようってのは
あまり現実的でないと思うと思うが

Cライクな言語において、0..1の多重度を表現するのにNullポインタ的なものを
使うことが多いけど、
少なくとも高級な言語なら、OptionやMaybeがあるべき姿だと思う
Javaや.NETは型安全性を犠牲にした妥協と見える

123 ：デフォルトの名無しさん：2010/05/21(金) 18:55:00

>>122
オブジェクト指向プログラミングと、
オブジェクト指向分析の境界で、そのへんがあやふやだから、
そのインスタンスの性質を表してるのに、have関係的に
扱ったりしてややこしくなってると思うんだよね。
have the のインスタンスは、所有してるクラスが死ねばもろともで良いんだよ。
仮にそれを参照（所有）してる他のクラスが生きてるとしても、それは
それを持ってることがおかしいんだよ。

124 ：デフォルトの名無しさん：2010/05/21(金) 19:00:02

ホワイトベースが、ガンキャノンを持ってるから、
砲門を二つ持ってる。

ここでガンキャノンがシャア少佐の工作によって
破壊されてるのに、2門残ったりする。

ホワイトベースhave a ガンキャノン　
ホワイトベースhave a ２門
とかやって、バグの原因になるんだよ。　　

ホワイトベースhave a ガンキャノン　
ホワイトベース.数える砲門数（）
としなければおかしいんだよ。

125 ：デフォルトの名無しさん：2010/05/21(金) 19:02:38

他の誰かから参照されたくない物なら、単にそれをプライベートにして
その参照を返すようなメソッドだのを作らなければいいだけの話では
そうすれば自動的に寿命は所有者と同じになるだろ

プログラムを現実世界の直喩で考えても上手くいかんと思うがなあ
現実を直接的にそのままモデル化しようとするのは
OO初心者が陥りがちな罠では

126 ：デフォルトの名無しさん：2010/05/21(金) 19:06:27

>>125
逆>>122みたいなバカな事言い出すのがオブジェクト指向に混乱を
もたらしてる。

class Human{
　have the hand[2];
　have a　handbag_list;
}
どちらも（0..N)関係だけど、意味合いがぜんぜん違う。

127 ：デフォルトの名無しさん：2010/05/21(金) 19:19:01

>>126
ああいいたいことは分かった
多重度というより、関連のconst性な

constでいいんじゃねえの

128 ：デフォルトの名無しさん：2010/05/21(金) 19:36:28

ええとつまりキャノンは構造体で定義しておくべきってことか？

129 ：デフォルトの名無しさん：2010/05/21(金) 19:44:28

整備とかでキャノンも外せるでしょ
そのときのガンキャノンは、まさしくガンだよ

130 ：デフォルトの名無しさん：2010/05/21(金) 20:27:10

なんでオブジェクト指向の勉強会なん
英語の勉強もか。have, belong, is

オブジェクト指向って自然発生的にやってたし
昔Smalltalkとか勉強したから理解が深まった
プリミティブじゃないifとかループとか美しいぜ
C++族の中途半端さが嫌いなやつはいねえのか

131 ：デフォルトの名無しさん：2010/05/21(金) 20:48:23

C++も最初に基底オブジェクトクラスを仕様化しとけば、
今ほどのカオスにはならなかったろうに。

132 ：デフォルトの名無しさん：2010/05/21(金) 20:58:46

つまりガンダムはライブラリ参照してるけど、ガンキャノンは初めから組み込んでいると
宣言によっては削ることも出来るが、それはもはやガンキャノンではありえないわけだな

133 ：デフォルトの名無しさん：2010/05/21(金) 20:58:53

このスレの奴らがいくら頑張って新言語を作ってもGoの方がはるかに
マシだろうな
無駄な努力はやめとけ

134 ：デフォルトの名無しさん：2010/05/21(金) 21:05:37

Goは、Cよりも上のレイヤーで使うことを想定している。代わりにはならない。

135 ：デフォルトの名無しさん：2010/05/21(金) 21:33:10

そのうち下位レイヤにも対応したGoToという言語を誇らしく発表

136 ：デフォルトの名無しさん：2010/05/21(金) 23:13:13

>>116
それって実行時のオーバーヘッドなく使える機能だよね？

新言語にはぜひ入れよう。

137 ：デフォルトの名無しさん：2010/05/21(金) 23:16:39

>>134
C#やらGCの話をしている時点でgolangの圧勝

OS本体はCで書いて、その上はgolangって感じだね
リンカとかコンパイラも書きやすそうだしな
Xprotocolの実装が入ってるし、そういうミドル層を狙ってるんだろう
現実的な解じゃないか

138 ：デフォルトの名無しさん：2010/05/21(金) 23:29:11

>OS本体はCで書いて、その上はgolangって感じだね

それなら、golangは新言語の直接の競合にはならないね。
新言語の主眼はCの置換えだから。

139 ：デフォルトの名無しさん：2010/05/21(金) 23:31:21

メモリ管理を組める言語ｷﾎﾞｿ

140 ：デフォルトの名無しさん：2010/05/21(金) 23:55:32

ルーチンとかの根幹的な構造も自分で組めるようにするの？

141 ：デフォルトの名無しさん：2010/05/21(金) 23:56:23

そうしたいね。

142 ：デフォルトの名無しさん：2010/05/21(金) 23:56:32

>>138
Cの置き換え言語の話でGCやらオブジェクトの話してるわけだが？

Cはある意味完成された言語。
だからこそgolangは別な層を目指したんだよ
現行の半端なOOへのアンチテーゼでもあるな

143 ：デフォルトの名無しさん：2010/05/22(土) 00:03:59

Goは総称型が無いのが残念
C++みたいなテンプレートは別に要らないけど

144 ：デフォルトの名無しさん：2010/05/22(土) 00:04:53

低級をカバーしつつ、流行りの機能を使えるのも新言語の持ち味だ。

golangがCとの共存を目指しているなら、golangがカバーしない部分では競合にはならない。
新言語はgolangと共存してもいいし、共存するくらいなら新言語だけを使ったほうがいいね。

145 ：デフォルトの名無しさん：2010/05/22(土) 00:08:28

GenericsはFAQだっけ？にはいずれ追加したいって書いてあるね

146 ：デフォルトの名無しさん：2010/05/22(土) 00:11:11

>>144
君はCPU固有言語君じゃないか？
頭をC#/C++/Winから離した方がいいよ

147 ：デフォルトの名無しさん：2010/05/22(土) 00:12:16

どこからC#/C++/Winなんて出てきたんだか。

148 ：デフォルトの名無しさん：2010/05/22(土) 00:18:47

>>147
俺エスパーかと思ったが違ったか
Cは英語みたいなもんだ。超えるのは難しいぞ

149 ：デフォルトの名無しさん：2010/05/22(土) 00:19:54

C代替だとGC依存/前提は話にならないと思う
使える分には構わないけど

150 ：デフォルトの名無しさん：2010/05/22(土) 00:27:55

GCなし言語にGCを追加すると汚くなるだけだよ
どうせ入れるなら最初から前提にしたらいい。
スレの意味はなくなるがｗ
>>144
C++すらホントの低レベルじゃ使われてない事実を考えて見てはどうだろう。

151 ：デフォルトの名無しさん：2010/05/22(土) 00:28:57

どこが汚くなるのかまったく不明。

152 ：デフォルトの名無しさん：2010/05/22(土) 00:32:04

>>150
>C++すらホントの低レベルじゃ使われてない事実を考えて見てはどうだろう。

だからこそ、低レベルで本当に「使える」新言語を作るんだろ。

153 ：デフォルトの名無しさん：2010/05/22(土) 00:35:25

>>150
> C++すらホントの低レベルじゃ使われてない事実を考えて見てはどうだろう。

使っちゃ悪いということはないんじゃない？　Cで出来る事は何でもできるんだから。
eCosはかなりの低レベルだと思うけどC++で書かれている。

154 ：デフォルトの名無しさん：2010/05/22(土) 01:30:29

まあ、後ろ向きの話をしてる奴は相手にしなくてもいいよ。

「既存のXXXはダメだから、新言語もダメだ」
ではなく、
「既存のXXXはダメだから、新言語はこうしよう」
という議論を期待したい。

155 ：デフォルトの名無しさん：2010/05/22(土) 01:54:33

お前がやれよ

156 ：デフォルトの名無しさん：2010/05/22(土) 02:42:17

>>153
ん？あれCじゃないか？
C++のサポートはあったと思うが。
C++がCと同じことが出来るのは
比較的上の世界だよ

前向きにいうなら、Cの代替じゃなく
C++/java/C#の代替を考えたらどうだろう
ブートローダやOS、組込みなんかの
ベタな世界を知らないで
Cの置き換えを考えるのは無理と思うよ

157 ：デフォルトの名無しさん：2010/05/22(土) 02:49:50

ついでにいうと、
知り合いがC++使ってRTOS作ってたが
ブート部分は苦労してたな
世界を二つ作らないといけないし
リアルタイムな時間の保証も考えると
結局virtualはほとんど無し
クラス階層も浅めでやってたな

俺はCで書いたが、性能や時間保証は
余り苦労しなかったかな

158 ：デフォルトの名無しさん：2010/05/22(土) 02:52:11

>>156
> java/C#の代替を考えたらどうだろう

スレ違い

159 ：デフォルトの名無しさん：2010/05/22(土) 02:54:03

>>156
> C++がCと同じことが出来るのは
> 比較的上の世界だよ

Cに出来てC++に出来ないこととは？

160 ：デフォルトの名無しさん：2010/05/22(土) 03:14:12

>>159
例えばmain以前の部分や
プアなCPUやメモリの組込みなんかは？
書けなくもないが、C++てより
ただのCとして使うことになる

>>158
GCやらクロージャやら
オブジェクトがうんたらとかの話ばっかだろ
スレ違いじゃないと思うがな

161 ：デフォルトの名無しさん：2010/05/22(土) 03:22:15

>>160
> 例えばmain以前の部分や
> プアなCPUやメモリの組込みなんかは？

それって、Cに出来てC++に出来ないことなの？理由は？

> ただのCとして使うことになる

それでもC++であることには変わりない。

162 ：デフォルトの名無しさん：2010/05/22(土) 03:26:41

>>161
子供かよw
要するに
その場に書いてないコードが走ったり
余分にメモリ食って
余分なセットアップがいるC++は
最初から使わないんだよ
動的なメモリすら使わない世界な

163 ：デフォルトの名無しさん：2010/05/22(土) 03:33:40

>>162
で、>>159の質問には答えないの？

> 子供かよw

これで逃げるなら別にいいけど。

164 ：デフォルトの名無しさん：2010/05/22(土) 03:42:32

じゃあ尋ねるが
C++がC++として機能する前は何で書くんだ？
スタティックなコンストラクタ呼び出しやら
スタックやメモリ初期化周りとかな
C++の機能を全く使わずに書いてもC++なのか？

まあ、暇だからいいけど
現実に選択肢に入らないんだから
言葉遊びならこれ位に。

165 ：デフォルトの名無しさん：2010/05/22(土) 03:49:11

>>164
だから、それは、「Cに出来てC++に出来ないこと」の説明ではないだろ。

CはXXXが出来る。しかし、C++はXXXが出来ない。

端的にXXXを答えればいい。

166 ：デフォルトの名無しさん：2010/05/22(土) 04:04:31

C++はCの機能をほぼ完全に包含しているから
Cに出来てC++に出来ないことがあると論陣を張り続けるには無理がある。

ハンバーグとハンバーガーを比べてハンバーガーには肉が無いと言ってるようなものだ。

167 ：デフォルトの名無しさん：2010/05/22(土) 04:20:02

実行時に負荷にならない機能はリッチにしたいな

168 ：デフォルトの名無しさん：2010/05/22(土) 04:22:14

ではハンバーグが食べたいときにレストランでハンバーガーを頼むといい。
俺はハンバーグセットを頼むけどなｗ
>>166
余分なものが付いているから使われない世界もあるんよ。
Cとしてか使わないならそれはC++とは言えんだろってこと。

169 ：デフォルトの名無しさん：2010/05/22(土) 04:29:19

ランタイムでCが初期化してやらないとC++としては使えないからな

170 ：デフォルトの名無しさん：2010/05/22(土) 04:40:48

まだこの人、ハンバーガーには肉が無い、と言い張るようだ。

171 ：デフォルトの名無しさん：2010/05/22(土) 04:55:03

CもC++も単なる置き換え対象だからどうでもいいよ。

172 ：デフォルトの名無しさん：2010/05/22(土) 04:59:56

まあ、実際に組み込み分野ではC++コンパイラがあっても
ほとんど使われてないからどっちでもいいよｗ
新言語はC並にRAMがまだない状態でも動かせる言語にしてくれ

173 ：デフォルトの名無しさん：2010/05/22(土) 05:01:07

必死過ぎて笑える

174 ：デフォルトの名無しさん：2010/05/22(土) 05:41:43

うむｗくだらん言葉遊びに付き合っちまったなｗ

175 ：デフォルトの名無しさん：2010/05/22(土) 09:15:54

新しい言語はアンマネージがデフォでGC付きポインタである
ハンドル型があって共存できればいい。
で、マネージドな関数からアンマネージドな関数を呼び出すときは
GCを止めるフラグを立てて戻ってきたら立て直すのを自動で行ってくれるようにする。
マネージドなプログラムのスタックフレームは完全なGCが可能な情報があれば嬉しい。
マネージドなプログラムではポインタは扱わないでハンドルで扱う。
アンマネージドなプログラムではポインタを扱う。
とすれば融合できそうですね。
managed int main() {// mainがmanagedならgcライブラリをリンク
a();
}
managed struct A{}
struct B{}
managed int a(){
String s = @"str";// マネージドな文字列
A a = new A();
return unsafe();// 自動GC OFF
}
int unsafe() {
B b* = new B();
auto B b2* = new B(); // autoが付くとスタックから取得する。
delete b;
return 1;
}

176 ：デフォルトの名無しさん：2010/05/22(土) 09:17:28

GCはライブラリ提供でいいよ

177 ：デフォルトの名無しさん：2010/05/22(土) 09:29:56

ライブラリ提供では、保守的なGCになってしまいません？

178 ：デフォルトの名無しさん：2010/05/22(土) 09:39:07

言語仕様にGCを入れてスタックフレームの使い方を工夫することで
完全なGCが可能になるので、GCのアルゴリズムはライブラリでいいとしても
関数の呼び出し規約の変更と構造体にGCが可能にするための情報の
追加が行えるようにするといいと思うのです。
関数呼び出し時のスタックに何が入っているかも分かるようにするとか。
GC切った状態でならOSも、言語も作れる。
すくなくとも、言語仕様としてGC拡張に耐える文法であるといいと思います。
C++の
B b(3);
のように書いてスタックに変数をというのはやめて
auto B* b = new B(3);b.a
のように書けたらいいのではないかと。

179 ：デフォルトの名無しさん：2010/05/22(土) 09:51:53

GC処理によるCPU占有を許容できないシステムでも使われるのが低水準言語
しきりにGCGCとわめいてるクズ共はそういう世界を考慮していない根本から間違った奴ら
どうしても採用していならまずCPUを占有しないGCを発明してからにしろ

180 ：デフォルトの名無しさん：2010/05/22(土) 09:55:56

採用云々は別としてGCを実装可能な言語仕様を検討するのは意味ある
GC使用を選択可能というのも現実的な解だと思うが

181 ：デフォルトの名無しさん：2010/05/22(土) 09:59:28

>>180
ない

GC必須な仕様ではリアルタイム処理は絶対に作れない
タイムスライスを保証できないから
さらにGCがなくても高水準なプログラムは作れる
であれば採用しないのは当然の帰結だ

182 ：デフォルトの名無しさん：2010/05/22(土) 10:11:41

C++/CLIやObjective-Cでいいだろ。記法が気に入らないだけなら、どう変えたいのだ？

183 ：デフォルトの名無しさん：2010/05/22(土) 10:19:31

>>181
ゆとりはメモリ管理もできないんだ
許してやれ

184 ：デフォルトの名無しさん：2010/05/22(土) 10:24:38

ゆとりはコンカレントGCもパラレルGCもリアルタイムGCも知らないんだ
許してやれ

185 ：デフォルトの名無しさん：2010/05/22(土) 11:23:21

>>181
採用可能だが採用しないことも可能という言語仕様なら問題ないだろ。
コード流用の観点から言えば十分に検討の余地がある。
頭固すぎだろ。

186 ：デフォルトの名無しさん：2010/05/22(土) 11:41:41

リアルタイムGCが実用になっているとでも

187 ：デフォルトの名無しさん：2010/05/22(土) 11:59:55

リアルタイム処理にはGC使わないほうがいいので
リアルタイム処理専用のコンパイラならGCなしで使うようになってたほうがいい。
GCの言語機能はオプショナルなものとする。
GCありが可能なコンパイラでもオプションによってGCありが選択できる。
コーディング規約等にGCありオプションを付けてはいけないことと明記し
徹底することで対応できるのではないかと。

188 ：デフォルトの名無しさん：2010/05/22(土) 12:16:41

>>181
何で GC 可能を GC 必須にすり替えるんだ。

189 ：デフォルトの名無しさん：2010/05/22(土) 12:17:58

C++/CLIに対する不満はC++ベースであること。
A a;と書いてスタックに領域が取られるのが不満だ。
D言語だと auto A a = new A();と書くことでスタックに領域が取れるのでそうしたい。
Objective-Cは覚えるのに千本ノックが必要で老いた体に叩き込むのはキツイ。
D言語は保守的GCでマネージアンマネージがスタックフレームにごちゃまぜになってるのが不満。
C#はデフォルトGCありであることが不満で新しい言語はデフォルトGCなしが望ましい。

190 ：デフォルトの名無しさん：2010/05/22(土) 12:27:22

現実に存在する言語ではC++/CLIは素晴らしいので
C++/CLI拡張を念頭において新しい言語を作成して欲しいです。

191 ：デフォルトの名無しさん：2010/05/22(土) 14:56:21

パフォーマンスや少メモリーを求めるところではプログラマーが細かくオブジェクトの寿命をコントロールできて
それ以外のところではプログラマーが特に意識せずともメモリーリークが起こらないように処理系が良きにはからってくれればいい。

CGは単なる手段だから、後者を実現できるのであればCGである必要は全くない。

192 ：デフォルトの名無しさん：2010/05/22(土) 14:59:24

CGは板違いですが？

193 ：デフォルトの名無しさん：2010/05/22(土) 15:02:26

Cgのことか？

194 ：191：2010/05/22(土) 15:08:00

CGはGCの間違い
GCはgarbage collectionの略

195 ：デフォルトの名無しさん：2010/05/22(土) 15:13:55

GC必須 : 不可
GC可能 : 許可

196 ：デフォルトの名無しさん：2010/05/22(土) 15:16:21

必須とか可能とか、誰にとっての話？

197 ：デフォルトの名無しさん：2010/05/22(土) 15:16:37

OS制作者

198 ：デフォルトの名無しさん：2010/05/22(土) 15:20:04

OSなんて作りたいように作ればいい。

新言語の仕様に縛られなくていいよ。

199 ：デフォルトの名無しさん：2010/05/22(土) 15:24:55

>>191
何が言いたいかよくわからん
リアルタイム計算や少メモリのような要件のないプログラムはGCあり言語で書いて
そういう要件のあるプログラムはGCなし言語で書けばいいのでは？
だって、別のプログラムだろう？

メモリってグローバルな資源だから、特定のプログラムの一部分は
少メモリである必要があるとか、タイムクリティカルでなくていいとか
そういうことって無いと思うし

200 ：199：2010/05/22(土) 15:27:24

ああそれと、一部分だけタイムクリティカルってケースは
割り込みハンドラとかあんのかな、と思うけど
もしそれだけが問題なら、特定のブロックでGCが実行されないようにさえ
出来ればいいんじゃねえの
大抵そういう手段は用意されてると思うけど

201 ：デフォルトの名無しさん：2010/05/22(土) 15:29:23

GC自体が実行ファイルのサイズを肥大化させる
GCを完全に使わない設定がないと意味が無い

202 ：デフォルトの名無しさん：2010/05/22(土) 15:31:31

>>199
いくつも言語を覚えたくない。

203 ：デフォルトの名無しさん：2010/05/22(土) 15:33:49

GCの使える新言語A と GCの使えない新言語B を作って
簡単にそれぞれ移行出来ればいいな。

204 ：デフォルトの名無しさん：2010/05/22(土) 15:36:15

なんだ言語1個しか使えない無能ちゃんの集いなのか？ここ
今既に言語1個じゃ仕事にならんだろうに

205 ：デフォルトの名無しさん：2010/05/22(土) 15:39:50

ライブラリとは別に機能をアタッチメント式にすればよかろうよ
GCとかメモリ管理とか

206 ：デフォルトの名無しさん：2010/05/22(土) 15:41:12

GCがないと実現困難な言語仕様とかあるから
同時に巻き込まれて無効になる仕様があるのは仕方が無いな

207 ：デフォルトの名無しさん：2010/05/22(土) 16:04:28

Indexテーブルを使った、仮想メモリページ単位の管理にすれば、
大きさの変わるオブジェクトの管理が、
ちょっ速になりそうな気がするんだけどな。
テーブルをどこに置くかが問題だがｗ

208 ：デフォルトの名無しさん：2010/05/22(土) 16:17:48

>>188
そんなんこのスレでもさんざん言われてるだろ
オプショナルなGCは保守的になるんだよ
保守的GCは確実に解放していいと判断できるメモリしか解放できない
効果などあってなきが如し

209 ：デフォルトの名無しさん：2010/05/22(土) 16:44:04

>>208
それはC言語での話でしょ。
C++では保守的ではないマークアンドスイープが実装できるはず。

210 ：デフォルトの名無しさん：2010/05/22(土) 18:47:24

囲碁GCの話は禁止

211 ：デフォルトの名無しさん：2010/05/22(土) 18:59:34

リソースを適切に管理する仕組みであれば、それがGCである必要はない。

212 ：デフォルトの名無しさん：2010/05/22(土) 19:18:05

>>209
そういうことはオプショナルで且つ保守的でないGCを発明してから言ってくれる？
何が「はず」だヴォケ

213 ：デフォルトの名無しさん：2010/05/22(土) 19:30:43

>>212
出来ないと思っている理由は何？
C++はスタック・スタティック確保はコンストラクタ・デストラクタ呼び出すから対応済。
ヒープ確保はnewをオーバーライドすればすべてのインスタンスを追跡できる。
出来ないと思う理由が知りたい。
はずというのはそういう有名なライブラリがないからだができない理由が知りたいわ。

214 ：デフォルトの名無しさん：2010/05/22(土) 19:32:54

「僕がプロ野球選手になったらホウムラン８０本打ってホウムラン王になります。」

215 ：デフォルトの名無しさん：2010/05/22(土) 19:36:51

※クラス定義の話題は、カプセル化機能は欲しいからです。

friend　というアクセス制限子があるけども、これってオブジェクト指向的に
必須というわけでもないと思うので、friendは廃止して良いよね。
いやいや、そうじゃないfriendが無いと大変な事になる、こういう場合
組めなくなるという意見があれば教えてください。

216 ：デフォルトの名無しさん：2010/05/22(土) 19:38:24

>>213
C++のポインタや型はナマだから、何の印もついてないし
ポインタと整数と適当に置き換えたりできるのもCと同じだ

それでなぜC++できちんとしたGCが出来ると思うのか理解できん

217 ：デフォルトの名無しさん：2010/05/22(土) 19:39:22

アーキテクチャが対応してないだけで言語の問題じゃないだろ

218 ：デフォルトの名無しさん：2010/05/22(土) 19:42:05

>>213
出来ないなんて誰も言ってないと思うけど？
根拠も実例も示さず妄想だけで議論を進めるのは危険でしょ。

219 ：デフォルトの名無しさん：2010/05/22(土) 19:55:03

>>216
理解してないのはわかった。

220 ：デフォルトの名無しさん：2010/05/22(土) 19:59:09

俺たちはいったい誰と戦っているんだ……!？

221 ：デフォルトの名無しさん：2010/05/22(土) 20:54:04

もうC++は許してやれよ

222 ：デフォルトの名無しさん：2010/05/22(土) 21:30:03

>>213
＞C++はスタック・スタティック確保はコンストラクタ・デストラクタ呼び出すから対応済。
一般にGCのある言語にはC++でいうデストラクタは無い。ファイナライザやディスポーザはヒープ外リソースの開放のためでデストラクタではない。
ましてや、ファイナライザが呼ばれないかもしれないGC付言語もある。

＞ヒープ確保はnewをオーバーライドすればすべてのインスタンスを追跡できる。
この追跡を０オーバーヘッド且つストップザワールド無しで実現できるアルゴリズムが存在しない。存在すれば直ぐに採用されている。

223 ：デフォルトの名無しさん：2010/05/22(土) 21:32:50

C++/CLIなんてのも無しな
あれが汚いと思わないならプログラミングやめたほうがいい
混在させるならGCありをベースにしないと半端になる
構造体はメモリと1:1で余分な追加物無し出ないと
かけないものが出てくる

RTOS並みのマルチスレッド管理をネイティブに言語に組み込めないかね
そういうのベース言語でOS作ってみたいな

224 ：デフォルトの名無しさん：2010/05/22(土) 21:37:41

>>223
頭痛が痛いんだ。

RTOSのスレッドをマルチスレッドと呼ぶのはなんか違うような気がする。
なんか違うけど誤解する程度には似てるので、確かに技術的なロードマップ
はありえると思うんだけど。

ただその場合、それは言語じゃなくてOSの話題になるわけで、
その辺り、自分の言ってる事が無茶苦茶にならないように書けてないので、
君は良くわかってないバカだと思う。
2chに限らず、その辺混乱しちゃうだろうから、と丁寧にかけないバカは
たいてい本当にバカ、二百万の書き込みの内ひとつだけ、こうやって突っ込むと
まともな答えが返ってくるけども、君はバカだと思う。

バカ多すぎ。

225 ：デフォルトの名無しさん：2010/05/22(土) 21:40:52

>>222
おれはC++はマークアンドスイープ型のＧＣは実装可能だといいたいんだけど。
一般的なＧＣ言語の話をして何が言いたいの？

＞この追跡を０オーバーヘッド且つストップザワールド無しで実現できるアルゴリズムが存在しない。

おれはC++で「保守的ではないマークアンドスイープが実装できる」はずといっている。
なぜオーバーヘッドの話になる？

ちなみにC++で実装可能なら、GCの採用不採用選択を言語が保証することは可能ということになるから
C++の仕様からその特性を抽出すればそのような言語は可能という主張ができる。
もしそうならオーバーヘッドの問題は不採用で回避可能だね。
でそのソースコードをマークアンドスイープ型ＧＣ採用のプログラムに流用も可能になる。

226 ：デフォルトの名無しさん：2010/05/22(土) 21:44:07

GCありと、そうでないものを共存させたら、本質的に互換性のないオブジェクトが二種類（さらにプリミティブ型）になるから汚くなって当然。妥協の問題。

227 ：デフォルトの名無しさん：2010/05/22(土) 21:44:47

＞「保守的ではないマークアンドスイープが実装できる」
オーバーヘッドを無視すればだけどな
実際にはオーバーヘッドがあるために採用できない
＞ちなみにC++で実装可能なら
実例出せればカッコイイけどな

228 ：デフォルトの名無しさん：2010/05/22(土) 21:46:51

>>226
両立できないんだよね、だが実際それを実装してしまうMicrosoftにそら恐ろしいもの感じるが。

229 ：デフォルトの名無しさん：2010/05/22(土) 21:47:07

オブジェクトはGCありを前提として設計するのと、そうではないのとでは言語の設計が変わる。共存させたいならそれによる不便も受け入れなくてはならない。

230 ：デフォルトの名無しさん：2010/05/22(土) 21:50:43

結局具体的に指摘したこと(>>213 >>225)には反論できない。
で実装を見せない限り認めないと。自分はただ自説を繰り返すのみ。
プログラムは動作していない限り意味がないのは最終的にはそういうものだけど
ただ否定するだけって何も生まないね。

231 ：デフォルトの名無しさん：2010/05/22(土) 21:59:01

>>230
議論の段階は終わったから実装見せてくれ。
実装見せろとか後ろ向きなこというな。

が３スレにわたって繰り返されてる。
勢いを維持したいだけのバカがいるんだよ。

232 ：デフォルトの名無しさん：2010/05/22(土) 21:59:45

>>229
アルゴリズムが違うんだからどっちも完全に同じ結果になるような動作をすることはないね。
最大公約数のなかで記述することになるから面倒になることは間違いない。
GCない場合をデフォルトとして公約数内の範囲で記述すればGC採用上でも動作するというくらいだとおも。

233 ：デフォルトの名無しさん：2010/05/22(土) 22:07:53

>>230
具体的な指摘とはこれ？
＞おれはC++はマークアンドスイープ型のＧＣは実装可能だといいたいんだけど。
とりあえず、スレタイの[超高速]にマッチしているか指摘して欲しい

234 ：デフォルトの名無しさん：2010/05/22(土) 22:20:25

言語で実装可能なライブラリの速度と、言語そのものの速度は別物だと思うんだけど、どうだろうか

235 ：デフォルトの名無しさん：2010/05/22(土) 22:24:22

>>234
そういう質問するレベルなら、書き込むなよ。
初心者すれって山のようにある。

236 ：デフォルトの名無しさん：2010/05/22(土) 22:31:43

>>235 がイラついてることだけはよくわかった

237 ：デフォルトの名無しさん：2010/05/22(土) 22:32:34

GC否定派「GCはランタイムが必要だから嫌」
GC肯定派「こういうGCの方式がある、この言語ではこうしてる」

議論が噛み合ってないんだよ、否定派のランタイムが必要に
対して対論を（ランタイムなしで実現できるGC）を出してこいよ
バカの癖に書き込むなよ。

238 ：デフォルトの名無しさん：2010/05/22(土) 22:34:35

こんなスレに天才プログラマーが集まってるでも？

239 ：デフォルトの名無しさん：2010/05/22(土) 22:36:06

>>236
パタリロ・ド・マリネール８世曰く「いらいらする時はカルシウムを取るといい。」

240 ：デフォルトの名無しさん：2010/05/22(土) 22:38:51

ところで、新言語のGCは何言語で実装するんだ？

241 ：デフォルトの名無しさん：2010/05/22(土) 22:39:24

バカバカ言ってるのは、リアルで普段バカバカ言われて言い返せずストレス貯めてるグズだよ。

242 ：デフォルトの名無しさん：2010/05/22(土) 22:40:45

>>240
新言語自身だろうね。

243 ：デフォルトの名無しさん：2010/05/22(土) 22:41:44

もう脳内で仮想ノイマン式CPUのメモリ演算リアルタイムトレース出来るレベルの人以外書き込み禁止にしようぜ

244 ：デフォルトの名無しさん：2010/05/22(土) 22:42:08

で、今あるすごい実装のGCってどんな言語で書かれてるんだろう

Cかな

245 ：デフォルトの名無しさん：2010/05/22(土) 22:42:13

じゃぁ、新言語のGC作るときにはGC使うなよ。

246 ：デフォルトの名無しさん：2010/05/22(土) 22:43:15

>>245
そりゃそうだろ。

247 ：デフォルトの名無しさん：2010/05/22(土) 22:44:08

いや、お前らならやりかねないから。

248 ：デフォルトの名無しさん：2010/05/22(土) 23:08:48

>>224
理解不能ならそんでいいが
並列記述がOS依存な言語じゃなく
逆に言語とランタイムに入れちまうってこと。
CSPみたいなのは微妙だし。

んでOS書いたらOS自体も並列実行させやすいし。
スレッドみたいなんが1stクラスなら
OSの記述レベルがあがる。
シグナルとか例外なんかもあつかえるかな

ま、与太話だが、並列実行=OSありきつーのは想像力なさすぎだ
ディスバッチャなんざコアはランタイムに十分入るくらい小さいしな。

249 ：デフォルトの名無しさん：2010/05/22(土) 23:13:52

GCありなし混在は汚い。
せっかくメモリ管理自動にするメリットが
二種類のメモリを管理するコストに相殺されちまう。

250 ：デフォルトの名無しさん：2010/05/22(土) 23:33:06

>>249
ヒープとスタックの混在は？
ファイルとメモリーの混在は？
グローバル変数とローカル変数の混在は？

251 ：デフォルトの名無しさん：2010/05/22(土) 23:41:50

>>250
言ってる意味がわかりません。

252 ：デフォルトの名無しさん：2010/05/22(土) 23:45:13

汚いか汚くないか答えればいいんじゃない？

253 ：デフォルトの名無しさん：2010/05/23(日) 00:05:43

GC混在ができる言語は理論的には可能ですよね。
でも、C++ではポインタの追跡ができないんじゃない？
ポインタ禁止、スタックに配列、クラス、構造体の確保禁止、
配列も指定クラスを使いなんらかのマークが付いている。
スマートポインタのみ許可で、スマートポインタには何かマークが付いている。
マネージドなクラスにはクラス情報へのポインタが追加されている。
アンマネージドな関数呼び出し時はNOGC; a(b); GCON;みたいにする。
例外はとりあえず禁止。
等として、レジスタや中途半端な状態のデータだけは保守的にすれば
このへん適当ですけど、完全なGCはできるのかな？

254 ：デフォルトの名無しさん：2010/05/23(日) 00:13:32

Scalaにunmanagedを追加できると仮に考えて
1つ母音をとるとアンマネージドな意味にすると
そんなに汚くなくかけるんじゃないかなと思ったのですがどう思います？

例)
var a:Int = 0; val a:Int = 0; class A{} struct A{} def a(a:Int){}// managed
vr a:Int = 0; vl a:Int = 0; clss A{} strct A{} df a(a:Int){}// unmanaged

255 ：デフォルトの名無しさん：2010/05/23(日) 00:15:14

C++/CLIが存在している以上、マネージとアンマネージの混在は可能。Javaだって、ライブラリを用意すればアンマネージのヒープも使える。しかし、それらでOSがかけるわけではない。

256 ：デフォルトの名無しさん：2010/05/23(日) 00:19:31

なんでOS書けなきゃならないの

257 ：デフォルトの名無しさん：2010/05/23(日) 00:19:41

>>247
　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼　　　　俺はGC付き言語でGCを作ったことがあるぞ！

　　　　／　　 ⌒（__人__）⌒ ＼
　　　　|　　　　　|r┬-|　　　　|
　　　　＼　　　　 `ー'´　　／
　　　　ノ　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､.
　　ヽ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

258 ：デフォルトの名無しさん：2010/05/23(日) 00:20:38

ちゃんとコピペしろ

259 ：デフォルトの名無しさん：2010/05/23(日) 00:21:30

>>256
OSは神が造り人に与えるものだとでも思っている？

260 ：デフォルトの名無しさん：2010/05/23(日) 00:21:50

GCの話は、
・生ポインタは無し。ただのポインタでもメタデータ付きにするか拡張可能な構造体にする。
・GCは、プリミティブ（ルーチンとか）の管理で必要なら言語として実装する。そうでなければライブラリ
でいいんじゃないの？

もっとプリミティブなポインタとかルーチンの話をしようぜ。

261 ：デフォルトの名無しさん：2010/05/23(日) 00:23:27

>>260
> もっとプリミティブなポインタとかルーチンの話をしようぜ。

以前も同様の書き込みを見たが、話をしたいなら自分から話題を振れ。

262 ：デフォルトの名無しさん：2010/05/23(日) 00:31:23

コンパイラがOSに合わせたコードをはくのであって、コンパイラに合わせてOSがかかれるわけ出刃ない。

263 ：デフォルトの名無しさん：2010/05/23(日) 00:32:02

>>255
現存の処理系による制約はあるが、
言語仕様としてはC++/CLIはCをほぼ完全に包含しているのだから、
CでかけるものはC++/CLIでかける。

即ち、C++/CLIでOSをかける。

264 ：デフォルトの名無しさん：2010/05/23(日) 00:40:01

C++/CLIのランタイムはOSが存在することが前提になっている。また、C++/CLIコンパイラはランタイムが存在してることを前提としている。
一方、Cはランタイムはなくても言語として成立している。

265 ：デフォルトの名無しさん：2010/05/23(日) 00:41:31

現存の処理系による制約はあるが、
言語仕様としてはC++/CLIはCをほぼ完全に包含している

266 ：デフォルトの名無しさん：2010/05/23(日) 00:42:26

>>263
仮にC++/CLIでOS書くとして、低水準な部分は全部#pragma unmanagedでコード書くということ？
たしかにそれでも「C++/CLIで書ける」は偽ではないだろうけど、
CもしくはC++でコンパイルできるコードをわざわざ
C++/CLIコンパイラでコンパイラしているだけという捉え方もできるぞ。

267 ：デフォルトの名無しさん：2010/05/23(日) 00:43:56

どうぞ、お捉えください。

268 ：デフォルトの名無しさん：2010/05/23(日) 00:45:29

>>263
包含してると言っても、水と油が分離している状態だけどな。綺麗に混ざれば問題なかったのだが。

マネージドのクラスのメンバーにC++のオブジェクト変数（ポインタじゃないよ）が作られれば良かったのに

269 ：デフォルトの名無しさん：2010/05/23(日) 00:46:17

新言語では綺麗に混ざるようにしたいね。

270 ：デフォルトの名無しさん：2010/05/23(日) 01:00:16

ふつうは綺麗に分離したいものですが
逆に考えるんですね

271 ：デフォルトの名無しさん：2010/05/23(日) 01:02:27

混ざるというのは、一つの言語仕様に綺麗に入れるってことだろ。
言語仕様の中で上手く統合できるか、綺麗に分離する必要があるかはまた別の議論。

272 ：デフォルトの名無しさん：2010/05/23(日) 01:11:46

GC混ぜる話はループするだけだから無用じゃないか
C++/CLIみたいなゴミを使いたきゃそっち使えばいい
管理情報振ってGCするとか、どんなハイレベルな言語作る気だよ
脳みそ腐ってるやつらばっかだな

273 ：デフォルトの名無しさん：2010/05/23(日) 01:23:41

C/C++とシェルを混ぜてみないか
シェルは文字列しかないからGC楽勝だろ

274 ：デフォルトの名無しさん：2010/05/23(日) 01:25:28

L'Arc?en?Ciel

275 ：デフォルトの名無しさん：2010/05/23(日) 01:33:14

しばらく傍観するわ

GC入れようって訴えてるヤツは「低水準も書ける高水準」を目指してることに気付いてないようだ
本来は完全なスレチなんだが相手するのも疲れた

276 ：デフォルトの名無しさん：2010/05/23(日) 01:37:52

先週も同じことを言ってたよねｗ

277 ：デフォルトの名無しさん：2010/05/23(日) 01:40:56

ガキの頃、「一抜けたー」って言って、誰も付いて来ないからすぐ戻ってくる奴いたよなｗｗ

278 ：デフォルトの名無しさん：2010/05/23(日) 01:42:10

ゆとりはメモリ管理もできないんだ
許してやれ

279 ：デフォルトの名無しさん：2010/05/23(日) 01:47:34

安直でありがちだが、managedとunmanagedで別構文にして管理を分けるんだろうな。

280 ：デフォルトの名無しさん：2010/05/23(日) 01:49:24

そういう流れじゃなかったのに結局自分の知ってるものしか理解できないんだな

281 ：デフォルトの名無しさん：2010/05/23(日) 01:52:23

ですよねー

282 ：デフォルトの名無しさん：2010/05/23(日) 02:19:50

>>275
GC入れちゃうとある程度以下の世界が書けなくかるんだよね
まあmanagedとかの話はほっとくのがいいな

ところで、さっきはアホが寄り付いたが
goroutineとchannelにmutexつかrmcみたいなオペか変数の装飾か
後はレジスタセットみたいな組込みデータ型か
なんてので低レベルな並列言語つーネタはどうよ

283 ：デフォルトの名無しさん：2010/05/23(日) 02:21:27

早速傍観できなくて出てきちゃいました＾＾

284 ：デフォルトの名無しさん：2010/05/23(日) 02:21:42

erlangはふつーにspawnだっけ

285 ：デフォルトの名無しさん：2010/05/23(日) 02:24:13

別人だよ
低レベルな言語にGCとか違和感持つ人間は多いんじゃね

286 ：デフォルトの名無しさん：2010/05/23(日) 02:26:20

別にいいんだよ。匿名掲示板だし。
書き込まれている内容が重要であって、誰が書き込んだかなんて関係ないから。

287 ：デフォルトの名無しさん：2010/05/23(日) 02:31:49

ＧＣ必須といってる奴なんて少数派なのになんでシャドウボクシングしてるんだろうね

288 ：デフォルトの名無しさん：2010/05/23(日) 02:34:18

ですよねー

289 ：デフォルトの名無しさん：2010/05/23(日) 02:35:39

C代替にGC使えたらいいなーはあってもGC前提はなかんべ

290 ：デフォルトの名無しさん：2010/05/23(日) 02:36:34

なら安心した
書き込みが目立つだけか

291 ：デフォルトの名無しさん：2010/05/23(日) 02:41:30

1名勘違いしているのが紛れ込んでいるようだが

GCを使うプログラムも、GCを使わないプログラムも両方書けるようにするには
言語仕様にはGCが入ることが必須になるんだよ。

言語仕様にはGCが必ず入っていて、
その仕様に基づいて作られるプログラムでは、GCを使う、使わないは任意に選べる。

言語仕様にGCが入ったからといって、GCを必ず使わなければならないということはない。

292 ：デフォルトの名無しさん：2010/05/23(日) 02:43:49

混在もあかんやろ
GCはメモリの生存時間をシステムに委ねて楽するわけだ
言語仕様も小さくなってきれいになる
楽とミスを減らすための機能なのに
区別して書くとか逆向き

293 ：デフォルトの名無しさん：2010/05/23(日) 02:44:17

言語仕様に含まれているとド素人ほど使いたくなってしまうからな
そういう意味では言語仕様に含めることはリスクを伴う

CGに反対しているのは自制の意味を込めているのだろう

294 ：デフォルトの名無しさん：2010/05/23(日) 02:46:27

・全てのリソースをGCに委ねる。
・GCに委ねるリソースと委ねないリソースを混在。
・全てのリソースをGCに委ねない。

どれにするかは、開発内容によって選べば良い。

295 ：デフォルトの名無しさん：2010/05/23(日) 02:47:02

ワーニングやコンパイルオプションも言語仕様に含めればいいんじゃないの？

296 ：デフォルトの名無しさん：2010/05/23(日) 02:49:01

うむ。この話は無限ループだな
俺もしばらく様子見。

297 ：デフォルトの名無しさん：2010/05/23(日) 02:49:04

静的と動的も区別できない奴が力説してる

298 ：デフォルトの名無しさん：2010/05/23(日) 02:50:25

>>275 >>296
無限ループって怖いねｗ

299 ：デフォルトの名無しさん：2010/05/23(日) 02:54:14

>>297
反論を恐れてアンカーすらつける勇気ない奴がごちゃごちゃ言うなｗｗ

300 ：デフォルトの名無しさん：2010/05/23(日) 02:54:32

>>299
おまえだよ

301 ：デフォルトの名無しさん：2010/05/23(日) 02:55:59

コードを使いまわしたいというのとGCありとGCなしを同一プログラムで混在させたいというのは別物。

302 ：デフォルトの名無しさん：2010/05/23(日) 03:03:47

話を先に進めたいんならGCなしでやっちゃえよ
どこかの天才が混在可能なオサレな文法作ってくれたらその時に考えればいい

303 ：デフォルトの名無しさん：2010/05/23(日) 03:04:06

>>298
別人だってw
人にケチつけてないで
お前こそなんかネタ振れよw
嫁もワンコも寝ちまってヒマなんだからよ

304 ：デフォルトの名無しさん：2010/05/23(日) 03:12:16

なんか典型的過ぎてイタイ

305 ：デフォルトの名無しさん：2010/05/23(日) 03:18:07

>>302だな

306 ：デフォルトの名無しさん：2010/05/23(日) 03:20:52

ここはGCスレの代理戦争カー！

307 ：デフォルトの名無しさん：2010/05/23(日) 06:04:03

完全なGCをするための、スタックフレームの使い方なのだけど、
アンマネージドな関数とマネージドな関数のスタックフレームは
別々に分けるとGCしやすくていいと思ったのだけどどうだろう？
コルーチンの呼び出しみたいに切り替えるの。
アンマネージド(GC起動前)→GC起動→マネージド→GC停止→アンマネージド
というようにすればいいと思ってたのだけど
スタックが分かれていればこうできるかなと。
アンマネージド(GC起動前)→GC起動&スタック切替→マネージド→スタック切替
→アンマネージド→スタック切替→マネージド…
こんなことがC++/CLIで起こってるのかな？

308 ：デフォルトの名無しさん：2010/05/23(日) 06:27:42

フルーチンとマネージャー

だけ読んだ

309 ：デフォルトの名無しさん：2010/05/23(日) 07:25:53

フルチンマネージャ

310 ：デフォルトの名無しさん：2010/05/23(日) 07:51:27

フルチンじゃなくて、フ・ルーチンな

311 ：デフォルトの名無しさん：2010/05/23(日) 09:44:31

http://source-ore.up.seesaa.net/image/source-ore-2008-06-05T12:53:37-1.jpg

312 ：デフォルトの名無しさん：2010/05/23(日) 10:27:16

>>307
恐ろしくいろんなことを勘違いしてるように感じるのだけど、
その勘違いを紐解けない。Wikipediaのスタック、コールスタック
の記述を読んだだけでコードを書いたこと無い、似非プログラマーが
書いたって感じ。

313 ：デフォルトの名無しさん：2010/05/23(日) 10:58:36

実際につくってないからなｗ
勘違いしてて出来ないならそれはそれでいいんだ。
出来たらいいなってことで、ああしたらできるかな、こうしたら出来るかな？
って考えてるだけなので。今のところ。
GCありなし混在言語なんて、ほとんど誰も作ったことないだろうから
やってみるのがいいんでしょうね

314 ：デフォルトの名無しさん：2010/05/23(日) 11:12:13

スマポをＧＣと認めないとは随分反主流派ですね

315 ：デフォルトの名無しさん：2010/05/23(日) 11:13:33

Objective-C

316 ：デフォルトの名無しさん：2010/05/23(日) 11:33:00

「C言語って、16bitマイコンで動くファームウェアとかの開発でも使われてるんだけど」
「16bitマイコンで動くファームウェアがC言語で書かれているはずがない！」
「えっ？」

317 ：デフォルトの名無しさん：2010/05/23(日) 15:03:30

8bitマイコンを忘れないで

318 ：デフォルトの名無しさん：2010/05/23(日) 16:20:30

基本スマートポインターでいいけどな。ダメなケースをコンパイラが検出してくれれば。

319 ：デフォルトの名無しさん：2010/05/23(日) 16:31:32

メモリ管理は自分でやりたい

320 ：デフォルトの名無しさん：2010/05/23(日) 16:32:54

自分でやりたい人は、自分でやれるように
処理系にやらせたい人は、処理系にやらせれられるように

両方対応するのが望ましい。

321 ：デフォルトの名無しさん：2010/05/23(日) 16:33:17

>>319
スマポなら、自力管理から自動管理まで用途に応じて幅を持たせられるから便利だね。

322 ：デフォルトの名無しさん：2010/05/23(日) 16:34:31

>>314
しー、言っちゃだめよ。議論が終わっちゃうでしょ。

323 ：デフォルトの名無しさん：2010/05/23(日) 16:36:43

「スマポをＧＣと認めない」なんて話題出してるのは>>314だけだけどな。

324 ：デフォルトの名無しさん：2010/05/23(日) 16:58:08

>>323
君には理解できなかったんだね残念

325 ：デフォルトの名無しさん：2010/05/23(日) 17:02:23

まあ落ち込むな。
次は人に理解してもらえるように頑張れ。

326 ：デフォルトの名無しさん：2010/05/23(日) 17:04:16

あんまり頑張れとか言うと自殺しちゃうよｗｗ

327 ：デフォルトの名無しさん：2010/05/23(日) 17:05:45

具体的な指摘が出来ないから煽り始めた

328 ：デフォルトの名無しさん：2010/05/23(日) 17:06:07

人に理解してもらう前に、理系学部（計算機学科じゃない）なら
一般教養で勉強するレベルの事すら理解してないで、そこまで
理解してる人はいないんだからと書いてるやつは、勉強しなおすべきだと思う
http://pc12.2ch.net/test/read.cgi/tech/1152200420/
いいスレがあるんだけど、この本を読めるレベルじゃなくて、
書けるレベルがここに参加していい最低限度のレベル。

329 ：デフォルトの名無しさん：2010/05/23(日) 17:08:01

Japanese is ok.

330 ：デフォルトの名無しさん：2010/05/23(日) 17:08:11

>>313-314と読んで>>323なら人工無脳としか思えん

331 ：デフォルトの名無しさん：2010/05/23(日) 17:09:47

>>314が必死過ぎて笑える

332 ：デフォルトの名無しさん：2010/05/23(日) 17:10:57

横だけど必死なのはお前に見える

333 ：デフォルトの名無しさん：2010/05/23(日) 17:11:46

横ｗ

334 ：デフォルトの名無しさん：2010/05/23(日) 17:12:56

ここまで全部俺の自演

335 ：デフォルトの名無しさん：2010/05/23(日) 17:14:19

いや俺の自演

336 ：デフォルトの名無しさん：2010/05/23(日) 17:40:51

結局、プログラミング言語はリソース管理を如何に行うかだからな。

この分野はさんざん研究されているだろうから、
最新の最も簡単に安全に効率よく出来る手法を持ってきて
あとは最近ハヤリの構文や機能と上手く融合出来れば良いね。

337 ：デフォルトの名無しさん：2010/05/23(日) 17:42:14

リソース管理って?なんか言葉がちょっと抽象的な感じがするんだけど。
具体的にはどんなこと?

338 ：デフォルトの名無しさん：2010/05/23(日) 17:48:19

メモリー、ファイル、通信、プロセス、スレッド、各種デバイス、他

339 ：デフォルトの名無しさん：2010/05/23(日) 17:50:02

排他制御とかも

340 ：デフォルトの名無しさん：2010/05/23(日) 17:51:32

そっかw というか、「この分野」じゃなくて、全部じゃないかw

341 ：デフォルトの名無しさん：2010/05/23(日) 17:54:03

全部っていっても、リソースそのものの扱いではなく、その生成／消滅を扱う分野だろ？

342 ：デフォルトの名無しさん：2010/05/23(日) 17:56:15

じゃあメモリ確保とか、ガーベージコレクタとか、いつもの話題に戻るわけね。

343 ：デフォルトの名無しさん：2010/05/23(日) 18:02:46

>>336-342
ＯＳとプログラミング言語を意図的に（もしくは白痴）
混同してる。そしてそのことに何の疑問ももたない自作自演。
もうね、本当にね。バカばっかり。

344 ：デフォルトの名無しさん：2010/05/23(日) 18:03:31

>>343は病気なので触れないでください。

345 ：デフォルトの名無しさん：2010/05/23(日) 18:13:18

いい記事があったんだけど、
ポインターの定義構文と使用構文にやっぱ問題あるよな。
http://builder.japan.zdnet.com/sp/c-programming-language/story/0,3800083430,20370255,00.htm
これでもかって言うぐらいに、間違えてくれてるんだ。
これを反面教師にして、ポインターの宣言とアドレスの取り扱い
周りの構文を考えたいんだけど、どうかな、Ｄ言語の場合が
参考になるわけなんだけど、Ｄ言語レベルで充分かなとも思うし。

それにしても、この人、良くこの文体で書けるなぁって思う。
ＩＢＭでこの文体で、この内容ってことは、
キ○○イに近いような気がする。

346 ：デフォルトの名無しさん：2010/05/23(日) 18:13:31

言語自体が扱うのはCPUとメモリ
スレッドはアリだな
occamみたいなん面白い

347 ：デフォルトの名無しさん：2010/05/23(日) 18:34:47

とりあえず

絶　対　に　入　れ　る　な

って機能先に洗い出して、残った物に優先順位つけてけばいいかと

348 ：デフォルトの名無しさん：2010/05/23(日) 18:39:10

超高速が目的なんで、VMとGCは絶対入れない機能だな

349 ：デフォルトの名無しさん：2010/05/23(日) 18:44:08

絶対に入れたいのは、並列処理だね
デフォルトでマルチスレッド・マルチコア環境前提でいい

350 ：デフォルトの名無しさん：2010/05/23(日) 18:50:30

並列化のスレッディングのアルゴリズムを記述できてライブラリとして供給する。
言語仕様に固定で組み込むのは駄目。あくまでもすべてを記述できる低級言語

351 ：デフォルトの名無しさん：2010/05/23(日) 18:57:23

絶対に入れるな？
variant型とかか

352 ：デフォルトの名無しさん：2010/05/23(日) 19:00:13

variant、GCは言語仕様に入れない。使いたい人がライブラリで実装すればいい。

353 ：デフォルトの名無しさん：2010/05/23(日) 19:06:22

「入れない」って列挙したものについては、
少なくとも設計がひと段落するまでは（欲しいか欲しくないかは別にして）
仕様に関係する議論から排除できるな

354 ：デフォルトの名無しさん：2010/05/23(日) 19:12:54

トリップをつけて「入れない」と宣言した機能は、そのトリップではその機能を議論しないという決断だと受け止めていいよ。
その他の自由な議論を阻害するものではない。

355 ：デフォルトの名無しさん：2010/05/23(日) 19:16:27

入れると言った人もトリップ付けて、責任もって入れることにしたら
議論が正常化すると思う。ＣＰＵは問わないけどもアセンブラリストを
要求された時点でＵＰする事。にすれば良いと思う。

356 ：デフォルトの名無しさん：2010/05/23(日) 19:16:28

どうせ本気で言語なんて作らないくせに

357 ：デフォルトの名無しさん：2010/05/23(日) 19:17:51

>>356
>>354-355で、本気の人だけになると思う。
そしてトリップ無しでの発言は基本荒らし行為って
事にすれば良いんだよ。

358 ：デフォルトの名無しさん：2010/05/23(日) 19:20:18

なるほど。
つまり>>357は荒らし行為ってことだな。

359 ：デフォルトの名無しさん：2010/05/23(日) 19:26:43

ある程度議論ルール固まったらＷｉｋｉってもいいかもんね
鳥無しの基本嵐認定は行き過ぎだが、鳥有り議論に対する影響を少なくするってのはありだな
要望っていうかスタンスがあるなら鳥つけろ、妄想垂れ流すだけで邪魔するなら荒らし認定されるんだろう
論理的で根拠がある話なら鳥有りが意見を組み入れるだろうし

360 ：デフォルトの名無しさん：2010/05/23(日) 19:28:18

>>352
初心者が全部の機能を使いたくなる気持ちはわかるけど
言語仕様に入っていても不要な機能は使わなければいいだけだよ。

361 ：デフォルトの名無しさん：2010/05/23(日) 19:29:29

議論するのはいいけどさ
コンパイラ作れる奴いるの？
いたとして、作る気あんの？
そこ抜きに話しても無駄に終わるぜ

362 ：デフォルトの名無しさん：2010/05/23(日) 19:32:33

>>359
「鳥付けろ！」とか「鳥無しばかりだから傍観するわ」とか言って荒らす奴が出てくるから鳥を余り強調しない方がいい。
付けたい奴が付けるだけでいい。
発言を尊重するかどうかは、鳥の有無によってではなく、あくまでもその内容によるべきだ。

363 ：デフォルトの名無しさん：2010/05/23(日) 19:34:24

>>362
確かにそうだな

364 ：デフォルトの名無しさん：2010/05/23(日) 19:34:28

>>359
Ｗｉｋｉは議論に向かないので、fj.comp.langに移動が良いと思う。
fj.comp.lang.cを間借りさせてもらうか、場合によっては作ってもらう
ってことで。雑音はいりにくいし（ｗ

365 ：デフォルトの名無しさん：2010/05/23(日) 19:37:23

>>363
そんなこと無いと思うよ。とりなしを無視できな奴もバカって
事にすれば良いだけ。とりなしをＮＧＩＤにすればすっきりするし。
ということで、鳥必須ってことで。

366 ：デフォルトの名無しさん：2010/05/23(日) 19:40:45

IDないぞ

367 ：取りに行くです ◆JZ1SFn6i7c ：2010/05/23(日) 19:43:14

>>366
あっそうか、じゃあ鳥+コテハンって事で、デフォルト名無しさんを
ＮＧワードにするって事で。

368 ：デフォルトの名無しさん：2010/05/23(日) 19:44:07

お好きにどうぞ。

369 ：デフォルトの名無しさん：2010/05/23(日) 19:46:10

そこまで仕切って仕様を確定までして
コンパイラ作る技量ないとか言ったら
全部無駄になるんだが
そこんとこ分かってんのか？

370 ：デフォルトの名無しさん：2010/05/23(日) 19:48:23

どのレスを読むかは個々人で好きに決めればいいと思うよ。
NGもわざわざ宣言せずに黙ってやればいいし。

このスレでは内容にかかわらないところで発言の仕方を縛るようなことは一切しない。
レスの取捨選択はあくまでも個々人でやるべきことだから。

371 ：取りに行くです ◆JZ1SFn6i7c ：2010/05/23(日) 19:49:39

以下いらない宣言。
ＧＣ　多値戻り

372 ：デフォルトの名無しさん：2010/05/23(日) 19:51:40

既にNGされてる気がする

>>371
お前はコンパイラ作れるのか？
まずそれが知りたい

373 ：デフォルトの名無しさん：2010/05/23(日) 19:54:30

そういえば、多値戻りの話もあったなｗ

多値を扱うデータ型を用意して、関数（メソッド、サブルーチンコール、…）の入出力で自由に使えるようになっていると便利だな。

374 ：デフォルトの名無しさん：2010/05/23(日) 20:06:17

やはりC言語は神の作りたもうた言語だな

375 ：デフォルトの名無しさん：2010/05/23(日) 20:09:56

館はタプルでライブラリ行き。
ライブラリでできるものはライブラリにしないといつまでも作れないよ。
低級言語だから欲張らないことだ。

376 ：デフォルトの名無しさん：2010/05/23(日) 20:34:10

無名メンバー名無しの構造体と考えたら
タプルは基本データでいいんじゃない

377 ：デフォルトの名無しさん：2010/05/23(日) 20:37:40

C++0xみたいに構造体をreturnで初期化可能にする文法と
型推論のautoを導入すれば

struct { int a, b, c; } foo() { return { 1, 2, 3 }; }
auto x = foo();
printf("%d, %d, %d\n", x.a, x.b, x.c);

のようなことができる

378 ：デフォルトの名無しさん：2010/05/23(日) 20:54:34

すげーわろた

379 ：デフォルトの名無しさん：2010/05/23(日) 21:21:19

>>377
俺もそれがいいと思う。

380 ：デフォルトの名無しさん：2010/05/23(日) 21:22:07

http://www.objectclub.jp/ml-arch/extremeprogramming-jp/4800/thread.html

GCに関する議論がこの辺にありました。
考えてる人は考えているのですね。

381 ：デフォルトの名無しさん：2010/05/23(日) 21:28:28

C++でのGCについては0xで議論されてるよ。
結局入らなかったけど。

382 ：デフォルトの名無しさん：2010/05/23(日) 21:53:32

variantは、言語仕様にいれても低水準とは矛盾しない。
ライブラリでも実現できるが、見た目は悪くなる。

383 ：デフォルトの名無しさん：2010/05/23(日) 22:14:08

透過的なガーベジコレクションですか。
http://d.hatena.ne.jp/faith_and_brave/20081117/1226913980
結論からいうと、 C++0x に GC は入りません。
C++0x では、透過的な GC の導入が間に合わないので、
最低限の決めごとだけを行います。

なるほど。Hans Boehm 直々のペーパーもある。

384 ：デフォルトの名無しさん：2010/05/23(日) 22:23:50

>>380
日付を見ろよ、終わった議論なんだよ（ｗ

385 ：デフォルトの名無しさん：2010/05/23(日) 22:44:46

終わった議論であるなら、その結論は？

386 ：デフォルトの名無しさん：2010/05/23(日) 23:03:50

結論を問うと止まるスレ

387 ：デフォルトの名無しさん：2010/05/23(日) 23:21:49

>>382
variantの実行時オーバーヘッドってどうなの？
オーバーヘッドの程度によって使える場面は制限されるよね。

388 ：デフォルトの名無しさん：2010/05/23(日) 23:40:28

>>387
どれだけオーバーヘッドがあっても、言語仕様上は問題ないでしょ。
コプロがないと浮動小数点演算は整数演算の何百倍もかかるけど、言語仕様上は何の問題もない。

389 ：デフォルトの名無しさん：2010/05/23(日) 23:42:06

だから、別に言語仕様上問題あるなんて一言も言ってないよ。
オーバーヘッドがどれくらいなのかなって聞いているんだよ。

390 ：デフォルトの名無しさん：2010/05/23(日) 23:47:27

>>389
オーバーヘッドがあると何か不都合か？

391 ：デフォルトの名無しさん：2010/05/23(日) 23:48:08

C/C++に代わる低級言語を開発したい

なんのために？　趣味？

392 ：デフォルトの名無しさん：2010/05/23(日) 23:49:27

>>390
程度によって使える場面が限られるでしょ？

最内周ループでは使わないようにしようとか。

393 ：デフォルトの名無しさん：2010/05/23(日) 23:54:42

>>392
その程度は実装によるから何とも言えないでしょ。
現実場面では、自作の共用体を使っていろいろするよりも高速になることが多いと思うが。

394 ：デフォルトの名無しさん：2010/05/24(月) 00:03:36

実装によるのは当然だけど、
例えば、実装によって型情報を保持する分負荷が増えるとか、
定性的な議論ができればと思って聞いたんだけどね。

いいや、別に。

395 ：デフォルトの名無しさん：2010/05/24(月) 00:17:43

トリップ入れてない人を相手にするのも嵐です。

396 ：デフォルトの名無しさん：2010/05/24(月) 00:26:30

ここから俺の自演だから

397 ：デフォルトの名無しさん：2010/05/24(月) 01:31:14

リフレクションは欲しい

398 ：デフォルトの名無しさん：2010/05/24(月) 02:09:31

リフレクションって設計に失敗してるプログラムで使うイメージしかない

399 ：デフォルトの名無しさん：2010/05/24(月) 03:11:11

結局低レベルってのから一瞬で離れるんだな

400 ：デフォルトの名無しさん：2010/05/24(月) 03:24:03

名前付き引数に対応してね☆ミ

401 ：デフォルトの名無しさん：2010/05/24(月) 03:43:27

クロージャと継続もほしいゆ

402 ：デフォルトの名無しさん：2010/05/24(月) 07:38:32

欲しい → 不要
あったら嬉しい → 不要
必要 → まれに必要
どうしても必要 → たまに必要
必ず必要 → もしかしたら必要

403 ：デフォルトの名無しさん：2010/05/24(月) 08:01:31

>>401
同意

404 ：デフォルトの名無しさん：2010/05/24(月) 09:18:39

名前付き引数は低レベルでも問題ない

405 ：デフォルトの名無しさん：2010/05/24(月) 09:24:06

リフレクションも低レベルでも問題ない。

406 ：デフォルトの名無しさん：2010/05/24(月) 09:28:27

c++0xでの議論
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2507.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html

407 ：取りに行くです ◆JZ1SFn6i7c ：2010/05/24(月) 15:11:06

リフレクションはいらない。

名前付き引数は、コンパイル時にオーバーヘッドが解消できる事と、
（コンパイラが呼び出し関数に合わせて順番変えてやれば良いだけ）
関数定義や例外処理を変更したいって言ってる俺としては、有りかもと思う。

408 ：デフォルトの名無しさん：2010/05/24(月) 17:30:00

>>407
だからお前コンパイラ作れるの？

409 ：デフォルトの名無しさん：2010/05/24(月) 17:40:49

>>408
バカばかりでお前もバカの一員だと思うんだけど、
しつこいから答えると、その質問する奴がバカだと思う。
最適化ぶりぶりのコンパイラ作るのには、物凄いセンスが
必要だけども、コンパイラってようは単純なテキスト置換
処理なんだから、コンパイラを作れないと言う奴は、プログラムを
組めないと言ってるに等しい。つまり質問が無茶苦茶なんだよ。

そんな質問を平気でするのは馬鹿だからバカは黙ってて欲しい。

410 ：デフォルトの名無しさん：2010/05/24(月) 18:02:16

リフレクション自体は実行時にオーバーヘッドがあるかもしれないが、
リフレクションが有っても他の機能を阻害することはないから
リフレクションは言語仕様に含めていいと思うよ。

411 ：デフォルトの名無しさん：2010/05/24(月) 18:18:45

> コンパイラってようは単純なテキスト置換処理なんだから

シンボルテーブルまで作って単純なテキスト置換処理はないわな

412 ：デフォルトの名無しさん：2010/05/24(月) 18:27:23

シンボリックテーブルじゃね？

413 ：デフォルトの名無しさん：2010/05/24(月) 18:32:36

シンボリティフィケーショニングテーブル

414 ：デフォルトの名無しさん：2010/05/24(月) 18:39:03

シリコン？

415 ：デフォルトの名無しさん：2010/05/24(月) 18:45:24

>>409
つまり取りに行くです ◆JZ1SFn6i7c はこういう考えの持ち主なわけね

コンパイラ＝テキスト置換ツール

OK把握した

416 ：デフォルトの名無しさん：2010/05/24(月) 18:52:14

>>409
どこまでヌケサクなの？
そのテキスト置換処理において、膨大な置換ルールを破綻無く実装する能力を持ってるか聞いてるんだけど？
質問が滅茶苦茶なんじゃなく、お前の読解力が滅茶苦茶貧弱なんだよ。

417 ：デフォルトの名無しさん：2010/05/24(月) 18:59:33

>>416
バカを重ねるな。

418 ：デフォルトの名無しさん：2010/05/24(月) 19:03:20

お前がなｗ
特徴的な改行、いつものキチガイ君だろ

419 ：デフォルトの名無しさん：2010/05/24(月) 19:09:27

俺もそう思う

420 ：デフォルトの名無しさん：2010/05/24(月) 19:11:48

>>409
私には無理なので貴方が作って下さい

421 ：デフォルトの名無しさん：2010/05/24(月) 19:41:31

>>420
黙ってれば良いと思う、君に出来るのはそれだけ。

422 ：デフォルトの名無しさん：2010/05/24(月) 19:48:26

>>421
作らないのならあんたも黙ってろ

423 ：デフォルトの名無しさん：2010/05/24(月) 19:50:57

あたいもそう思う。

424 ：デフォルトの名無しさん：2010/05/24(月) 20:00:14

このスレにはそれぞれが出来る範囲で参加すればいいよ。
何かを作らないから書き込んではいけないとか、そういうことは一切ない。

425 ：デフォルトの名無しさん：2010/05/24(月) 20:09:30

でもコンパイラ作る人が一人もいなけりゃ絵に書いた餅で終わるで

426 ：デフォルトの名無しさん：2010/05/24(月) 20:11:02

絵に描いたもちでも綺麗に書けてればいいと思うんだけど、
お餅とウンコの区別がつかない人が書き込むから駄目。

>>424
遊び場欲しくてそんなこと書いちゃうバカなんだと思うけど
バカの遊び場じゃないよ。

427 ：デフォルトの名無しさん：2010/05/24(月) 20:12:22

また病気の人が来てるね。

428 ：デフォルトの名無しさん：2010/05/24(月) 20:12:43

コンパイラという形にならない事が分かってたら
議論する気も起きない

429 ：デフォルトの名無しさん：2010/05/24(月) 20:15:17

議論する気が起きないなら書き込まなくていいよ

430 ：デフォルトの名無しさん：2010/05/24(月) 20:17:37

6スレにもなって成果が全く無い理由を考えてみたまえ
みんな適当に書き捨ててるだけなんだよ
取りまとめ役と処理系制作者がいないと
進むものも進まない事くらいそろそろ分かれ

431 ：デフォルトの名無しさん：2010/05/24(月) 20:24:20

>>430
＞6スレにもなって成果が全く無い理由を考えてみたまえ
バカが書き込んでスレを汚すから。

432 ：デフォルトの名無しさん：2010/05/24(月) 20:24:39

自己紹介乙

433 ：デフォルトの名無しさん：2010/05/24(月) 20:44:10

わ、わたし１４歳で胸の大きさに悩んでる女子中学生のおっさんだけど、この流れみてたらコンパイラ作る勉強してもいいかな、・・・って思っちゃった///

434 ：デフォルトの名無しさん：2010/05/24(月) 20:48:04

まとまらない原因は、スレタイに性質の異なる２言語を入れてしまっていること。
次は、CとC++でスレを分割すべし。

435 ：デフォルトの名無しさん：2010/05/24(月) 21:07:12

てか、このスレって簡単なコンパイラくらい
作ったことあるやつばっかじゃないの
普通高校生か大学生あたりで作るだろ

436 ：デフォルトの名無しさん：2010/05/24(月) 21:07:47

「超高速」「低級言語」を分かってない者が多いので、「【GC】低速高級言語【VM】」にも分割すべし

437 ：デフォルトの名無しさん：2010/05/24(月) 21:18:49

>>434
同意。

てか、たぶんCを超えるのは無理だからC++だけでいいんじゃね

438 ：デフォルトの名無しさん：2010/05/24(月) 21:20:38

０オーバーヘッドならどんなに文法が汚くても許容する。C++サイコー

439 ：デフォルトの名無しさん：2010/05/24(月) 21:25:15

C++は汚すぎる

440 ：デフォルトの名無しさん：2010/05/24(月) 21:26:31

>>434
まさに第二のCが目標なら、やることやれることは
そんなに多くないんじゃないかね。それでさえ迷う部分は多いがｗ

技術の進歩に伴って、いくつかの仕様は削れる
（register指定子、プロトタイプ宣言など）
長い歴史の中でC文法の問題点も明らかになってきた

でも本質的な部分はそれほどいじりようがないはず。Cはよくできてる
スレッド周りのサポートを入れて、あと名前空間とライブラリ？

超高速なんて簡単に言うが、アグレッシブな最適化を期待するなら
言語としての表現力に制約を加えて、処理系が仮定していい条件を増やしてやらないとダメ
プログラマが低水準を精密に操作したいという要求とは、かなり背反してしまう

441 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 21:32:58

>>440
お前センス無いなぁ、最適化を強力にするためには言語の表現力を
高めないと駄目なんだよ。ポインターと整数を可換にしたから
ポインター演算と整数演算の最適化に苦労したんだよ。

なので、関数にParametor引数、Result引数なんだよ。
そして関数属性；const関数、pure関数、General関数

442 ：デフォルトの名無しさん：2010/05/24(月) 21:36:01

Parametor

443 ：デフォルトの名無しさん：2010/05/24(月) 21:40:47

>>440
FORTRANコンパイラの最適化は神だからなｗ
Cのrestrictなんてのも結局プログラマ責任だし。
しかし文法的な問題ってさほどなくないか？

444 ：デフォルトの名無しさん：2010/05/24(月) 21:41:58

>>440
C++のautoやC#3.0程度の型推論はつけられるだろうし欲しい
個人的にはコルーチンもあると良い

最後らへんはFortranのほうがベクトル演算最適化しやすいとか
純粋関数型のほうが並列化しやすいとか
手書きループより抽象化されたmap/reduceのほうがいいとかいう話だよね？
基本的には同意

445 ：デフォルトの名無しさん：2010/05/24(月) 21:49:22

だれか441にも突っ込んでやって下さい

446 ：デフォルトの名無しさん：2010/05/24(月) 21:53:35

型推論は欲しいね。

447 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 21:54:16

>>445
レベルが違いすぎて無理だと思うよ。
442の為に、ちゃんとポイントは作ってあげた。
らそこは速攻だったのでその程度人しか今はいないと思う
>>442レベルの人が書き込まなくならないと無理だと思う。

448 ：デフォルトの名無しさん：2010/05/24(月) 21:55:10

らそこ

449 ：デフォルトの名無しさん：2010/05/24(月) 21:57:41

コンパイル時に処理できるものはどんどん入れてもいいな。

450 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 22:16:30

>>449
ランタイムを必要しないものと、
型安全性を破壊しないものは
有っても困らないとは思う。
データーの型はプログラマが明示的に破壊しない限り、
破壊できない事変わらないことが大切だと思うんだよね。
なので暗黙の型変換とかautoは禁止が良いと思う。
あと、autoはテンプレートにとっておきたい気もするし。

ともかく、安全に組める、早くできるという方向で行くべきだと思う。

451 ：デフォルトの名無しさん：2010/05/24(月) 22:19:40

autoは型安全だよね。

452 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 22:21:33

>>451
プログラマが理解してない場合がありえる、
と言う意味で型安全じゃない。

プログラマが理解してないのにコンパイルが通るので駄目

453 ：デフォルトの名無しさん：2010/05/24(月) 22:23:28

オレ定義

454 ：デフォルトの名無しさん：2010/05/24(月) 22:25:38

一文一文プログラマーの理解度をチェックする対話型コンパイラーとかいいね。

455 ：デフォルトの名無しさん：2010/05/24(月) 22:27:14

>>454
コンパイルする人間からプログラマを推定するのが型安全じゃないだろｗ

456 ：デフォルトの名無しさん：2010/05/24(月) 22:28:47

>>441
CPU固有言語君は美的センスを磨いた方がいい
C#とかC++に汚染されてる
中途半端な言語じゃなくLispとSmalltalk勉強しておいで。

457 ：デフォルトの名無しさん：2010/05/24(月) 22:29:43

触っちゃダメ

458 ：デフォルトの名無しさん：2010/05/24(月) 22:34:06

まあしかし関数型言語もいずれはPrologと同じ道を辿って
20年後もCを使っている気がするな

459 ：デフォルトの名無しさん：2010/05/24(月) 22:35:50

Prologより関数型言語の方が古いけどな

460 ：デフォルトの名無しさん：2010/05/24(月) 22:38:04

20年内に論理型言語の復権はありそうだけど。

461 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 22:40:23

>>456
aa.x86_rot(bit=CF)を提案してのは俺だけど、CPU固有言語という
言葉の元になったのは別人だと思う。
environmentというコテハンは一回使ったかなっておもう

後、継承はともかく、クラス、カプセル化は必須。

462 ：デフォルトの名無しさん：2010/05/24(月) 22:41:14

APLの復権はまだか

463 ：デフォルトの名無しさん：2010/05/24(月) 22:45:21

メンバーを指定するであろう位置に予約語を置いてしまう美的感覚が凄い
名前空間は無用に荒らしたくないよね

464 ：デフォルトの名無しさん：2010/05/24(月) 22:49:58

>>449
マクロ、テンプレート
型推論

465 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 22:51:43

>>463
お馬鹿な君達の為にあえてああやって書いて、
それじゃあそうなるから、こういう記述が
良いんじゃないかとか言わしてあげられるように
してあげてるのに、ぶーぶー文句言うばかり。

466 ：デフォルトの名無しさん：2010/05/24(月) 22:55:45

特に魅力があるわけでもない得体のしれないものを良くしようとは思わない。
どんなに酷くても何か一つでも輝きがあればいいんだけどね。

467 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 22:57:19

>>464
マクロ→廃止
型推論→いらない
テンプレート→STLとはまったく別物（記述がわかりにくすぎるよ！！）
テンプレート実現のための型推論は必要。

>>466
なに？俺のこと？俺の提案の魅力を理解できない奴は書き込むなよ。

468 ：デフォルトの名無しさん：2010/05/24(月) 22:59:12

ちょいお遊びでキャリーを扱うのを考えてみた
あれほどのvolatileなデータだからやはり特殊変数以外ない
で'.'をキャリー、@をローテートとして
a = b + c
d = e + .
d = e +. f
これでADD/w C
a <<@ でローテート
a <<@. でローテートwC

ただのマクロアセンブラのようだ

469 ：デフォルトの名無しさん：2010/05/24(月) 23:01:23

Cの型は安全のためではなくて、アドレスやサイズを計算することが目的。
危険か安全かは関係なく、ただ書かれた通りに計算するだけ。
型＝安全という論点を強調するとCの代替案にはなれない。

470 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/24(月) 23:03:09

>>469
そこは哲学が180度ちがう、Cの欠点はそう考えた事だから
C/C++の代替を目指すなら、その欠点は構文が変わろうが
解消するって事だよ。

なので議論しようがない。C使ってろで終わってしまう。

471 ：デフォルトの名無しさん：2010/05/24(月) 23:03:32

>>469
そうだね。そういう低レベルな記述は必要だろうね。

472 ：デフォルトの名無しさん：2010/05/24(月) 23:06:42

>>471
自作自演するなよ、この頓珍漢。

473 ：デフォルトの名無しさん：2010/05/24(月) 23:08:00

>>468
キャリーは演算の副産物だから扱いむずいな
いつ変化するかわからんし
最適化の影響も受けるし。

474 ：デフォルトの名無しさん：2010/05/24(月) 23:11:42

文字定数がint扱いとか止めて欲しい。

475 ：デフォルトの名無しさん：2010/05/24(月) 23:13:04

>>470
安全って一体なんなのか誰も定義しないから、定義のない概念は無視するという哲学
と180度ちがう哲学？

476 ：デフォルトの名無しさん：2010/05/24(月) 23:31:20

>>474
組み込み型は（あるとしたら）整理しないとね

477 ：デフォルトの名無しさん：2010/05/25(火) 00:39:10

組み込み型で入れたいもの

文字列、正規表現、XML、Query、任意精度、

他にある？

478 ：デフォルトの名無しさん：2010/05/25(火) 00:44:12

ばかだろ

479 ：デフォルトの名無しさん：2010/05/25(火) 00:52:26

>>477
SIMDに対応できるようにベクトル、行列はあった方がいいかもな。

480 ：デフォルトの名無しさん：2010/05/25(火) 00:53:44

またドバイタワー建築中か

481 ：デフォルトの名無しさん：2010/05/25(火) 00:58:44

>>477
プロセス、スレッド、イベント、割込み、シグナル／セマフォ／ミューテックス、タイマー

482 ：デフォルトの名無しさん：2010/05/25(火) 01:41:44

Complex, map, sliceもだな
>>481
絞り込むとスレッドかコルーチンと
通信channelとrmc命令があればいいな

483 ：デフォルトの名無しさん：2010/05/25(火) 01:47:16

Dでいいじゃん
作るならDくらい越えてくれよ

484 ：デフォルトの名無しさん：2010/05/25(火) 01:49:52

goでいいじゃん
Ken Thompson位超えてくれよ

485 ：デフォルトの名無しさん：2010/05/25(火) 01:54:51

>>441他

まず高速化は絶対無理。歴史のある巨大プロジェクトのGCCの吐くコードでさえ
VCより30%遅いとか言われてるのにここのメンツじゃVCより数倍遅いのしか作れない。
だから開発効率を売りにして勝負しなかったら判断力のないアホしか使ってくれない。

開発効率を求めるなら
・ライブラリが充実していて自分で書かなくともよい
・高性能なデバッガやIDEが付属
っていうのが最低線だが言語仕様とかどうでもいいこと議論してるようじゃ終わってる。

もちろんCのライブラリがリンクできれば独自に用意しなくていいとかそういうのは論外。
それじゃ言語の新しい機能は使えないしライブラリ付属のサンプルがそのまま動作しない
なら開発効率は最悪になる。
別の言語のデバッガで仕事するとかありえないので、Cのコンパイラは流用できても
Cのデバッガは流用できないから新規に作らないといけないわけだ。

で誰が作るの？テストは？重大なバグが見つかったら誰が直すの？
ここ言語仕様考えるとかWiki立てるとか楽な仕事しかやる人いないじゃないw
その面倒な汚れ仕事やる人いないなら作れないに決まってるよね？

486 ：デフォルトの名無しさん：2010/05/25(火) 01:57:23

言語作成で一番重要なのはライブラリだな
間違いない

487 ：デフォルトの名無しさん：2010/05/25(火) 01:57:36

それとね、プログラミング言語は匿名では作れないんだよ。
海外のOSSのプロジェクトに投稿してみればわかるけど住所氏名勤務先連絡先
どころか、身分証明と勤務先の上司の承諾書まで要求されるんだぜ。
実は一部にGPLからの盗用されたコードが混ざってましたwではシャレにならないわけ。
2chで匿名の人をいくら集めたって意味ないだろ...

488 ：デフォルトの名無しさん：2010/05/25(火) 02:04:39

最小構成のコンパイラが手軽に作れるといいんだけど。
pccみたいな。

489 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 02:04:50

>>486
俺も実はそう思ってる。ライブラリの中身が不明だから
最適化をかけれない、処理を端折れない、ライブラリが
そもそも遅いってのが、いろんな問題の根っこなんだろうと
思うんだよね。なので、const関数、pure関数の階層化が
必要で、コンパイルエラーではじきまくる所から始まると
思う。なので関数に修飾つけなければconst扱いにして
ブロック変数と戻り値以外を変更したらすかさずコンパイルエラー
という極めて過酷なプログラミング環境が必要だと思うんだよね。

後から指定して矛盾してたら未定義とか、register変数みたいに
コンパイラの気分ってのは駄目だと思う。

>>487　2chでいい加減無理となったら別で始めるわけだ。
別に匿名に拘ってる訳じゃないし。
まともな議論できる人がちゃんと現れたら、fj.comp.lang.cへ移動しよう
と思ってる。

490 ：デフォルトの名無しさん：2010/05/25(火) 02:17:28

「取りに行くです。」はとにかく、
コンパイラにたくさん情報を与えて高速化したいってのはわかった。
でも関数定義長すぎだ。短く出来ないのかい？
void f(int a,int b, int c, int* e, int* f, int* g);を
void f Parameter(int e,int f,int g) Result(int* a,int* b,int* c);
と書くより
(int,int,int) f(int e,int f,int g)と書いた結果があなたの言っている構文より
わかりやすいし短く書ける思うのだけど。
左辺は結果で右辺はパラメータとする。
位置によって意味が変わるのでキーワードを２つ消して短く出来る。
あと部分適用はカリー化するのがセオリーだ。
(int,int) f(int a, int b)(int c,int d)
と書いて、a,bがモードにすれば部分適用もして欲しいって意味になっていい。
Param,Mode,Resultのキーワード３つ消せる。

491 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 02:21:12

>>490
可読性は重要だよ、書くのが面倒というより、
１００００倍可読性が重要。
読みやすくする提案なら聞けるけど記述端折るのは
いただけない。

492 ：デフォルトの名無しさん：2010/05/25(火) 02:26:12

ライブラリ作るのが大変なのはわかる。
だけど、構文がC言語以下になったら駄目だ。
構文が決まらないうちにライブラリを作っても
構文が変わるたびにライブラリを作り直さなくてはならなくなる。
Cは３５年以上使われてるものだから１つ１つ丁寧に作り上げるべきだ。

493 ：デフォルトの名無しさん：2010/05/25(火) 02:37:07

>>491
端折ってません。
Haskellならfの型はf:(int,int)->(int,int)->(int,int)と書きます。
Scalaならf(a:Int,b:Int)(c:Int,d:Int):(int,int)と書きます。
カリー化の概念は幾つでも部分適用が可能なことです。
f:int->int->int->int->intというような記述も可能でより一般的な記述方法です。
あなたのいうモードは多値のカリー化が１つだけしか出来ないわけで記述力は
カリー化より劣っています。

494 ：デフォルトの名無しさん：2010/05/25(火) 03:00:32

なんか斜め遙か下方の議論だな
Param,Result,Mode?なんて雑音がコードに入ったら可読性悪いし
カリー化なんてのは高階な言語でこそ生きる話だと思うんだが。

495 ：デフォルトの名無しさん：2010/05/25(火) 03:10:25

カリー化はいいが
複数のコードを静的に生成すると
サイズがでかくならんの？

496 ：デフォルトの名無しさん：2010/05/25(火) 03:42:57

>>485
初めからバックエンドまで自作は諦めるべきでしょ？
中間言語を適当なフレームワークにつなぐか、そもそもターゲットを汎用言語にする
Cへのトランスレータでも十分すぎると思う

497 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 06:11:20

>>493
Haskellでも無ければ、Scalaでもないんだよ。
HaskellやScalaつかえば良いじゃん。
>>494
その辺は趣味の違いなので議論に出来るように書いてよ。
趣味の違いを議論しても意味が無いし、不要だと思うのは
勝手だけどで外して失うメリットが多すぎるしね。

498 ：デフォルトの名無しさん：2010/05/25(火) 06:26:18

さすがにNGしたわ

499 ：デフォルトの名無しさん：2010/05/25(火) 07:10:32

>>489
最適化とかじゃなくてだな、
ライブラリが貧弱だと単純に作るのが面倒くさいんだよ

500 ：デフォルトの名無しさん：2010/05/25(火) 08:06:29

printfが便利すぎるからな

501 ：デフォルトの名無しさん：2010/05/25(火) 08:09:01

>>489
共有ライブラリ

502 ：デフォルトの名無しさん：2010/05/25(火) 08:11:27

>>495
ならない、あるいは、ならないように気をつけることが出来る。

503 ：デフォルトの名無しさん：2010/05/25(火) 09:12:14

基本的には大きくなるが
やり方次第でさほどでもないって感じじゃない

504 ：デフォルトの名無しさん：2010/05/25(火) 10:24:45

>>497
他の例を挙げたのはそれが使いたいから挙げたわけではないです。
一般的で短いほうが好まれるといってるのです。
あなたの目的にあったことは出来て短く書けるわけだから悪い話じゃないと思うよ。
ScalaやHaskellはC言語の変わりになれないし、
そこで簡単に他の使えばいいじゃんとかいわないほうがいいよ。
カリー化は部分適用の目的があるので、「取ってくる」の話している
modeの役割と変わらないし、一般的だし短く書ける。
部分適用したくなければカリー化しなければいい話だ。
y = cos(a) + sin(a)を
cos Param(a) Result(b);
sin Param(a) Result(c);
y= b + c;
って書けって言われてもなぁ。
Cとアセンブラの中間の高級アセンブラというなら話は別だけど。

505 ：デフォルトの名無しさん：2010/05/25(火) 10:40:37

機能を足したがる人が多いがむしろCから処理系依存と要らない物を排除するのが理想
暗黙変換や算術変換は廃止
符号付右シフトやビット演算や符号付整数のオーバーフローや浮動小数点演算はCPU依存なので標準から排除もしくは仕様で固定する
文字型もコード依存なので排除もしくは仕様で固定する
標準ライブラリの入出力等もOS依存なので排除

506 ：デフォルトの名無しさん：2010/05/25(火) 10:47:03

http://japan.renesas.com/prod/mcumpu/

おまえら一度↑見て頭冷やせ。RAM16KBに収まるコードが書けなきゃCの代替にはなれないぞ？
テンプレートとか言ってる誰かさんはOOPがお好きなようだがｗ

507 ：デフォルトの名無しさん：2010/05/25(火) 10:56:24

>>505
どうせ標準ライブラリは使い物にならないから自前でって現状はわかる。
だがよく使うものを排除するのは最後の手段だろう。
使える(環境の)人にとっては効率が落ちることになるから。
言語仕様で内部の動作までカッチリ固定できればベストと思うけど、
それが無理ならqsort()のようにラッパー型にしてもいい。
ライブラリはできるだけ揃える方向のほうが使う人も増えると思うよ。

508 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 11:01:25

標準ライブラリを定義しない失敗は犯せないと思う。
何を定義しとかなきゃ不味いかは、膨大なCのノウハウが
役に立つ。でもそれは言語仕様が固まってから。

509 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 11:06:53

>>506
テンプレートでコードが肥大化するのは
テンプレートが悪いと言うより、大きなテンプレートを
使ってもユーザーにそれと感じさせないからで、リストが
必要なら、テンプレート使っても、手組みしても必要な
記述量って物があるので、そうは変わらない。

まぁテンプレートは一般化して組んである分すこし不利だけど
オーバーヘッドはそんなもんだ。

なのでテンプレートという考え方は失いたくないけども
STL的なやり方は絶対に嫌。というまぁ気分段階だけど。
STLじゃなくてM4的な何かっていうのも、プリプロセッサー
止めたいとか言ってる中でどうだかなって思うし。
色々難しいよね。いっそのことIDEに頑張ってもらう事にして
コピペライブラリでも良いんじゃないかとか（ｗ

510 ：デフォルトの名無しさん：2010/05/25(火) 11:13:48

テンプレートを制御されたマクロとして使えばかなり使えると思うんだがなあ
関数型マクロでとっ散らかるのはいや

511 ：デフォルトの名無しさん：2010/05/25(火) 16:08:21

>>506
RAM16Kより小さい場合も普通にあるよな

512 ：デフォルトの名無しさん：2010/05/25(火) 16:20:29

>>504
彼のセンスはズバ抜けてるからな
普通は記号とか構文で簡潔にしたいもんだが
美的センスもプログラム経験も少なそうだし
COBOL風C++が作りたいんでしょ
カリーとか関数言語みたいな高度な話題はついてこないよw

513 ：デフォルトの名無しさん：2010/05/25(火) 16:25:10

win上でideしか使ったことないゆとりでしょ

514 ：デフォルトの名無しさん：2010/05/25(火) 18:01:50

　　＝＝＝＝＝＝＝＝＝＝＝　みんな偉そうなこと言ってるけど、ここまで何の成果物も無し　＝＝＝＝＝＝＝＝＝＝＝

515 ：デフォルトの名無しさん：2010/05/25(火) 18:07:02

ところで、カリー化って特別な構文が必要なの？
必要じゃなくても何かあった方がいい構文があるとか？

516 ：デフォルトの名無しさん：2010/05/25(火) 18:29:48

カリー化ってクロージャ同様GC要るだろ
高級過ぎると思うが

517 ：デフォルトの名無しさん：2010/05/25(火) 18:38:13

カリー化にGCが必要かどうかは、変数にGCが必要かどうかと、同じ話じゃないの？

518 ：デフォルトの名無しさん：2010/05/25(火) 18:46:50

ラップする関数を静的に生成するか
インラインで展開するならいいだろな
動的にやるとなるといろいろ問題でるが
ありゃ宣言的に話が進む関数型で生きるもんだが
Cでも汎用関数に半固定引数使う場合なんかは同じだな

519 ：デフォルトの名無しさん：2010/05/25(火) 18:47:21

>>497のレスがあからさまに話題について行けてないｗｗ

520 ：デフォルトの名無しさん：2010/05/25(火) 19:01:03

名前付きパラのが欲しいな
全部ソートして$でもはさんで名前につなげちまえば
Cからも呼べるしリンクも楽か

521 ：デフォルトの名無しさん：2010/05/25(火) 19:03:38

++のmanglingはCからはつらい

522 ：デフォルトの名無しさん：2010/05/25(火) 20:30:00

結局のところ本当に欲しいものを作ろうとすると10万時間あっても足らない
だから初めにすべきことは仕様をギリギリまで削ること

安定して動作するようになったら一年に新機能１個とかちょっとづつ追加していけばいい
あれもこれも付けろと作業時間増やすことに熱心な人は早めに追い出すのが吉
現実的な話をしない人(あえて名前は出さない)は絶対役にたたないから無視に限る

ライブラリはある程度までは開発側の言語仕様に詳しい人が作らないといけない
そこを省いて全てユーザーに任せるとGHCみたいに粗悪なラッパーが蔓延ることになる
どこぞの教授なら研究室のメンバーに面倒な仕事を押し付けることもできるけれど
ここで作るなら大量に人材を(できれば資金も)確保する作戦を立てないと

使えるライブラリがないからユーザーが増えない↓↓↓
↑↑↑ユーザーが増えないから使えるライブラリがない

という無限ループに陥って糞言語化する
そうなってしまった新言語の如何に多いことか

523 ：デフォルトの名無しさん：2010/05/25(火) 20:45:38

ライブラリ書いちゃうと
言語仕様変えれなくなるよ

絞り込むのには全面賛成だが
but not too muchの部分も忘れちゃいかん

524 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 21:10:42

>>523
同意。
なので、C/C++の代替を目指すと言うコンセプトからも、
Cライブラリを使える（最大限には使えない）という仕様を
維持したいと思うんだ。
新しい言語altanativeC(仮称）で組まれていない以上、
その有効性は発揮出来ないけども、Cライブラリは使えるよ。
書き直すとこんなに良いよ、そんな方向を目指したいと思う。

バイナリーリンクが無理でもソースリンクが可能が最低限
だと思う。altanativeC(仮称）でコンパイルすると実力は
発揮できないけども使えるっていう感じ？

525 ：デフォルトの名無しさん：2010/05/25(火) 21:14:00

後発なんだからライブラリはCとか他言語のを使えたらいいんじゃね

526 ：デフォルトの名無しさん：2010/05/25(火) 21:17:34

ソースリンクてなんだ？
Cとコーリングコンベンション合わせるか
合わせれたらいい

527 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 21:23:59

>>526
ごめん造語した（ｗ
出来ればコーリングコンベンションを合わせたい。

コンパイラでどうとでもなるって言っても多値戻しとかやり始めたら
言語記述との乖離が大きすぎて、ラッパー入れてるのと変わらなくなる
それはちょっと嫌、でも色々考えて言語仕様を設計していく内にどうしても
コーリングコンベンションが違ってくるのなら、再コンパイル、再リンク
でちゃんと動かしたい（C言語のコンパイラも内包しちゃう事になるけど）
という感じ？
old-CでもANSI－Cでもコンパイル出来たようなイメージ.
て感じで。

ソースリンクは、それにしても不適切な言葉だったごめん。

528 ：デフォルトの名無しさん：2010/05/25(火) 21:35:53

きになったんだが
取りに行くです。がコテなの？

529 ：デフォルトの名無しさん：2010/05/25(火) 21:39:05

頭からスレ読んでるけど「3年以内にユーザー5万人を目指す」とか、
明確な目標がないから話が発散してるんだよね。

目標が決まってようやく新言語にどんな長所を持たせるのか検討する段階に進める。
そこで例えば「速度面で」他の言語に勝つのを目指すと決まったなら、
「何の速度面で何言語を超えるのよ？」の話をまとめあげ、
「それで本当にユーザー5万人大丈夫？」みたいな話になり、
大丈夫となったらそこで初めて「言語仕様」の話がででくるんじゃないの。
その上で開発にかかわる人数からスケジュールを確定して
各仕様の優先度を議論してギリギリまで削るべき。

勿論、まともなライブラリがなかったらユーザー5万人にも届かないのは言うまでもないし
仮にCのライブラリを流用するとしても機械的にインターフェイスを変換するだけなら
Cから直接扱うより悪くなることはあっても扱いやすくなることはない。
テンプレートが絡むと流用自体が困難だし、まともなライブラリとはとても呼べないよ。
ないよりマシなだけ。

530 ：デフォルトの名無しさん：2010/05/25(火) 21:56:14

3年以内にC/C++5万行のコードを新言語で書き直す

531 ：デフォルトの名無しさん：2010/05/25(火) 22:07:29

5万行も読んだらC/C++の専門家になってしまうなー

532 ：取りに行くです。 ◆JZ1SFn6i7c ：2010/05/25(火) 22:07:53

>>528
＞120 KB [ ２ちゃんねる３億PV/日をささえるレンタルサーバー \877/2TB/100Mbps]
＞取りに行ったけどなかった。次は一時間後に取りに行くです。

の最後の部分をコピペしただけだからあまり気にしないで。

>>529
そういうのは仕事でやってよ（ｗ
ねばならないとは思わないけども、君が思うのは自由かもしれない。
だから駄目とか言われても、困るし、めんどくさいし、
もうさ、これだけ色々な言語があるんだし、Windowsもちゃんと普及してるんだし、
GoogleのGoとかJavaとかあるんだし、C#エトセトラ、エトセトラ。

この辺と戦うのは疲弊するだけだから、Cに変わる使いやすい言語が出来れば良いな
程度の軽さで行こうよ、普及させなきゃ、とか、貢献貢献とか、めんどくさいじゃん。
目玉三角にして、Cより便利ーとかやってもしんどいだけだと思うよ。

20年前ならそういう事も楽しかったんだけど、今はもうそんな時代じゃないから。

533 ：デフォルトの名無しさん：2010/05/25(火) 22:27:45

スケジュールとか目標とか優先度とか言ってるのは、
普段派遣先で「スケジュールはどうした」「目標はどうした」「優先度はどうした」とガリガリやられて縮こまってる日雇いノイローゼ君が、
顔の見えない匿名掲示板で調子にのって普段ヤラれてることをやり返してるだけだろ。

534 ：デフォルトの名無しさん：2010/05/25(火) 22:44:13

>>533
違う違うw
いつも新しい言語が出てくるとしばらく試してみるんだが
軒並み開発やコミュの「取りに行く」みたいな言語ヲタのせいで
糞言語化していくんだよね。
新機能いらねーからバグ直せよと思うことあるでしょ。
まあここがダメだということを再確認しただけだった。

535 ：デフォルトの名無しさん：2010/05/25(火) 23:04:21

カリー化が新しい言語に実際に必要かといえばなくてもいいです。
でも、部分適用するならカリー化的な構文にしたらいいと主張してました。
なぜなら仮に後で新しいC言語を参考にして作った言語で
カリー化を実装しようとしたときも、自然に拡張できるからです。
後々の拡張も考えて構文を決めたほうがいいと思うのですがいかがでしょうか？

536 ：デフォルトの名無しさん：2010/05/25(火) 23:06:19

>>533
派遣？のことはしらんが仕事してるならスケジュールと目標は基本だろ

OSSでもUbuntuが後発で信頼を勝ち得たのは
使いやすくするという目標と規則的なリリースを守り続けてるからだよ

537 ：デフォルトの名無しさん：2010/05/25(火) 23:06:42

>>535
現状のCがどうなるかって事で、ちょっと構文書いてみ。

538 ：デフォルトの名無しさん：2010/05/25(火) 23:19:23

>>531
5万行くらい最長不倒関数が10個もあれば十分達成できるぞ

539 ：デフォルトの名無しさん：2010/05/25(火) 23:25:00

>>535
原案を出してもらえると嬉しいな。

540 ：デフォルトの名無しさん：2010/05/25(火) 23:41:41

仮にstrcmpがカリー化されているとすると
compare_with_foo = strcmp("foo");
compare_with_foo("bar");
こんな感じだよな

・関数オブジェクトの扱いや型はどうするのか
・引数をバインドするときに、その寿命をどうするのか
（クロージャと同じfunarg問題）
といった点が気になる

541 ：デフォルトの名無しさん：2010/05/25(火) 23:49:20

>>538
最長不倒関数が5k行なわけないだろw

俺は昔若い頃ifとgotoとグローバル変数しかない10000行位のCのプログラムをみたことあるぜ
数日かけて全面書き直したがw

542 ：デフォルトの名無しさん：2010/05/25(火) 23:53:17

>>540
やはり静的、インラインを考慮しないと
Cレベルの言語にはカリーは無理だが
問題はそいつをローカル変数で作って
スコープ外に持ち出す場合だな

543 ：デフォルトの名無しさん：2010/05/25(火) 23:59:30

>>535
ぜんぜん確定してないのですけど、こんな感じで考えています。
void main() { printf("hello world\n"); }
struct A { char* name; int x; int y; }
int add(int a, int b) { return a + b }
int fib(int n) { if (a <= 2) return 1; else return fib(n-1)+fib(n-2); }
は
df main:()(void) = printf("hello world\n")
strct A {name:char*;x:int;y:int;}
df add:(a:int,b:int)(int) = a + b
df fib:(n:int)(int) = if (n <= 2) 1 else fib(n-1)*fib(n-2)
見た目はかなりScalaに似ていますが(a:int)(b:int)(int)と括弧を続けて書くのが
関数型言語の a:int->b:int->intのような感じのものに対応できたらいいんではと
考えています。ただ、だめなパターンがあるかもしれません。
だめなパターンがあった場合はScalaに似たようになるでしょう。
自分の希望は、この構文レベルでいろいろと試すことが出来るように
テストケースを用意しておき、よりよい構文を見つけることです。
抽象構文木の下はほかの人が最適化したりしてもらえればと考えています。
このようにして多少長くなりますが、演算子順位法でパーサが書ける様になり、
通常の構文解析も楽に出来るようにできたらと考えています。

544 ：デフォルトの名無しさん：2010/05/26(水) 00:08:32

>>540　>>542
カリー化が目的になってる。
それをすることによって何のメリットがあるんだ？
って話を聞きたいんだよ。

むしろコンパイル時にカリー化して最適化ってのは
ありえそうだと思うのだが。
構文の不備によるカリー化不可能な定義を避けるために
構文を束縛するってのは判るのだけど、
カリー化不可能な関数っていうのが思いつかない。
存在しちゃ駄目だろそれは。
逆になさそうな気がするんだけど。

545 ：デフォルトの名無しさん：2010/05/26(水) 00:12:09

>>543
いや、だから、それは関数型言語が欲しいだろ？
それをアセンブラにしたらどうなるんだ？
書いてみてよ。

546 ：デフォルトの名無しさん：2010/05/26(水) 00:17:13

>>543
ありがとう。
とりあえず、ネガティブな反応はあとでまとめて読むことにして、これをベースに練っていこうか。

547 ：デフォルトの名無しさん：2010/05/26(水) 00:17:42

>>545
続き。>>540　>>542　>>543
Cでの構文ではこんなアセンブラになるけども、
カリー化（ってなんか物凄い違和感ある）することによって
こんなにも素晴らしいアセンブラになるとか、有るんだろ。
だからスレを潰しまくってるんだろ、それは何よ。

548 ：デフォルトの名無しさん：2010/05/26(水) 00:22:01

スマートポインタのようなものが必要になるんじゃないか。

549 ：デフォルトの名無しさん：2010/05/26(水) 00:22:15

カリー化で速度優先の最適化ってできる？

550 ：デフォルトの名無しさん：2010/05/26(水) 00:26:35

>>545
>>543で書いた例は今のC言語と同じアセンブラで十分です。
>>544
カリー化が目的じゃなくて、カリー化されてもきれいに書けるように考えてるのです。
C言語ではカリー化しないと思うのでしなくていいですけど。
発展性がある文法にしておこうよって考えてるのです。
Scalaではdefのところをdfと書き換えているのはGC拡張を考えてのことです。
>>546
ぜひよろしくお願いします。

551 ：デフォルトの名無しさん：2010/05/26(水) 00:29:44

低レベルな言語の話なんだから関数型過ぎるのは実際無理だろ
遅延評価とかも無理だし。
だからコンパイルタイムに処理できる範囲で
静的に定義できるような感じかインラインで展開しかねえんじゃね

552 ：デフォルトの名無しさん：2010/05/26(水) 00:32:51

scalaは悪くないけど速度的にはC>java>scalaってなるでしょ
個人的には関数型言語はいくつか種を残して
いずれまたブームが去ると思ってるが。

553 ：デフォルトの名無しさん：2010/05/26(水) 00:39:52

でも妄想より全然まとも

554 ：デフォルトの名無しさん：2010/05/26(水) 00:40:16

カリー化でコンパイル時に処理できるものと、それ以外を分けたらどうなるかな？

それが分かっていれば、ホットスポットでは前者のみを使おうとかそういう指針が出来るよね。

555 ：デフォルトの名無しさん：2010/05/26(水) 00:42:10

>>550
綺麗な単語並べてるけど、意味の構築に失敗してるね。
気分は伝わったよ。

>>549
数学者の仕事って言う雰囲気。

556 ：デフォルトの名無しさん：2010/05/26(水) 00:42:43

処理系側でエラー出さないとだね
厳密にスコープに閉じ込めないと。

557 ：デフォルトの名無しさん：2010/05/26(水) 00:45:53

>>554
＞カリー化でコンパイル時に処理できるものと、それ以外を分けたらどうなるかな？
コンパイル時にカリー化で・・・・

の間違いではなくて？

558 ：デフォルトの名無しさん：2010/05/26(水) 00:49:50

ぉお、>>577書いた後に気がついたんだけど
人工無能なのか、すごいなぁ。最近の人工無能は。

559 ：デフォルトの名無しさん：2010/05/26(水) 00:50:47

577に期待だな

560 ：デフォルトの名無しさん：2010/05/26(水) 00:51:09

>>577
マジかよ

561 ：デフォルトの名無しさん：2010/05/26(水) 00:54:05

カリー化の処理を、コンパイル時に処理できる場合と、それ以外の場合に分けられるかな？

それが分かっていれば、ホットスポットでは前者のみを使おうとかそういう指針が出来るよね。

（こんな感じかな。>>554）

562 ：デフォルトの名無しさん：2010/05/26(水) 00:55:59

でも結局引数持たせたラッパー関数と変わらなくなる気がするな

563 ：デフォルトの名無しさん：2010/05/26(水) 00:56:07

カリー化やその構文なんて小手先の問題より先に考えることあるだろ
関数をファーストクラスオブジェクトにするのかとか
レキシカルスコープなのかとか
どう考えてもカリー化よりlambdaのほうが本質的だ

まあGCじゃねーから小手先に走るしかないのかもしれないが
関数がファーストクラスオブジェクトじゃない世界でカリー化とか
吹いたところで出来ることも便利さは高が知れてるぞ

Cの生関数をベースにするなら、データをバインドした関数の型は
生の関数とは別のものにならざるを得ない
従ってC++ではテンプレートのダックタイピングでゴマカしてるんだろ
一体どうしたいんだ

564 ：デフォルトの名無しさん：2010/05/26(水) 00:57:50

先に考えたいことがある人はどんどん先に考えていいよ。

それぞれが考えたいところをどんどん考えればいい。

565 ：デフォルトの名無しさん：2010/05/26(水) 01:04:18

ＧＣ必須言語はさすがに対象外だと思うんだが。

566 ：デフォルトの名無しさん：2010/05/26(水) 01:04:40

本質的も何もlambdaは普通にいいんじゃね
クロージャとかいわなければ静的に処理できるし。
ダックタイピングもアドホックなプログラミングにはいいんだがなー
コンパイルタイムで処理できる範囲ならいいんじゃない

567 ：デフォルトの名無しさん：2010/05/26(水) 01:05:47

>>563
上の議論を見るにGCは無し、あるいはオプショナルという流れだから
ファーストクラスな関数があってもレキシカルスコープが完全サポートできずに威力半減
ちょっとそれは困ると思うｗ

Cの代替って言うからには、低水準を詰めたいんだよなあ
確かに、モダンなものも取り込みたいなあという願望もあるが
うまく風呂敷を畳むのが難しい

568 ：デフォルトの名無しさん：2010/05/26(水) 01:10:25

(go+C)/2あるいは(python+C)/2みたいな感じが現実的かね

569 ：デフォルトの名無しさん：2010/05/26(水) 01:12:47

>>567
だよな
俺もGC無いつってんだからその辺は最初から眼中に無いものと思ってるよ
当然レキシカルスコープなし、クロージャ無し、当たり前だ

なのになんでカリー化なんて話してるのか分からんよ

570 ：デフォルトの名無しさん：2010/05/26(水) 01:17:09

じゃあ、GCありで。
モダンな機能が使えないとつまらないからね。

当然、低レベルでも使えるように、パフォーマンスに影響を与える機能を洗い出して
「Effective 新言語」の中「カツカツに最適化したい部分では、これらの機能は使わないようにしよう」って啓蒙しよう。
（あるいはコンパイラがワーニングを出す）

571 ：デフォルトの名無しさん：2010/05/26(水) 01:22:55

関数型言語っぽいことがやりたきゃ素直に関数型言語使えばいいだろう
何でこのスレでやるの？

上から下までカバーできる僕の考えた最強の言語なんて、もし出来ても
C++より複雑で使いにくい最悪の言語になるのがオチだ

572 ：デフォルトの名無しさん：2010/05/26(水) 01:23:40

>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。

573 ：デフォルトの名無しさん：2010/05/26(水) 01:26:54

それ以前に、GC要るとか言い出す時点でスレタイから外れてる

574 ：デフォルトの名無しさん：2010/05/26(水) 01:27:08

>567
レキシカルスコープなくても明示的な束縛がありゃ十分だろ。
面倒臭くはあるけど。

575 ：デフォルトの名無しさん：2010/05/26(水) 01:30:52

ちょっと待ってくれ。
レキシカルスコープって構文で制約されるスコープルールだろ？
普通にC系はみなファイル・ブロックなんかで制約されるレキシカルスコープじゃねえのか
俺が話はずしてんのか？

576 ：デフォルトの名無しさん：2010/05/26(水) 01:32:55

>575
基本的にCはグローバルスコープとローカルスコープしかない。
レキシカルかもしれないけれど、あんまり意味はない。

577 ：デフォルトの名無しさん：2010/05/26(水) 01:33:13

>>574
束縛を明示させるとしても、型の問題と寿命管理の問題は残る

寿命はdownwordなスコープに限定するとしても、
>>540のようなことをしたいのは、結局は
int (*)(const char*)を引数に取る関数に渡すときにアダプタとして使うような
場合だが
（関数型言語のように）free variableをbindした関数と普通の関数を同一視できるか、
同一視できないので、ダックタイピングで逃げるかという形になる

578 ：デフォルトの名無しさん：2010/05/26(水) 01:40:41

スレタイみてＧＣありっていうやつの気が知れない

579 ：デフォルトの名無しさん：2010/05/26(水) 01:41:15

>>576
いや、話からいってレキシカルじゃなく
ダイナミックなスコープのこといってんじゃねえのかとおもってさ

580 ：デフォルトの名無しさん：2010/05/26(水) 01:53:52

>>579
関数内関数があるかどうかぐらいの話と考えればいいと思う

581 ：デフォルトの名無しさん：2010/05/26(水) 02:04:12

いやさ。Cとかは普通にレキシカルルールだよ
gcc拡張に欲しそうな機能かなりあんじゃね
関数内関数も静的なやつならいけるし
ブロックは値持つし

582 ：デフォルトの名無しさん：2010/05/26(水) 02:09:56

> 関数内関数も静的なやつならいけるし
静的な奴ってのが自由変数を参照していない関数、ということなら
名前をファイルスコープに拡張せずに済むという程度の意味しかないんじゃね

583 ：デフォルトの名無しさん：2010/05/26(水) 02:17:48

と思ったら、それは出来るのか
ttp://d.hatena.ne.jp/eagletmt/20100306/1267805001
すげえなGCC拡張

584 ：デフォルトの名無しさん：2010/05/26(水) 03:22:21

それはレキシカルルールだからな
今のレベルより上は保護されてない限り参照できる
まあ古くはPascalでさえ出来たからな
Cでは意図的に関数内関数は外したっぽいが。

585 ：デフォルトの名無しさん：2010/05/26(水) 03:54:41

gccの拡張機能は形を変えて
かなりの部分がC99にはいったよな
attributeのpackやalignやsectionとinline asmがないと
組み込みではつらい

586 ：デフォルトの名無しさん：2010/05/26(水) 09:23:59

Pascalと違ってCは関数ポインタが必要だし、GCC拡張ではそのために結構面白いことをしてる。

587 ：デフォルトの名無しさん：2010/05/26(水) 11:23:59

スコープとか気にしてる人はOOPにするつもりなの？

588 ：デフォルトの名無しさん：2010/05/26(水) 14:57:05

>>586
同じだよ。結構普通に出来るっしよ
上のレベルのフレームを参照してるのを
外に持ちだしたら危ないし

589 ：デフォルトの名無しさん：2010/05/26(水) 22:23:12

C++を使ったカリー化の実装イメージ
ttp://codepad.org/rsyqsN8a

関数ポインタの概念を拡張すれば
普通の関数ポインタやインスタンス＋メンバ関数ポインタもカリー化された関数も同じように扱えるが、
普通の関数ポインタとして使いたい場合にオーバーヘッドが必要な事は言うまでもない
Dみたいにfunctionとdelegateで分けるというのもアリ

590 ：デフォルトの名無しさん：2010/05/27(木) 02:14:42

これは分かりやすくていいな

591 ：デフォルトの名無しさん：2010/05/27(木) 04:28:00

>>571
「取ってくるです」の部分適用したいとコンパイラに伝える
構文が欲しいという話に応えてカリー化のような構文にすればいいのでは？
と提案しただけです。
C言語は多くの言語に影響を及ぼした偉大な言語です。
偉大な言語ではありますが、現在のように拡張されることを見越した
設計ではなかったと思います。
C言語の置き換えを目指すなら構文が拡張される言語を目指すべきです。
オブジェクト指向な言語に拡張したり、関数型言語への拡張も視野に
入れて構文を考えたものと、そうでないものなら拡張を考えた構文
のほうがいい構文だろうと主張しているのです。

592 ：デフォルトの名無しさん：2010/05/27(木) 04:36:53

ここで議論したいのは関数の型の記述方法です。
カリー化された関数とは関数を返す関数です。
C言語で考えれば関数ポインタを返す関数です。
引数には名前も付けたい。
型推論で型を省略できるところは省略できるようにしたい。
自分の型を返す関数の記述もしたい。
a()()()()()();
と呼び出せる関数の型を綺麗に書きたい。
構文解析は楽したい。
環境を持った関数と環境を持っていない関数は分けて考えたい。
クロージャとメソッドは別に考えたい、あるいは一緒に考えたい。
等あると思うのですが、関数ポインタの記述方法はどのようにしたらいいと思いますか？

593 ：デフォルトの名無しさん：2010/05/27(木) 07:19:49

C#みたいに型宣言前提にすれば

594 ：デフォルトの名無しさん：2010/05/27(木) 10:19:17

クロージャは要らんが、
カリーは>>589のように合成を遅延する形で作れるなら
コンパイラの最適化のヒントにもなりえて有効かも知れない。
元々可能だった関数(ポインタ)を返す関数とも競合しない。

名前付き引数は f(int a, int b, int c)ならば
f(b: 2, a: 1, c: 3);あるいはf(b: 2)(a: 1)(c: 3);
f(b= 2, a=1, c=3);だと代入と間違うため

595 ：デフォルトの名無しさん：2010/05/27(木) 12:15:29

カリーをサポートしたとして、どんなメリットがあるの？

596 ：デフォルトの名無しさん：2010/05/27(木) 12:49:10

インライン関数やC++系言語の関数オーバーライドによる
デフォルト引数の隠蔽とIDEのインテリセンスで十分で
わざわざ難解にする必要も無い。

597 ：デフォルトの名無しさん：2010/05/27(木) 16:39:41

メリットばかり強調してデメリットからは目をそむける輩がいますね

598 ：デフォルトの名無しさん：2010/05/27(木) 17:41:11

数万行→Cで今迄書いてきた行数
数千行→C++で今迄書いてきた行数
数千行強→Javaで今迄書いてきた行数

こんな「ワタシ」にも議論に参加する資格があるでしょうか？

599 ：デフォルトの名無しさん：2010/05/27(木) 18:14:41

参加する意志があれば、誰でも参加していいよ。

600 ：デフォルトの名無しさん：2010/05/27(木) 19:43:17

静的型言語だけど、基本的に型は推測させて、型は書かない文法はどうよ？
関数型言語であるでしょ

601 ：デフォルトの名無しさん：2010/05/27(木) 19:47:24

C++0xにもあるし、型推論は採用するよ。

602 ：デフォルトの名無しさん：2010/05/27(木) 19:49:37

>>600
バグ潰しの為に型異常を報告させるので、
型推測の規則を厳しく持っていかないと
駄目だけど、そのルールっての曲者で
単純で明瞭ぽい暗黙の型変換であれだけの
混乱と戸惑いが発生して、もうね全部かけ、
キャストしろって話になったのがCの歴史。
一方LWLは、全部載せ型を基本として何されても
一応行けるぞってのが売りだけど、そのために
物凄いオーバーヘッドが発生してる。

LWLはそういう物だからそれで良いんだけどさ。

603 ：デフォルトの名無しさん：2010/05/27(木) 19:52:49

>キャストしろって話になったのがCの歴史。

そんな歴史ねーよ。どこのヤクザ企業だよ。

604 ：デフォルトの名無しさん：2010/05/27(木) 20:07:05

アセンブラ代わりに使えるC++マジ最高

605 ：デフォルトの名無しさん：2010/05/28(金) 00:13:56

ご冗談でしょ
C++はカス

606 ：デフォルトの名無しさん：2010/05/28(金) 17:33:28

ちょっとお前らこのスレの頭おかしい奴になんとか言ってやってくれよｗ

フリーソフト作者の愚痴 38
http://pc11.2ch.net/test/read.cgi/prog/1274799337/

607 ：デフォルトの名無しさん：2010/05/28(金) 18:19:54

ご冗談でしょう、ストラウストラップさん

608 ：デフォルトの名無しさん：2010/05/28(金) 19:01:40

>>606
自己中マの巣窟

609 ：デフォルトの名無しさん：2010/05/28(金) 21:43:16

>>606
基地外の相手なんかすんなよ

610 ：デフォルトの名無しさん：2010/05/28(金) 21:59:48

クロージャー
カリー化
型推定
Lisp的なマクロ
ファーストクラス関数、正規表現、文字列、スレッド、XML、イベント

611 ：デフォルトの名無しさん：2010/05/28(金) 22:11:24

GUIとWEB忘れてんぞ

612 ：デフォルトの名無しさん：2010/05/28(金) 22:42:31

GUIとかWEB?はライブラリで提供すれば良い
正規表現や文字列やスレッドやXMLだって

613 ：デフォルトの名無しさん：2010/05/28(金) 23:14:22

Lisp的なマクロとか方言が乱立するだろ

614 ：デフォルトの名無しさん：2010/05/28(金) 23:15:38

言語機能の一部の実装がライブラリで提供されても全然構わない。

615 ：デフォルトの名無しさん：2010/05/28(金) 23:16:13

Lisp的なマクロだったら既にCで実装されているが、
Lispでマクロが強力なのはあの単純な構文だからだよ。

616 ：デフォルトの名無しさん：2010/05/28(金) 23:19:43

じゃあ、新言語の構文も単純にしよう。

617 ：デフォルトの名無しさん：2010/05/28(金) 23:20:20

ポールグレアム「PythonやRubyなど最近の言語はLisp化している」
http://practical-scheme.net/trans/icad-j.html

それに対する批判「PythonはLispと違って最高、Lispは糞」
http://practical-scheme.net/trans/IsPythonLisp-j.html

618 ：デフォルトの名無しさん：2010/05/28(金) 23:20:23

ここって提案するだけで誰も開発はしてないの？

619 ：デフォルトの名無しさん：2010/05/28(金) 23:22:08

色んな言語が関数言語に近づいてるのは俺も感じているな
ラムダ式とか既にあって当たり前みたいな感じ

620 ：デフォルトの名無しさん：2010/05/28(金) 23:22:57

>>615
Cのプリプロセッサマクロはトークンを置換するもの
Lispの構文木を操作するマクロとは別物でしょ

621 ：デフォルトの名無しさん：2010/05/28(金) 23:25:29

>>617の中にあるコード比較で、確かにRubyはLispみたいなコードでかなり短く（エレガントに？）書けるね
でもそんなコードって傍から見たら何をやってるのか分かり辛いと思うんだよ

622 ：デフォルトの名無しさん：2010/05/28(金) 23:26:42

Rubyは分かりやすいよ。

623 ：デフォルトの名無しさん：2010/05/28(金) 23:30:05

rubyはどうにでも書ける。コーディングによる

624 ：621：2010/05/28(金) 23:34:42

ああ、ごめん。俺はポールグレアムの文章を書籍のハッカーと画家で読んだが、それではrubyが追加されてるんだ
>>617には無いようだな。前に言ったように、rubyはlispとほぼ同じコード

625 ：デフォルトの名無しさん：2010/05/28(金) 23:45:59

>>620
本質的に同じものだよ。

626 ：デフォルトの名無しさん：2010/05/28(金) 23:46:51

>>620
本質的に同じものなんだけど、Lispはそのまんまリストだから、ああいう挙動ができるだけ。

627 ：デフォルトの名無しさん：2010/05/28(金) 23:47:33

Cのマクロは糞微妙だからな

628 ：デフォルトの名無しさん：2010/05/29(土) 02:25:06

マクロにも言語そのものの記述力が欲しい

629 ：デフォルトの名無しさん：2010/05/29(土) 02:43:54

Lispはリスト、Cは演算子で結合された構文木が本質である。

630 ：デフォルトの名無しさん：2010/05/29(土) 02:49:14

では、新言語の本質は何とすべきか。

631 ：デフォルトの名無しさん：2010/05/29(土) 03:00:36

本質とはなんぞや？

632 ：デフォルトの名無しさん：2010/05/29(土) 03:27:04

K&Rの前書きにある
Programmers know what they are doing.
という言葉が好きだ。

重くなるくらいなら安全に関する機能は不要だなあ

633 ：デフォルトの名無しさん：2010/05/29(土) 03:46:34

重くならないなら安全に関する機能は欲しいし、
重くなっても問題がないなら安全に関する機能は欲しい

重くなるか、重くならないか、重くなっても問題がないか、プログラマーは知っている。

634 ：デフォルトの名無しさん：2010/05/29(土) 03:50:24

型安全のためにプログラマが不自由になるのはどうよ

635 ：デフォルトの名無しさん：2010/05/29(土) 03:58:25

ガチガチにもゆるゆるにも書けるといいね。デフォルトはガチガチかな。

ガチガチ {
　int x;
　x = 1;
}

ゆるゆる {
　y = 1;
}

{
　/* デフォルトでガチガチ */
　int z;
　z = 1;
}

636 ：デフォルトの名無しさん：2010/05/29(土) 04:02:29

妥当です

637 ：デフォルトの名無しさん：2010/05/29(土) 04:34:24

>>629
演算子以外も構文木の一部だろ
全てがリストしかないlispとは
構文に対する考えが根本的に違う
構文いじるマクロなんて害悪でしかない

638 ：デフォルトの名無しさん：2010/05/29(土) 08:53:16

>>637
害悪という根拠は？

639 ：デフォルトの名無しさん：2010/05/29(土) 08:56:41

D&Eに通り一編の、Cプリプロセッサのマクロの問題点は書いてある

640 ：デフォルトの名無しさん：2010/05/29(土) 09:05:14

C++作った人が問題点を書いたから害悪なのか

641 ：デフォルトの名無しさん：2010/05/29(土) 09:10:15

>>638
マクロはよっぽど慎重に書かない限り副作用が激しいからな。

642 ：デフォルトの名無しさん：2010/05/29(土) 09:16:40

>>641
それは確かにそうだ。マクロは慎重に使うべきだ。
ただ、マクロは時として強力な武器となるのも事実だ。
たとえば、ActionScriptにはマクロがない。
インライン展開をコンパイラに期待しても展開してくれない。
そんな場合にCPPの関数マクロは役に立つ。

643 ：デフォルトの名無しさん：2010/05/29(土) 09:20:36

>>640 すでにある説明を繰り返すのは無駄だ、という意識のない奴はプログラマやめちまえ

644 ：デフォルトの名無しさん：2010/05/29(土) 09:24:39

>>643
議論をするのに本を買えというのがプログラマの仕事なのか？

645 ：デフォルトの名無しさん：2010/05/29(土) 09:24:40

>>638
緑化作業をします

インライン　植樹
マクロ　ペンキ

646 ：デフォルトの名無しさん：2010/05/29(土) 09:28:56

マクロは強力だがパズルになる。
パズルを利用して有用なことは、パズルにならない構文を用意すればいい。

647 ：デフォルトの名無しさん：2010/05/29(土) 09:30:01

C++の作者がマクロを批判するならコンパイラがプリプロセッサ
を動かさないようにすべきだったろう。
マクロを使う必要性があるのを認めざるを得なかったから残っているのではないかい？

648 ：デフォルトの名無しさん：2010/05/29(土) 09:37:54

マクロは文法を超越した規則性のある記述に使うのが便利だね。それでもテンプレートとかで記述できないかを一考してから使うべきだろう。
ライブラリ内のクラスや関数の生成でマクロを使っても、ライブラリユーザーには直接にマクロを使わせるべきではないだろう。

ただのタイプ数削減に使うのは避けるべきだろう。

649 ：デフォルトの名無しさん：2010/05/29(土) 09:41:06

１０００時間を１００時間に減らせるなら、マクロを使うべきだ。

650 ：デフォルトの名無しさん：2010/05/29(土) 09:41:49

>>644
なんて本の何ページの何行についてなんてポインタ指定しても本がなければアクセス違反でクラッシュってことか

651 ：デフォルトの名無しさん：2010/05/29(土) 09:43:04

>>649
どんなマクロかkwsk

652 ：デフォルトの名無しさん：2010/05/29(土) 11:27:01

Lispに構文も何もないからな

653 ：デフォルトの名無しさん：2010/05/29(土) 14:22:19

>>649
例えばアセンブラに対してC言語をマクロと考えれば10倍くらいになる。
http://www.vpri.org/html/work/ifnct.htm
SmalltalkをDSLを使って23万行を2万行にするのを目標にしているプロジェクトがある。
倍率が重要なのではない。費用対効果が高ければ使うべきだ。
マクロを使ってDSLを構築し、抽象化することでわかりやすく
行数を削減できるならマクロはいい道具だ。

654 ：デフォルトの名無しさん：2010/05/29(土) 14:25:55

>>652
Lispにも構文はある。たとえばSchemeの仕様書、R5RSの7章
http://www.unixuser.org/~euske/doc/r5rs-ja/r5rs-ja.pdf

655 ：デフォルトの名無しさん：2010/05/29(土) 14:59:34

>>646
LISPのマクロが強力とかいってる奴はポール・グレアムに洗脳されすぎ

656 ：デフォルトの名無しさん：2010/05/29(土) 15:01:24

>>653
えーと、「Smalltalk（でDSL）を使って」ではなくて、
「今、Smalltalkなら23万行で実現できていること（言語処理系込みのGUIベースのOSもどきの環境）を、
パーサージェネレーター（ここでいうマクロ）と連携させたSchemeライクな新言語で2万行で書く」ですね。

http://d.hatena.ne.jp/propella/20091219/p1

657 ：デフォルトの名無しさん：2010/05/29(土) 15:07:12

>>654
あるけど大した事ないという意味

658 ：デフォルトの名無しさん：2010/05/29(土) 15:20:30

一般に、Lispのマクロは強力だと思うよ。それは他のプログラマも認めるところなんじゃね
pythonクックブックにもそんな感じの言葉があった。Lispで作れないものがあるのか疑問とした上で、
ただしあの括弧だらけのコードに我慢出来ればの話だが。と絞められてたと思うけど
まあpythonクックブックはpythonマンセー本だから、pythonではLispに準ずるほど何でも出来て、
しかもコードが綺麗という趣旨の文章だったんだろう。例えばCのマクロなんかよりはよっぽど強力なのは明らか

659 ：デフォルトの名無しさん：2010/05/29(土) 15:26:25

このスレではCのマクロとLispのマクロが同じとか言ってる人もいるけどね
抽象度の高いクールなことを言おうとしてるんだろうけど

660 ：デフォルトの名無しさん：2010/05/29(土) 15:27:19

つまりLISPのコードの2万行は
Smalltalkのコードの20万行に相当すると

661 ：デフォルトの名無しさん：2010/05/29(土) 15:30:36

>>658
CのマクロでもLISPと同じことはできるけど、単に構文が複雑だからマクロの扱いも難しいというだけのこと。
LISPが強力だといわれるのは構文が単純だから。

662 ：デフォルトの名無しさん：2010/05/29(土) 15:31:28

じゃあ、Lispのマクロは強力なんでしょ？

663 ：デフォルトの名無しさん：2010/05/29(土) 15:32:07

タイプ量を減らすことがプログラマのためとは思わない。
全く同じことを何度も書かせるのは冗長だと思うが、それはエディタでどうとでもなる。
何をやっているのが把握しやすいことが最も重要。
その点でLispは最悪の部類に入る。

664 ：デフォルトの名無しさん：2010/05/29(土) 15:33:10

だからLispが使われてないんだろｗ
そんなのは最初から分かってる。グレアムでさえも

665 ：デフォルトの名無しさん：2010/05/29(土) 15:39:04

> CのマクロでもLISPと同じことはできる
> CのマクロでもLISPと同じことはできる
> CのマクロでもLISPと同じことはできる

みんなが話してるCとは別のCって名前の言語があるの？

666 ：デフォルトの名無しさん：2010/05/29(土) 15:40:37

>>662
機能としての強力さではなくて、
人間理解の点でCより秀でていると言える。
単に相対的な意味でわかりやすいというだけで、
実際に使ってみるとデバッグはものすごくやりにくいし、
とても便利な機能とは言えないと思う。
見た目上はキレイに纏まったように感じるかもしれないけど、
保守の観点からは最悪

667 ：デフォルトの名無しさん：2010/05/29(土) 15:41:15

構文ってのは人間のために作られるべきだ。
Lispの構文は、いわば片言の名詞を繋げただけの原始的なもの。
故に、Lispで作られた文の意図を把握するのは(人間にとって)煩わしい。
その反面、規則が単純であるが故に機械には理解しやすい。

668 ：デフォルトの名無しさん：2010/05/29(土) 15:41:30

機能としての強力さではなくて？何の話をしてんの

669 ：デフォルトの名無しさん：2010/05/29(土) 15:42:17

Lispが理解しやすいかどうかの話じゃないよ

670 ：デフォルトの名無しさん：2010/05/29(土) 15:43:05

>>667
人間にとって、簡単な機械のほうが、複雑な機械より理解しやすい。
Lispを解釈する機械は、Cを解釈する機械より簡単である。
ゆえに、Lispを解釈する機械は、Cを解釈する機械より理解しやすい。

671 ：デフォルトの名無しさん：2010/05/29(土) 15:54:44

コンパイラの理解のしやすさなんて
コンパイラ製作者以外どうでもいい話
しかしコンパイラ製作者がいないとコンパイラも増えないし普及もしない
ということでコンパイラの作りやすさを主眼に置いたD言語であったのだが

672 ：デフォルトの名無しさん：2010/05/29(土) 16:02:53

強力だけど理解しにくいマクロを望んでいるのか？

673 ：デフォルトの名無しさん：2010/05/29(土) 16:08:30

俺は>>655に反論したかっただけで、Lispのマクロを望んでるわけじゃないよ

674 ：デフォルトの名無しさん：2010/05/29(土) 16:12:07

D厨はちょっと黙ってろｗ
Dを流行らせたいなら逆効果だぞ

675 ：デフォルトの名無しさん：2010/05/29(土) 16:42:32

文盲乙と言えばいいのか

676 ：デフォルトの名無しさん：2010/05/29(土) 16:51:11

(define-macro (enum-let l . body)
(let loop ((x l) (num 0) (r '()))
(cond
((null? x) `(let ,(reverse r) ,@body))
((pair? (car x))
(loop (cdr x) (+ 1 (cadar x)) (cons `(,(caar x) ,(cadar x)) r))))
(else ; sym
(loop (cdr x) (+ 1 num) (cons `(,(car x) ,num) r))))))

(macroexpand1 '(enum-let (a (b 2) c) (+ a b c)))
=>(let ((a 0) (b 2) (c 3)) (+ a b c))

(macroexpand1 '(let ((a 0) (b 2) (c 3)) (+ a b c)))
=>((lambda (a b c) (+ a b c)) 0 2 3)

>(macroexpand1 '(let* ((a 0) (b 2) (c 3)) (+ a b c)))
=>(let ((a 0)) (let* ((b 2) (c 3)) (+ a b c)))

(macroexpand '(let* ((a 0) (b 2) (c 3)) (+ a b c)))
=>((lambda (a) ((lambda (b) ((lambda (c) (+ a b c)) 3)) 2)) 0)

おわかり頂けただろうか

677 ：デフォルトの名無しさん：2010/05/29(土) 17:11:09

>>653
＞例えばアセンブラに対してC言語をマクロと考えれば10倍くらいになる。
何だ、マクロの話じゃないのか。

678 ：デフォルトの名無しさん：2010/05/29(土) 17:19:19

自動プログラミング（笑）

679 ：デフォルトの名無しさん：2010/05/29(土) 19:27:59

「マクロ」に必要な要件って何なんだろう。

・構文を置き換えるルールを定義できる
・シンボルを置き換えるルールを定義できる
とか？

680 ：デフォルトの名無しさん：2010/05/29(土) 20:08:37

関数型が可読性高いと思ってるやつはさすがにいないよね？

681 ：デフォルトの名無しさん：2010/05/29(土) 20:10:08

関数型が可読性高いと思ってないやつはさすがにいないよね？

682 ：デフォルトの名無しさん：2010/05/29(土) 20:13:02

関数型が可読性高いと思ってないやつはさすがにいるよね？

683 ：デフォルトの名無しさん：2010/05/29(土) 20:18:00

関数型が可読性高いと思ってるやつはさすがにいるよね？

684 ：デフォルトの名無しさん：2010/05/29(土) 20:27:07

要は慣れだと思うが。

685 ：デフォルトの名無しさん：2010/05/29(土) 20:43:51

誰が可読性高いとか言ったんだ？私怨で暴れるのはやめろよ

686 ：デフォルトの名無しさん：2010/05/29(土) 20:45:37

関数型が歴史あるにもかかわらずメジャーになれないのはなぜだと思う？

687 ：デフォルトの名無しさん：2010/05/29(土) 20:47:39

>>686
逐次型の方がさらに歴史があるからだよ

688 ：デフォルトの名無しさん：2010/05/29(土) 20:48:09

構造化プログラムの可読性の高さは異常

689 ：デフォルトの名無しさん：2010/05/29(土) 20:49:33

純粋関数型で遅延評価なんて言語は80年代以降だしな

690 ：デフォルトの名無しさん：2010/05/29(土) 20:51:34

これだけ時間あっても普及しないもんな。

691 ：デフォルトの名無しさん：2010/05/29(土) 20:53:54

プログラムで実現したいことの多くは「計算」よりも「コンピューターの制御」なんだろう。
コンピューターの制御であれば、手続き型の方が直接的にかけるし、やることをそのまま記述するできて可読性も高い。

692 ：デフォルトの名無しさん：2010/05/29(土) 20:54:24

>>679
Lisp級の構文木を操作可能なマクロを作る要件

・マッチングプログラムが簡単に書ける
・マクロの実行時に構文木を返すプログラムを書ける

また、作るのを容易にするには
・単純な式として構文解析が可能

693 ：デフォルトの名無しさん：2010/05/29(土) 20:55:33

それってアイディアあっても作られなかったってことでは？

694 ：デフォルトの名無しさん：2010/05/29(土) 20:55:50

手続き型言語は手続きを書く言語
関数型言語は仕様を書く言語

695 ：デフォルトの名無しさん：2010/05/29(土) 20:55:56

FORTRANよりLISPが先輩なんだぜ。ｷﾘｯ

696 ：デフォルトの名無しさん：2010/05/29(土) 20:56:01

>>691 その理屈では機械語が一番可読性が高い。

まぁ実際そういうこともあるけど。

697 ：デフォルトの名無しさん：2010/05/29(土) 20:56:51

>>695 それはないw

698 ：デフォルトの名無しさん：2010/05/29(土) 21:01:22

なぜ副作用を導入するのか

699 ：デフォルトの名無しさん：2010/05/29(土) 21:04:36

mathematicaみたいにインテリジェントな評価をしてくれる言語はないものか

700 ：デフォルトの名無しさん：2010/05/29(土) 21:05:12

関数型が広まらない理由
・逐次実行するプログラムを書きにくいこと
・オブジェクト指向との親和性が低いこと
・文法がメジャーなC言語系統の言語からかけ離れていること
・関数呼び出しをネストするとlispのような見た目になってしまうこと
等があると思います。
Scalaはその点よく出来ていてオブジェクト指向と関数型言語がうまく
融合されているのでScalaのような言語が広まった後
Haskell等の文法にシフトしていくことはあるのかも。

701 ：デフォルトの名無しさん：2010/05/29(土) 21:05:42

型推論も可読性はどうだろう

702 ：デフォルトの名無しさん：2010/05/29(土) 21:06:48

型推論は型が長い時だけにしたい

703 ：デフォルトの名無しさん：2010/05/29(土) 21:08:49

仕様を書く、という習慣が身についていない人は関数型は難しいと思うよ。
それに関数型言語で書かれたソースも実機で動くプログラムになるわけだから、
その過程が想像しにくいというのも敬遠される理由かもしれないね。

704 ：デフォルトの名無しさん：2010/05/29(土) 21:11:40

>>703
計算機科学者は好みそうだね、関数型

705 ：デフォルトの名無しさん：2010/05/29(土) 21:12:41

>>665
CのマクロでLispのマクロをすべて実現することはできないよ。
新しい言語でLisp級のマクロを実現するアイディアはあるけど。

Lispが普及しない理由はLispのマクロにあるのではなくて、
Lispのシンタックス、見た目に問題があるからでしょう。

706 ：デフォルトの名無しさん：2010/05/29(土) 21:14:23

Lispの見た目はマクロによるものだろ

707 ：デフォルトの名無しさん：2010/05/29(土) 21:16:09

このように根拠のない妄想がタチ悪い

708 ：デフォルトの名無しさん：2010/05/29(土) 21:16:41

構文木を弄るからだよ

709 ：デフォルトの名無しさん：2010/05/29(土) 21:18:52

言語をマクロに合わせた結果、LISPは括弧とスペースの言語になってしまったのだろうか？
ジョン・マッカーシーはλ計算の記法としてLISPを考えたわけだけど、
その時マクロの事なんて考えていたんだろうか？
そもそもλ計算にマクロという概念はあったっけ？

710 ：デフォルトの名無しさん：2010/05/29(土) 21:20:32

手続き型と関数型は波動力学と行列力学みたいなもの

711 ：デフォルトの名無しさん：2010/05/29(土) 21:36:23

関数型言語は並列計算に強い。
というのも、ラムダ計算という強力な理論に裏付けされているからだ。
ラムダ計算にはチャーチ・ロッサー性という性質があって、
式の中の部分式をどこから評価しても結果は一緒ということが証明されている。
つまり、部分式を並列に実行しても良いということなんだ。
しかし例えばC言語みたいな言語は状態を持っているから、
必ずしも結果が同じになるとは限らない。
だって、たとえば、もし部分式が同じグローバル変数を操作していたら
最初に実行された部分式の評価が別の部分式にも影響を及ぼすからね。

712 ：デフォルトの名無しさん：2010/05/29(土) 21:37:57

>>709
計算理論では、足し算から掛け算を定義したりする
つまり根本的な要素だけを与えられれば、当然可能だわな
マクロという概念があろうがなかろうがそのくらいのことは想定して作ってあるだろ

713 ：デフォルトの名無しさん：2010/05/29(土) 21:38:12

つまり、これからのマルチコア時代は並列計算は避けて通れないわけで、
関数型言語が主流にならなければならない十分な理由があるわけさ。

714 ：デフォルトの名無しさん：2010/05/29(土) 21:45:14

>>709
LispはListを基本としたから今の見た目になっている。
Listだから構文木を操作するマクロを書きやすいのだ。
>>710
その表現は的を得ている。統一的な理論を作るのは難しい。

715 ：デフォルトの名無しさん：2010/05/29(土) 21:49:36

副作用うんぬんは昔から言われてたしerlangもあるが大流行してるわけでもない。結局手続き型に簡単なルールを導入する方が正解だと思う。

716 ：デフォルトの名無しさん：2010/05/29(土) 21:54:38

>>715
ハードのマルチコア化がメインストリームになってきたのはせいぜいここ5年ほどだろ？
そしてマルチコアと並列処理の重要性がまだまだ現場まで浸透していないのが現状。
もし流行するとしたらこれからだよ。

717 ：デフォルトの名無しさん：2010/05/29(土) 21:57:21

既存の手続き型言語でも関数プログラミン的なことは出来るでしょ

718 ：デフォルトの名無しさん：2010/05/29(土) 21:58:12

人は安全性とか理論的正確さなんかよりも目に見えるメリットを欲しがるものだ。
今まで関数型言語が流行しなかったのは目に見えるメリットが無かったから。
でもこれからは違うよね。

719 ：デフォルトの名無しさん：2010/05/29(土) 21:58:53

>>717
チャーチ・ロッサー性はないでしょ？

720 ：デフォルトの名無しさん：2010/05/29(土) 22:01:00

スレッドの技術は昔からあったし関数言語も昔からあった。
でもこれまでは手続き型で対処してきた。
ここ数年で必要性が高まったから再注目されているが
これまでなぜ採用されてこなかったかには理由がある。
再注目の結果関数型からインスパイアされた技術が
いくつか手続き型に組み込まれる流れになると思うよ。

721 ：デフォルトの名無しさん：2010/05/29(土) 22:01:22

こんなに高性能でサクサク動くこのアプリ、関数型言語で作ったんです

と誰かがプロモーションすれば流行るよ

722 ：デフォルトの名無しさん：2010/05/29(土) 22:05:06

monadius（笑）

723 ：デフォルトの名無しさん：2010/05/29(土) 22:09:46

>>720
例えば関数型言語だったら、
関数が内部で別の関数を呼んだら、それが勝手に別のスレッドで実行される、
あるいは別のネットワークでつながれたマシン上で実行される、
という処理系を作ることだってできるんだよ。
もしその手続き型言語だったら状態の縛りがあるから
どの処理をどのように並列化するのか全部自分で指示しなきゃいけない。
その違いがあるね。
将来的な言語は並列化も自動でやってくれるようになると思うよ。

724 ：デフォルトの名無しさん：2010/05/29(土) 22:10:34

MTASC, haXe は高性能でサクサク

725 ：デフォルトの名無しさん：2010/05/29(土) 22:13:06

新言語でも、こんなふうに構文を拡張できるようにしたいな。

JavaScriptのwithをRubyでも使いたい夢をあきらめないで。 - このブログは証明できない。
http://d.hatena.ne.jp/shunsuk/20100420/1271753512

726 ：デフォルトの名無しさん：2010/05/29(土) 22:39:09

スケールアウト可能なRDBを関数型で作ってサーバ増やすと
勝手に並列分散してくれたらうれしいとか思ったけど
スレ違いな気がしてきた。（汗

727 ：デフォルトの名無しさん：2010/05/29(土) 23:05:21

勝手にスケールアウトするWebサーバアプリとか

728 ：デフォルトの名無しさん：2010/05/30(日) 03:10:13

>>725
Rubyって凄いんだな

729 ：デフォルトの名無しさん：2010/05/30(日) 04:55:43

>>725
静的にこれをどう解決するかが問題だな

730 ：デフォルトの名無しさん：2010/05/30(日) 05:10:13

コンパイル時に環境を変えることが出来る仕組みかぁ。
環境って要するに変数の検索順と検索するスコープをいじるってことだろ。
型とdelegateを取って、delegateの環境というか、変数の検索に
呼び出し元の関数のスコープとオブジェクトのスコープを切り替えられる
仕組みがあればいいのか。

731 ：デフォルトの名無しさん：2010/05/30(日) 08:36:51

>>721
twitterの裏はRubyから移行してscalaだよな

コンピュータがチューリングマシンをモデルにしていて
人間が逐次的にモノを考えているうちは手続き型がメインだな
両方進化して別物になる頃には関数型が流行るかもしれん

ヘテロな並列について
golangのこないだのblogにはgoroutineをコプロ向けにコンパイルして
GPGPUみたい奴で走らせても面白いってなことが書いてあったな
個人的にはマシンコード、サブプロセッサのマシンコード、HDLを一つの言語から
生成できればとても面白いんじゃないかと。妄想だなｗ

732 ：デフォルトの名無しさん：2010/05/30(日) 08:40:18

>>729
こんなもんPascalでもあったっしょ
別物か？
そんな高度なことしなくてもコンパイル時の
名前検索に機能追加するだけじゃねえの

733 ：デフォルトの名無しさん：2010/05/30(日) 08:55:29

PascalとかVBとかのwithと一緒だね
まあ、CとかJavaとかしか知らない人は知らないんだろう

734 ：デフォルトの名無しさん：2010/05/30(日) 09:34:54

>>733
withってそんなに便利とも思えないんだが
なくても別に困らない程度の構文だよね

735 ：デフォルトの名無しさん：2010/05/30(日) 09:53:59

>>725
プリプロセスで、コンパイラコンパイラを使ってコンパイラを作るか、
コンパイラをDSLで構成すれば可能じゃね？

鬼だ。

736 ：デフォルトの名無しさん：2010/05/30(日) 10:33:09

>>735
VMだけ提供するから文法は好きなように設計してくれ、
と言えばぜんぜん鬼ではないな。

だが、VMとコア言語を提供されると、コア言語がしがらみになる。

コア言語の巧拙をもっと議論するべきだ。
構文糖で尻拭いするのは最後の悪あがきであって、嬉々として語るようなことではない。

737 ：デフォルトの名無しさん：2010/05/30(日) 11:27:59

Lispのラムダは記法を借りただけに近いぞ

738 ：デフォルトの名無しさん：2010/05/30(日) 11:51:35

>>732 >>733
withが出来ることが重要なのではない。
withを拡張で作ることが出来るのが重要なのだ。
>>735
そのためにはどんな仕組みがあればいいのだろう？
その仕組みを考えることこそが重要だ。>>736と同意見だ。

739 ：デフォルトの名無しさん：2010/05/30(日) 11:56:03

with は、インタプリタの性能向上のためという面もある。
最適化をするそれなりのコンパイラではメリット小さい。

740 ：デフォルトの名無しさん：2010/05/30(日) 12:06:07

コンパイルタイムの名前解決を変更できるとしたらどうだろう？
コンパイラはプラグインで名前取得用の関数を書き換える機能を提供する？
動的に名前解決の関数のポインタを置き換えることができるようにするのだ。
書き換える関数はその言語で記述し、ダイナミックリンクして置き換えるのだ。

741 ：デフォルトの名無しさん：2010/05/30(日) 12:18:25

コアファイターのような言語を開発したい

742 ：デフォルトの名無しさん：2010/05/30(日) 12:33:02

>>736 >>738
いや、嬉々として語っては無いが？
つーか、λ項とレキシカルスコープの実装から脱線しすぎだ。
もういいや。

743 ：デフォルトの名無しさん：2010/05/30(日) 12:39:13

正直、純粋関数型言語じゃないと関数型言語の旨みは無いし、言語も進化しない。
もうラムダ式からプログラムへ変換できるぐらいで満足していたらいけないんだよ。
プログラムがラムダ式と同等の性質を持つためには純粋関数型言語じゃないとダメ。
ラムダ計算はまだプログラミングの世界で本領を発揮していないからねぇ。
そろそろ次のステップに進まないとね。

744 ：デフォルトの名無しさん：2010/05/30(日) 12:41:46

純粋関数型言語は使い道がないのも事実。
手続き型に寄生するのがベスト。

745 ：デフォルトの名無しさん：2010/05/30(日) 12:46:24

>>744
自動並列化・・というと自動プログラミングみたいな臭いがしてしまうが、
少なくとも理論的可能性は純粋関数型言語の方が有利。
チャーチ・ロッサーの定理って知ってる？

746 ：デフォルトの名無しさん：2010/05/30(日) 12:49:39

さらに、純粋関数型言語はグラフ理論による最適化に有利。
だって純粋関数は入力と出力以外に無いんだから。

747 ：デフォルトの名無しさん：2010/05/30(日) 12:49:54

初期のamazonのサーバーがLispだったはず。

748 ：デフォルトの名無しさん：2010/05/30(日) 12:50:52

このスレ的には、Webブラウザが書けるようなものを求めてると思うぞ

749 ：デフォルトの名無しさん：2010/05/30(日) 12:52:35

そうなの？OS作ったり、省メモリを必要とする組み込みで使ったりするものかと思ってたけど

750 ：デフォルトの名無しさん：2010/05/30(日) 12:54:22

遅延評価しない純粋関数型言語ってあり得るんだろうか？
もしあり得るとしたらIOはどんなふうになるのかな。
現存する実装は存在する？

751 ：デフォルトの名無しさん：2010/05/30(日) 12:54:48

>>746
純粋関数ｗって、正規表現かSQLみたいなポジションだよね

752 ：デフォルトの名無しさん：2010/05/30(日) 12:59:09

ぜんぜん低水準言語の話じゃなくなってるわけだが

753 ：デフォルトの名無しさん：2010/05/30(日) 13:00:54

>>748
apacheより高速で実用的なwebサーバがhaskellで550行程度で作られているが・・・
mighttpd

754 ：デフォルトの名無しさん：2010/05/30(日) 13:02:13

>>751
はいはい、software designを読んだ人ね
SQLが関数型言語だ、という主張を真に受けてhaskellもSQLと同じなんだと思っちゃったわけね

755 ：デフォルトの名無しさん：2010/05/30(日) 13:03:36

エクセルが関数型言語って言ってる人もいたよ

756 ：デフォルトの名無しさん：2010/05/30(日) 13:05:01

Haskellでシューティングゲームを作ったまとめ
http://d.hatena.ne.jp/kryozahiro/20100529/1275143000

757 ：デフォルトの名無しさん：2010/05/30(日) 13:08:12

なぜ関数型が並列化できるのか理解してないんだな。Cでもひとつ制限加えれば可能なのに。

758 ：デフォルトの名無しさん：2010/05/30(日) 13:09:30

>>757
どういう制限を加えればいいんですか？

759 ：デフォルトの名無しさん：2010/05/30(日) 13:09:31

命令型にSQLとかを埋め込むか
関数型にIOを埋め込むかで揉めてるだけ

760 ：デフォルトの名無しさん：2010/05/30(日) 13:12:04

C++でプログラミングしてる人はマルチコアをどういうふうに利用しているんだろう。
たぶんWorkerパターンを毎回作ってるんだろうな、と思う。
それって自動化できるんじゃない？

761 ：デフォルトの名無しさん：2010/05/30(日) 13:12:59

関数の引数が順序立てて評価されない、という制限を加える、ということか？

762 ：デフォルトの名無しさん：2010/05/30(日) 13:17:20

マルチコアマルチコアって言うけど
１つのアプリに複数のコアを占有されるのは正直ウザい
あれは重い処理するアプリがあっても
他のアプリやOSの動作を重くしないためのものだと思ってる

そのアプリだけ動かすような状態になってもいいから
高速化したいようなアプリは例外だけど（画像処理とか、ゲームとか）
普通のアプリはむしろ利用しない方がありがたい

763 ：デフォルトの名無しさん：2010/05/30(日) 13:20:35

チャーチ・ロッサーの定理とはどのようなものですか？

764 ：デフォルトの名無しさん：2010/05/30(日) 13:26:28

わかってない、理解してないというだけか。

765 ：デフォルトの名無しさん：2010/05/30(日) 13:35:39

マルチコアとか特別なことか？
マルチスレッドでプログラムしとけば
OSが勝手にスケジューリングするだけだろう。
スレッド管理はOSに依存するからライブラリがふさわしい。

766 ：デフォルトの名無しさん：2010/05/30(日) 13:36:29

>>749
このスレを占拠しているLISPerにとって、
低レベルってのは、webサーバとかSQLサーバとか程度のレイヤの話で
OSカーネルとか、8bit/16bitマイコンを使った組み込みのことは1msも考えてない。

767 ：デフォルトの名無しさん：2010/05/30(日) 13:40:45

それはアンチLisp、アンチ関数型だろ

768 ：デフォルトの名無しさん：2010/05/30(日) 13:42:31

ここは関数型言語厨のすくつですね

769 ：デフォルトの名無しさん：2010/05/30(日) 13:45:22

実際、最近の言語は関数型言語的な事が出来るようになってるから
抽象化という意味で新言語はそうなるだろう

770 ：デフォルトの名無しさん：2010/05/30(日) 13:49:10

>>766
いやGCとかVMとか言ってる連中のレベルが低レベルという意味だろう。
java言語は否定しないがjavaVMでDBサーバとか勘弁してもらいたい。
webブラウザのプラグインくらいに留めておいてほしいものだ。

771 ：デフォルトの名無しさん：2010/05/30(日) 13:53:22

スレタイには、C/C++に代わると書いてあるんだから、C/C++が出来ることを実現できなくっちゃね。

WebサーバーやSQLサーバーを記述できないとね。＞関数型

772 ：デフォルトの名無しさん：2010/05/30(日) 13:56:14

つ mighttpd

773 ：デフォルトの名無しさん：2010/05/30(日) 13:57:29

GC使用モード、VM使用モードが
規格で用意されていれば良い
オンオフ可で

774 ：デフォルトの名無しさん：2010/05/30(日) 14:38:02

firefoxってC++で書かれているんだよね。すごいぜ高級アセンブラ

775 ：デフォルトの名無しさん：2010/05/30(日) 14:41:06

だからfirefoxは糞なのか

776 ：デフォルトの名無しさん：2010/05/30(日) 14:44:56

結局、LISPerも「低レベル」のこと考えてないじゃん

777 ：デフォルトの名無しさん：2010/05/30(日) 14:48:01

「低レベル」じゃなくて「低レイヤ」の方がいかもしれん

778 ：デフォルトの名無しさん：2010/05/30(日) 15:10:38

低レイヤでは、動的な仕組みは使わない方がよいですよね。
だから、コンパイルタイムでいろいろやるとかいうのがいいと思いますよ。
ただ、関数型言語が云々いう人がいて何かを主張しているわけだから
聞きましょうよ。

779 ：デフォルトの名無しさん：2010/05/30(日) 15:15:27

↓以下、低レイヤーにおける関数型のメリットが挙げられます。静かに聴きましょう

780 ：デフォルトの名無しさん：2010/05/30(日) 15:16:15

アンチもたいがいだな

781 ：デフォルトの名無しさん：2010/05/30(日) 15:30:29

関数型言語のパターンマッチ機能はとても強力なので
低レイヤーの言語でも検討する余地があると思います。

782 ：デフォルトの名無しさん：2010/05/30(日) 15:34:18

式ベースな構文はマクロや構文木を操作するのに有利に働きます。
優先順位付きのユーザー定義可能な演算子も後から
ライブラリで機能を追加する上で構文を追加したような効果が得られるので有利です。

783 ：デフォルトの名無しさん：2010/05/30(日) 15:36:01

末尾再帰最適化の機能があれば、
ループを使うことなく、アルゴリズムを再帰を使って
綺麗に記述することが出来ます。

784 ：デフォルトの名無しさん：2010/05/30(日) 15:37:58

ループの方が素直で綺麗
必要以上に再帰を使うのは歪んでる
forの代わりにifとgotoで記述するようなもの
コードの意図が不明瞭になる

785 ：デフォルトの名無しさん：2010/05/30(日) 15:48:05

再帰がどのようにメモリを使うか知らないんだろうな。

786 ：デフォルトの名無しさん：2010/05/30(日) 15:52:29

関数型の再帰と手続き型の再帰は違うよ

787 ：デフォルトの名無しさん：2010/05/30(日) 15:53:22

>>785 末尾呼び出しの最適化を知らない手続き脳ですね、わかります。

788 ：デフォルトの名無しさん：2010/05/30(日) 15:54:09

kwsk

789 ：デフォルトの名無しさん：2010/05/30(日) 15:56:10

ホントにわかってないｗ

790 ：デフォルトの名無しさん：2010/05/30(日) 15:58:42

手続き型だって末尾再帰最適化くらいするよw

791 ：デフォルトの名無しさん：2010/05/30(日) 16:01:55

IDがないからバカに横レスされると困るな、ム板は

792 ：デフォルトの名無しさん：2010/05/30(日) 16:05:18

敗北宣言ｗ

793 ：デフォルトの名無しさん：2010/05/30(日) 16:05:19

その前に、ループと再帰は必要十分の関係にあるのか

794 ：デフォルトの名無しさん：2010/05/30(日) 16:06:18

おいおい

795 ：デフォルトの名無しさん：2010/05/30(日) 16:07:04

>>784で言ってるのは、
再帰で書くかループで書くかというその使い分けから
コードの意味を汲み取りやすくなったりするという事を言っている
そりゃ何でも再帰で書けるだろうけど、
それは何でもifとgotoで書けると主張する事と大して違いはない

796 ：デフォルトの名無しさん：2010/05/30(日) 16:08:18

どちらでも書けるということが重要だと思うね

797 ：デフォルトの名無しさん：2010/05/30(日) 16:30:47

手続き型言語ならわざわざ末尾最適化させるような再帰で書かずにループで記述するだけでしょ

798 ：デフォルトの名無しさん：2010/05/30(日) 16:36:26

スタックってローカル変数も消費するけどそれすら回避できるの？

799 ：デフォルトの名無しさん：2010/05/30(日) 16:44:46

n番目の再帰がn-1番目の再帰の結果に依存するようなものは最適化できるのか？

800 ：デフォルトの名無しさん：2010/05/30(日) 16:47:14

int factorial(int n) {
　return (n <= 0 ? 1 : n * factorial(n - 1));
}

を g++ -O2 でコンパイルするとこうなる

__Z9factoriali:
　pushq %rbp
　movq %rsp, %rbp
　movl $1, %eax
　testl %edi, %edi
　jle L6
　.align 4,0x90
L5:
　imull %edi, %eax
　decl %edi
　jne L5
L6:
　leave
　ret

完全にループになってるっしょ

801 ：デフォルトの名無しさん：2010/05/30(日) 16:49:25

で？

802 ：デフォルトの名無しさん：2010/05/30(日) 16:49:32

正直、低レベルだからといって特別なことは何もないと思うよ。
要はinput/outputの処理をロスが最小限になるようにできる言語が欲しいってことでしょ。
だったら単純にベンチマークで比較すりゃいいんじゃないの？

803 ：デフォルトの名無しさん：2010/05/30(日) 16:49:55

漸化式はそれだけで自明だと思うが、どこがループより分かりにくいのかな

804 ：デフォルトの名無しさん：2010/05/30(日) 16:50:50

>>799
それってアセンブリ言語的には単純にジャンプループに最適化できることじゃん。

805 ：デフォルトの名無しさん：2010/05/30(日) 16:51:17

>>787とか言いつつ>>801とか
関数言語厨は頭湧いてるな

806 ：デフォルトの名無しさん：2010/05/30(日) 16:52:06

そのレベルだと簡単に最適化できるとわかるけど、出来ない場合はあっという間にスタックオーバーフロー

807 ：デフォルトの名無しさん：2010/05/30(日) 16:53:01

>>805
実用のソフトを書いてみれば冷めるんじゃね。

808 ：デフォルトの名無しさん：2010/05/30(日) 16:53:46

>>803
漸化式なら手続き型でも再帰で書けばいいじゃない
どうせ末尾再帰最適化されるんだから
漸化式を書くケースなんてほとんどないだろうけど

809 ：デフォルトの名無しさん：2010/05/30(日) 16:54:56

たとえばSchemeは意味論で厳密に「末尾呼び出し」が決まってて、
それを処理する場合は必ず最適化される。

810 ：デフォルトの名無しさん：2010/05/30(日) 16:55:07

手続き型ではループで書くが

811 ：デフォルトの名無しさん：2010/05/30(日) 16:55:32

で？

812 ：デフォルトの名無しさん：2010/05/30(日) 16:57:41

ループで書けばいい物を再帰で書こうとするから
関数型は流行らないということが理解できないのかね

813 ：デフォルトの名無しさん：2010/05/30(日) 16:58:47

ループって長ったらしくて汚いじゃん
まるでダラダラ言い訳続けるヤンデレ少女のようだ

814 ：デフォルトの名無しさん：2010/05/30(日) 16:59:28

>>812
まるでループ信者

815 ：デフォルトの名無しさん：2010/05/30(日) 16:59:56

言ってみれば高級アセンブラを作ろうという趣旨のスレに、なぜか関数型言語厨が現れる不思議
コンパイラの出力が結局はif gotoで記述されてるものになるということが分かってないのかもしれん

816 ：デフォルトの名無しさん：2010/05/30(日) 17:00:10

同じことは二度と言わねーぜっていうクールさがカッコいいよね、再帰

817 ：デフォルトの名無しさん：2010/05/30(日) 17:01:05

>>815
じゃあifとgotoだけの言語作ってそればっかり使ってろや

818 ：デフォルトの名無しさん：2010/05/30(日) 17:01:25

>>815 おまえは一生機械語だけ使ってろ

819 ：デフォルトの名無しさん：2010/05/30(日) 17:01:27

>>815
だとしたら実際のコーディングスタイルが関数型だと何が問題のか言ってくれない？

820 ：デフォルトの名無しさん：2010/05/30(日) 17:02:58

みんなでifとgotoしか制御構文が存在しない言語作ろうぜｗ

821 ：デフォルトの名無しさん：2010/05/30(日) 17:03:26

>>820
そういう演習あったなあｗ

822 ：デフォルトの名無しさん：2010/05/30(日) 17:05:18

ifとgotoだけだとさすがにやばいのでIO用にreadとwriteだけ用意しよう。

823 ：デフォルトの名無しさん：2010/05/30(日) 17:06:01

そんなbrainf*ckと大して変わらない言語を作っても

824 ：デフォルトの名無しさん：2010/05/30(日) 17:10:40

しかし、最小限の機能しか持たない言語を実装して行く過程で、
低レベル言語に必要なものとは何かが分かるかもしれないよ。

825 ：デフォルトの名無しさん：2010/05/30(日) 17:10:58

アセンブラってbfとそれほど違いないしな

826 ：デフォルトの名無しさん：2010/05/30(日) 17:12:33

brainfuckこそがお前らが求める言語か？

827 ：デフォルトの名無しさん：2010/05/30(日) 17:13:15

まず目標立てないと話にならないよ。
何を実装するための言語を作ろうとしているのか。

828 ：デフォルトの名無しさん：2010/05/30(日) 17:15:54

ハードウェアに実装された高級brainfuckである機械語を、オサレに記述できる言語

829 ：デフォルトの名無しさん：2010/05/30(日) 17:16:02

>>763
ラムダ式の中の部分式をどこから評価しても結果は一緒ということ

830 ：デフォルトの名無しさん：2010/05/30(日) 17:17:31

>>828
オサレに記述とはどういう意味か詳しく教えてください。
具体的にみんなにもあなたの考えが分かるように伝えてください。

831 ：デフォルトの名無しさん：2010/05/30(日) 17:19:49

>>830
その内容をグダグダ言い合うスレだという認識だが

832 ：デフォルトの名無しさん：2010/05/30(日) 17:20:53

いいかな、マジレスしても。
目標を立てるからには具体的でないと目標の価値がないよ。
例えばMINIXをタネンバウムバージョンよりも高速、かつ、短く書き直す、
というような明確な目標が欲しいな。

833 ：デフォルトの名無しさん：2010/05/30(日) 17:25:09

本気で言ってるならおまえがブロトだせ

834 ：デフォルトの名無しさん：2010/05/30(日) 17:28:51

どうせ具体的な目標なんか決めても実物なんてできっこないくらいみんなわかってるんじゃないのか
そのうえでグダグダ言ってるのを楽しむスレだろ

835 ：デフォルトの名無しさん：2010/05/30(日) 17:30:51

具体的な目標に束縛されるのはハッカーらしくない（ｷﾘｯ

836 ：デフォルトの名無しさん：2010/05/30(日) 17:32:36

オレオレアイディアを披露するスレがちょうど無かったので
ここに玉石混交のネタが集中してる感

837 ：デフォルトの名無しさん：2010/05/30(日) 17:33:20

目標は

具体的で明確であり、
公共的であり、
スレ住人の興味を引き、
イノベーションを起し、
競争意識を高めるもの、

でなければならない。

そしてその目標を達成するための言語を作ろう。

その上で、さらに、C/C++より優れた点を一つ以上持つ言語を作ろう。

838 ：デフォルトの名無しさん：2010/05/30(日) 17:37:01

目標が「具体的な目標を作ろう」であってもいいけどな

839 ：デフォルトの名無しさん：2010/05/30(日) 17:39:43

>>834
俺が作る！

840 ：デフォルトの名無しさん：2010/05/30(日) 17:52:59

C/C++に代わるということは、この言語の処理系の出力が機械語だということだと思う

841 ：デフォルトの名無しさん：2010/05/30(日) 17:57:01

C/C++にとって代わるかどうかは世に出してみないと分からない事なので、
さしあたっての目標はC/C++より優れた点を一つ以上持つ言語ということでどうだろう？

842 ：デフォルトの名無しさん：2010/05/30(日) 17:58:42

速度よりもヒューマンインターフェースの部分で勝負した方が勝ち目がある気がするから、
最初に作る処理系はインタプリタでも構わないと思う。

843 ：デフォルトの名無しさん：2010/05/30(日) 17:59:36

すげーどーでもいいけど
>>800のコードは「末尾再帰」ではないよね
末尾再帰で書くなら、こう

int fact1(int n, int acc) {
　return n <= 0 ? acc : fact1(n - 1, n * acc);
}
int factorial(int n) { return fact1(n, 1); }

単純な例では、gccは末尾再帰化→ループ化までやってくれてるってことだね

844 ：デフォルトの名無しさん：2010/05/30(日) 18:01:08

VCもするよ

845 ：デフォルトの名無しさん：2010/05/30(日) 18:01:50

ループはループで書くのがわかりやすいってことだ。

846 ：デフォルトの名無しさん：2010/05/30(日) 18:03:38

それは配列使ってるから。
そして抽象化されないのがあたりまえという刷り込みが脳みそにあるから。

847 ：デフォルトの名無しさん：2010/05/30(日) 18:04:46

>>843
まあね
引数増やすの面倒くさかったし
ちゃんと最適化してくれるからああしたけど

848 ：デフォルトの名無しさん：2010/05/30(日) 18:17:30

>>846
どこに配列が？

849 ：デフォルトの名無しさん：2010/05/30(日) 19:17:45

末尾再帰はプログラムの終了を除いて、
基本的にcallやretは存在しない
全部jmpだ
わかるか

850 ：デフォルトの名無しさん：2010/05/30(日) 19:20:42

わかるよ＾＾

851 ：デフォルトの名無しさん：2010/05/30(日) 19:41:20

普通のプログラムをCPS変換すると全部末尾再帰になる
CPSは自動変換できる
どういうことか、わかるか

852 ：デフォルトの名無しさん：2010/05/30(日) 19:41:35

>>841
未だにC/C++以外の言語が入りこめてない分野で使える言語でないと
結局C/C++が残ることになって代わることにはならないと思うんだ
だから最初の条件はそういう分野で使える言語であることだと思う
その上でより優れた言語であることかな

つまりC/C++を駆逐可能な言語

853 ：デフォルトの名無しさん：2010/05/30(日) 20:14:10

既にC/C++以外で間に合う用途からはC/C++は追い出されてるからな。
既存ソフトのメンテナンスを除く新規プロジェクトでC/C++を選ぶ機会は
めっきり減ってしまった。

854 ：デフォルトの名無しさん：2010/05/30(日) 20:15:50

本気でC/C++を駆逐したいのなら、C/C++以外の言語が入りこめてない分野を調べてみろ。
GCとか、VMとか、関数型とか、如何に有り得ない妄想話で盛り上がってたか分かるから。

855 ：デフォルトの名無しさん：2010/05/30(日) 20:17:42

何かわかったのなら、ここに発表すればいいよ。

856 ：デフォルトの名無しさん：2010/05/30(日) 20:18:32

妄想話で盛り上がったらいけない理由が分からない
現実主義者のスレは他にいくらでもあるだろ

857 ：デフォルトの名無しさん：2010/05/30(日) 20:20:35

勘違いした現実主義者がしゃしゃり出て、
本気で新言語の仕様を考えようとした結果がこれだろ

858 ：デフォルトの名無しさん：2010/05/30(日) 20:21:48

>>857
それはパート1で終わってんだよ。空気嫁

859 ：デフォルトの名無しさん：2010/05/30(日) 20:22:42

8,16bitCPU 小規模システム
OS(メモリ管理、ドライバ)
リアルタイム処理
そのほか

860 ：デフォルトの名無しさん：2010/05/30(日) 20:25:26

>>856
完全な妄想よりは現実を基にした妄想の方が面白いでそ

861 ：デフォルトの名無しさん：2010/05/30(日) 20:26:03

パート1で終わってりゃ良かったんだよ、こんなアイちゃんスレ。
誰だよ、あの時次スレ立てたのは。

862 ：デフォルトの名無しさん：2010/05/30(日) 20:26:17

>>856
僕の考えた関数型言語ってスレを立てたほうがいいんじゃんね？

863 ：デフォルトの名無しさん：2010/05/30(日) 20:27:08

宇宙技術、軍事、プロセスコンピュータとかも下手な言語はつかえない。
今やってる制御系の仕事は全部C言語で作ってるわ。

864 ：デフォルトの名無しさん：2010/05/30(日) 20:27:41

私怨で関数型言語を叩いてる奴はどうにかならないの？

865 ：デフォルトの名無しさん：2010/05/30(日) 20:28:20

デバドラを今風の言語機能で書けたら嬉しい。

今、一番も今風なのが関数型。

866 ：デフォルトの名無しさん：2010/05/30(日) 20:29:09

私目的で関数型言語を持ち上げよう奴はどうにかならないの？

867 ：デフォルトの名無しさん：2010/05/30(日) 20:30:18

>>866
オウム返しは良いけど、新言語に関数型が考慮されない理由は何？
rubyも関数型的な一面があるけど

868 ：デフォルトの名無しさん：2010/05/30(日) 20:31:01

関数型言語が苦手で、関わりたくないってことだろ。文脈的に

869 ：デフォルトの名無しさん：2010/05/30(日) 20:31:35

関数型は怖くないよ＾＾

870 ：デフォルトの名無しさん：2010/05/30(日) 20:33:59

>>867
コンパイル時に処理されるなら有り。実行時に処理されるならいらない。

871 ：デフォルトの名無しさん：2010/05/30(日) 20:34:49

次スレは、「新言語を開発したい」と「低水準言語を開発したい」に分離すべきだな

872 ：デフォルトの名無しさん：2010/05/30(日) 20:35:10

>>870
有りと考えてるようには見えないが

873 ：デフォルトの名無しさん：2010/05/30(日) 20:35:48

初心者は全部の機能を使いたがるけど、いらない機能を無理に使わなくてもいいんだよ

874 ：デフォルトの名無しさん：2010/05/30(日) 20:36:47

前から持ってたけど、この板のLISPerのウザさと声のデカさは異常

875 ：デフォルトの名無しさん：2010/05/30(日) 20:37:50

ちゃんと反論しろよ

876 ：デフォルトの名無しさん：2010/05/30(日) 20:38:13

低水準の定義を明確にしないと

関数型で1スレ消耗してしまった

877 ：デフォルトの名無しさん：2010/05/30(日) 20:40:26

低水準言語が関数型を含まないとアンチが定義しないと

878 ：デフォルトの名無しさん：2010/05/30(日) 20:41:52

低水準に関連するキーワード

・ハードウェアを直接操作
・デバドラ

879 ：デフォルトの名無しさん：2010/05/30(日) 20:43:15

それで新しい手続き型でCより優れてる要素は何？

880 ：デフォルトの名無しさん：2010/05/30(日) 20:45:16

関数型言語信者は、低級言語とか高級アセンブラとかと呼ばれることを期待しているのだろうか？

881 ：デフォルトの名無しさん：2010/05/30(日) 20:48:05

話を逸らすな

882 ：デフォルトの名無しさん：2010/05/30(日) 20:52:24

低水準に関連するキーワード

・ハードウェアを直接操作
・デバドラ
・直接アドレス参照
・OS
・GCとかVMとか目的のプログラム以外のものが動作しなくても動くこと。

883 ：デフォルトの名無しさん：2010/05/30(日) 20:53:23

それで新しい手続き型でCより優れてる要素は何？

884 ：デフォルトの名無しさん：2010/05/30(日) 20:54:10

日本語でおk

885 ：デフォルトの名無しさん：2010/05/30(日) 20:55:26

>>868
俺は否定しないな。実際にそうだ。
もっとお爺さんに言うように説明してくれたらわかるかもしれない。

886 ：デフォルトの名無しさん：2010/05/30(日) 20:56:08

わからない機能は無理に使わなくていいよ。

887 ：デフォルトの名無しさん：2010/05/30(日) 20:56:11

・8bit/16bitCPU対応で、RAMが32KBしかなくても動作するプログラムが作れること。

888 ：デフォルトの名無しさん：2010/05/30(日) 20:58:25

新しい手続き型言語って何？　Goとかｗ

889 ：デフォルトの名無しさん：2010/05/30(日) 21:00:20

>>888
当然、お前が考えるものだよ。文脈読め馬鹿

890 ：デフォルトの名無しさん：2010/05/30(日) 21:00:50

基地外に言われたくない

891 ：デフォルトの名無しさん：2010/05/30(日) 21:01:17

Goってことか？

892 ：デフォルトの名無しさん：2010/05/30(日) 21:01:47

>>882
０オーバーヘッド

893 ：デフォルトの名無しさん：2010/05/30(日) 21:04:53

「C/C++に代わる」の意味を、業界のメインストリームを乗っ取ることだと思ってるのがいるな。

894 ：デフォルトの名無しさん：2010/05/30(日) 21:06:06

>>878
Javaでできるｗｗ

895 ：デフォルトの名無しさん：2010/05/30(日) 21:06:14

スレの流れ自体に文句言ってる奴って何一つ、どういうものがふさわしいかってレスをしないよね

896 ：デフォルトの名無しさん：2010/05/30(日) 21:06:21

最終的には現在C/C++が業界で占めている位置を乗っ取る。

897 ：デフォルトの名無しさん：2010/05/30(日) 21:06:47

>>887
Javaだな

898 ：デフォルトの名無しさん：2010/05/30(日) 21:07:25

>>893
それ以外の意味だと意味がないだろ
現実には無理だとしても、そうじゃなきゃ本当にただのネタでしかなくなる

899 ：デフォルトの名無しさん：2010/05/30(日) 21:07:36

そもそも>>1を読め。これは思考実験と、その発想の共有だ
突っ込み入れてる奴の方こそ何も分かってない

900 ：デフォルトの名無しさん：2010/05/30(日) 21:08:14

901 ：デフォルトの名無しさん：2010/05/30(日) 21:09:31

的外れな流れなら壊しても構わない

902 ：デフォルトの名無しさん：2010/05/30(日) 21:09:59

>>887
おいおい。そんな五百円もするようなCPUで仕事が取れると思ってるのか？
RAM は128byteからだ

903 ：デフォルトの名無しさん：2010/05/30(日) 21:10:20

>「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。

904 ：デフォルトの名無しさん：2010/05/30(日) 21:10:36

先ずは自分の的の位置を確認する謙虚さが必要

905 ：デフォルトの名無しさん：2010/05/30(日) 21:12:46

>>902
マの話はマ板でやれ

906 ：デフォルトの名無しさん：2010/05/30(日) 21:12:55

>>899
それはPart2を立てるときに、後付けされた理由だろ。

907 ：デフォルトの名無しさん：2010/05/30(日) 21:13:18

>>905
ゴメソ

908 ：デフォルトの名無しさん：2010/05/30(日) 21:13:54

>>906
だからパート1の流れを引きずってる奴はなんだんだよ
パート1の>>1はそれは無理だと叩かれてどっか行っただろ
そのスレを有効活用してんだよ。今のテンプレに従えカス

909 ：デフォルトの名無しさん：2010/05/30(日) 21:14:49

>>905
このスレこそMLかfjでやれ。妄想談義で6スレも伸ばすな。

910 ：デフォルトの名無しさん：2010/05/30(日) 21:15:20

>>906
現在のスレはあくまでもこのスレだ。

911 ：デフォルトの名無しさん：2010/05/30(日) 21:16:30

どの板にも総合雑談スレはあるだろ

912 ：デフォルトの名無しさん：2010/05/30(日) 21:17:50

>>908
だったらパート1で終わってろよ。
6スレも俺様言語仕様の妄想合戦して何が楽しいんだ。

マ板のOOスレかここは。

913 ：デフォルトの名無しさん：2010/05/30(日) 21:18:17

>>912
お前は何が楽しくてこのスレにいるの？

914 ：デフォルトの名無しさん：2010/05/30(日) 21:18:46

0オーバーヘッドがポイントだな

915 ：デフォルトの名無しさん：2010/05/30(日) 21:19:11

けど、RAM 32kbyteなんてすげー贅沢、って世界でCは使われてると主張しておく
そういうところで使える今風の言語がほしい

916 ：デフォルトの名無しさん：2010/05/30(日) 21:19:38

>>913
お前は何が楽しくてこのスレにいるの？

917 ：デフォルトの名無しさん：2010/05/30(日) 21:20:16

>>915
マシン語が想像できないような高機能な言語は
そういう環境じゃ厳しいんじゃ

918 ：デフォルトの名無しさん：2010/05/30(日) 21:21:40

オウム返しｗ

919 ：デフォルトの名無しさん：2010/05/30(日) 21:21:48

何でも、「無理だ」「厳しい」で諦めちゃう人って、寂しいよね。

920 ：デフォルトの名無しさん：2010/05/30(日) 21:22:28

>>917
マシン語想像できなくても開発出来るけど。

921 ：デフォルトの名無しさん：2010/05/30(日) 21:22:36

メモリ使用量を概算したりするのに
どれだけ言語がどれだけメモリ使うか分からないんじゃねえ

922 ：デフォルトの名無しさん：2010/05/30(日) 21:22:37

プログラミングやる人にも、野暮な人っているんだな

923 ：デフォルトの名無しさん：2010/05/30(日) 21:24:44

なんでも妄想でひっかきまわすだけの奴とか

924 ：デフォルトの名無しさん：2010/05/30(日) 21:25:00

>>909
ｆｊなんてもう死に体だろう

925 ：デフォルトの名無しさん：2010/05/30(日) 21:25:54

>>921
逆に言うと、わかればいいんだよな

926 ：デフォルトの名無しさん：2010/05/30(日) 21:26:45

妄想するにしてもスレタイに沿った妄想しようぜ
超高速でも低級でもC代替でもない言語の話は妄想以前に単なるスレ違い

927 ：デフォルトの名無しさん：2010/05/30(日) 21:26:45

>>924
『オレは「fj」を知ってるんだぞ』って言う単なるアピールだから気にしなくていい。

928 ：デフォルトの名無しさん：2010/05/30(日) 21:28:12

>>923
このスレの基地外が紛れ込んでいるようだよ

フリーソフト作者の愚痴 38
http://pc11.2ch.net/test/read.cgi/prog/1274799337/

929 ：デフォルトの名無しさん：2010/05/30(日) 21:28:24

>>926
だからC代替はCと等価じゃなきゃいけないわけ？
Cとは違うという結論ありきで議論はスタートしてるわけだが

930 ：デフォルトの名無しさん：2010/05/30(日) 21:29:36

最先端の研究成果を取り込むのであって、
昨今の言語のトレンドを取り入れるわけではない。

931 ：デフォルトの名無しさん：2010/05/30(日) 21:30:12

このAAを貼るくらいの余裕がほしい

　　　　　　　　　　　 _,,‐─-v‐､,,、
　　　　　　　　 ,,-‐'": : : : : : : : : : `ヽ
　　　　　　／: : : : : : : ,,_＿ : : : : : : ＼
　　　　　　ｒ': ,､,,.-─''"゛　　ﾐ : : : : : : : 'ｉ、
　　　　　 `/ /　　　　　　　ﾐ_ : : : : : : :,､}
　　　　　　ｉ　l　　　 _,,..-‐^‐-､ `ﾞｉ: : : ／l.l|
　　　　　　ｉ、}‐-、ヽ;;/,rｪｯ;;'"　ﾞー'　9ｉﾘ!
　　　　　　| 　',tテi　ヽ＝'"　　　　　ゞ t'
　　　　　　 |　 'i"´|　, -､　　　　　　　　ヽ-､,,_＿_
　　　　　　 |　　'}､ !,,tu'" 　ヽ、　 ,l: ‐-‐" }: : : : :
　　　　　　 }　　 lヽ､__,,,.-‐ヽ　　/: : : : : : /|: : : : :
　　　　　,r/　　/: : :ヽー‐'　　ﾉ: : : : : : : / .|: : : : :
　　　　 /: ＼ /: : : : : 丶,, -''_: : : : : : ／　 |: : : : :
　　　/: : : : :ヽ／: : : : : : : ヽﾞ''‐--‐ヽ　　 |: : : : :
　　/: : : : : : : : : : : : : : : : : : ヽ＼: : /　　|: : : : :

　　　　　エフジェー＝デ＝ヤレー[Fj De Yale]
　　　　　　　　　（1955～フランス）

932 ：デフォルトの名無しさん：2010/05/30(日) 21:30:25

Cじゃなくていいけど0オーバーヘッド

933 ：デフォルトの名無しさん：2010/05/30(日) 21:31:51

>>929
＞新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
これ文章自体、書いたやつの妄想だから。「結果的にCになりましたｗｗサーセンｗｗｗ」って結論もあり。

934 ：デフォルトの名無しさん：2010/05/30(日) 21:32:15

>>929
>だからC代替はCと等価じゃなきゃいけないわけ？

当然
今C(C++に非ず)でやっていることができる言語じゃなければ要件を満たさない

935 ：デフォルトの名無しさん：2010/05/30(日) 21:32:40

ホットスポットを低レベル記述して、全体の制御は高レベル記述できればいいね。

936 ：デフォルトの名無しさん：2010/05/30(日) 21:32:49

>>929
出力が等価かそれ以上の効率
記述性も
言語そのものが一致していたら意味がない

937 ：デフォルトの名無しさん：2010/05/30(日) 21:34:45

非オブジェクト指向で、手続き型で、静的型付けで…
あれ？Cになっちゃった

お前らが望む結論

938 ：デフォルトの名無しさん：2010/05/30(日) 21:36:02

それの何が悪い

939 ：デフォルトの名無しさん：2010/05/30(日) 21:37:22

>>930
最先端の研究成果って何？

940 ：デフォルトの名無しさん：2010/05/30(日) 21:37:41

>>938
頭が悪い

941 ：デフォルトの名無しさん：2010/05/30(日) 21:38:49

オブジェクト指向はいくつも両立例があるが

942 ：デフォルトの名無しさん：2010/05/30(日) 21:39:10

>>939
大学とか研究所の論文でも漁って来いや。

943 ：デフォルトの名無しさん：2010/05/30(日) 21:39:43

関数型は並列で有利な話が途中で止まってしまったorz...

944 ：デフォルトの名無しさん：2010/05/30(日) 21:40:20

>>940
全く新しい言語じゃないといけないと思ってる、お前は頭が固い

945 ：デフォルトの名無しさん：2010/05/30(日) 21:40:42

>>943
そんな些細なノイズに負けてたら、２ちゃんねるに書き込む資格はないよ。

946 ：デフォルトの名無しさん：2010/05/30(日) 21:41:19

>>944
全く新しくなくて良いよ？
でもCにはない要素が一つもないじゃん。これでCの代替って笑うしかないんだけど

947 ：デフォルトの名無しさん：2010/05/30(日) 21:41:32

副作用でぐぐってろ

948 ：デフォルトの名無しさん：2010/05/30(日) 21:41:48

>>943
具合的な実装方法を考えてみれば？

949 ：デフォルトの名無しさん：2010/05/30(日) 21:41:58

俺が負けたわけじゃなくて、書いてた人が来なくなったのかなと。

950 ：デフォルトの名無しさん：2010/05/30(日) 21:43:03

>>942
どの論文かポインタ示せよ

951 ：デフォルトの名無しさん：2010/05/30(日) 21:43:16

>>943
そもそも並列が(このスレ的に)求められてるの？
HDLとかだと面白いかもだが

952 ：デフォルトの名無しさん：2010/05/30(日) 21:43:28

>>946
みんなで笑って大団円を迎えるって流れもありなんだよ。

953 ：デフォルトの名無しさん：2010/05/30(日) 21:44:09

○○はCに出来ないから、C代替にもなくて良い

こんな馬鹿げた話がある？

954 ：デフォルトの名無しさん：2010/05/30(日) 21:46:02

>>953
そんな話してんのお前だけだよｗ

955 ：デフォルトの名無しさん：2010/05/30(日) 21:46:37

スケーラビリティすら否定するのはどうだろう

956 ：デフォルトの名無しさん：2010/05/30(日) 21:47:03

>>950
ggrks

>>953
馬鹿げた話で終わったら、それはそれで仕方ないだろ。

957 ：デフォルトの名無しさん：2010/05/30(日) 21:47:06

>>952
みんなが笑うには成果がなければならない。
有終の美以外は許さないよ。

958 ：デフォルトの名無しさん：2010/05/30(日) 21:47:38

終わらせたい奴がCで良いだろって言ってるだけだよなあ
なんでこのスレにいるんだろ

959 ：デフォルトの名無しさん：2010/05/30(日) 21:47:58

>>943
このスレで求められているかどうかはわからないけども、
関数型では並列が有利とかいう人の話を最後まで聞いてみたかったなと。
何かしら参考になることがあるのかもなぁと思って。
並列をわかりやすく書けて、高速に動くならありじゃない？

960 ：デフォルトの名無しさん：2010/05/30(日) 21:48:15

Cでいいだろ発言はこのスレでは禁止
理由は>>1

961 ：デフォルトの名無しさん：2010/05/30(日) 21:48:24

Cで良いって結論は実質別スレのパート１で終わったの
パート１の話をしたいやつはスレチと言っても良いね

962 ：デフォルトの名無しさん：2010/05/30(日) 21:49:12

EC++の代替案考えるのもあり

963 ：デフォルトの名無しさん：2010/05/30(日) 21:49:51

スレタイ変えずに、パート2にした理由は？

964 ：デフォルトの名無しさん：2010/05/30(日) 21:50:57

>>962
EC++はテンプレートがないのが辛い
当時仕様が固まってなかったというのはあるが、テンプレートの方が組み込みには使い道がある気がする

965 ：デフォルトの名無しさん：2010/05/30(日) 21:51:10

>>957
そんなこと思ってんのお前だけだよ。

966 ：デフォルトの名無しさん：2010/05/30(日) 21:51:12

>>963
スレタイの意図が変わっただけだよ

967 ：デフォルトの名無しさん：2010/05/30(日) 21:51:26

(Cを含む既存の)○○でよい、は今後一切禁止
同様に超高速低水準からかけ離れた妄想も一切禁止

968 ：デフォルトの名無しさん：2010/05/30(日) 21:51:47

>>959
おれが改良言語発表するから待って

969 ：デフォルトの名無しさん：2010/05/30(日) 21:54:58

次スレ
http://pc12.2ch.net/test/read.cgi/tech/1275223921/l50
http://pc12.2ch.net/test/read.cgi/tech/1275223999/l50

970 ：デフォルトの名無しさん：2010/05/30(日) 21:55:19

>>966
Part1からいるけど、そんな流れどこにも無かったぞ。

971 ：デフォルトの名無しさん：2010/05/30(日) 21:58:10

今時の言語だから最低限REPLは欲しいよな

972 ：デフォルトの名無しさん：2010/05/30(日) 21:58:28

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものでした。

アイと研究員とのやり取りに利用するスレッドに書き込まれた、
関係者各位の皆様、ご協力ありがとうございました。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

973 ：デフォルトの名無しさん：2010/05/30(日) 21:59:51

C言語へのトランスレータでいいよ

974 ：デフォルトの名無しさん：2010/05/30(日) 22:00:29

おお、分岐した！

975 ：デフォルトの名無しさん：2010/05/30(日) 22:03:37

>>969
それどっちも次スレじゃなくて、forkしただけだろ

低水準言語を開発したい
http://pc12.2ch.net/test/read.cgi/tech/1275223999/

新言語を開発したい
http://pc12.2ch.net/test/read.cgi/tech/1275223921/

976 ：デフォルトの名無しさん：2010/05/30(日) 22:04:47

低水準言語はどうでもいいかなあ。抽象化の話すると叩かれるし

977 ：デフォルトの名無しさん：2010/05/30(日) 22:07:11

【超高速】C/C++に代わる低級言語を開発したい 7
ﾏﾀﾞｧ-? （･∀･）っ/凵⌒☆ﾁﾝﾁﾝ

978 ：デフォルトの名無しさん：2010/05/30(日) 22:07:20

おれ最強言語のほうが興味ない。
お互いのためだな。

979 ：デフォルトの名無しさん：2010/05/30(日) 22:08:02

>>976
抽象化は結構な、というか重要なことだが
やりすぎてハードウェアから乖離しすぎると
低水準を扱う言語としては問題が出てくる

バランス感覚が必要。GCすら問題視される領域で、
関数型言語の技法がそのまま使えはしないだろう

980 ：デフォルトの名無しさん：2010/05/30(日) 22:08:13

>>963
パート1での反応を受けて、本来の意図に適切に沿った議論ができるようにパート2以降の>>1を修正したよ。
表現は変えたけど、元々の思いはそのままだよ。

981 ：デフォルトの名無しさん：2010/05/30(日) 22:09:19

この速さならいえる

982 ：デフォルトの名無しさん：2010/05/30(日) 22:09:43

もともとの>>1は結構作る気満々で、結構現実的な話をしてたよ

983 ：デフォルトの名無しさん：2010/05/30(日) 22:10:43

なんでもありはスケーラビリティではない。

984 ：デフォルトの名無しさん：2010/05/30(日) 22:10:48

>1
3行で要約しろ

985 ：デフォルトの名無しさん：2010/05/30(日) 22:11:56

＞パート1での反応を受けて、本来の意図に適切に沿った議論ができるように
えーとこの発言って、･･･　
実はパート1の>>1は途中で逃げたんじゃなくて、今に至るまでずっと張り付いてたと考えていいのかな？

986 ：デフォルトの名無しさん：2010/05/30(日) 22:12:32

>>984
スタートレック風にしないか？

987 ：デフォルトの名無しさん：2010/05/30(日) 22:13:27

>>985
少なくとも最初の1のような発言は見つけられないけど
スレを立てたのも別の人間だと思ってた

988 ：デフォルトの名無しさん：2010/05/30(日) 22:13:33

スレタイにGC禁止入れとけ

989 ：デフォルトの名無しさん：2010/05/30(日) 22:14:22

あばばばば

990 ：デフォルトの名無しさん：2010/05/30(日) 22:16:22

おぼぼぼぼぼ

991 ：デフォルトの名無しさん：2010/05/30(日) 22:17:21

低水準の方はForthの話でもすればいいのか？
Cは高水準すぎる。

992 ：デフォルトの名無しさん：2010/05/30(日) 22:18:17

駆け巡る鷲巣の脳内物質

993 ：デフォルトの名無しさん：2010/05/30(日) 22:18:17

少なくともC++にスマポがある以上GC禁止はありえない。
無茶な議論が確かに多いけど。

994 ：デフォルトの名無しさん：2010/05/30(日) 22:19:27

>>993
このばあいのGCといったらスマポは指さないと思う

995 ：デフォルトの名無しさん：2010/05/30(日) 22:19:50

スレタイにスマポ禁止入れとけ

996 ：デフォルトの名無しさん：2010/05/30(日) 22:21:14

βエンドルフィンチロシンエンケファリンバリンリジンロイシンイソロイシン

997 ：デフォルトの名無しさん：2010/05/30(日) 22:22:05

174 ：デフォルトの名無しさん[]：2010/03/20(土) 18:30:53
>>1
そのとおり。
そこで、それは何であるかを明らかにし、
最新のやり方でCよりも優れたやり方でそれを実現したい。

238 ：デフォルトの名無しさん[]：2010/03/21(日) 03:19:08
>>234
こんな進化が早い業界で40年前の言語が最適解なわけがない。
C99だとしても10年以上前だ。

現在の知識で一から言語設計すれば、Cよりもっと良い解が必ず存在する。

246 ：デフォルトの名無しさん[]：2010/03/21(日) 10:33:45
既存がどうこうではなく、
いま、最高のプログラミング言語研究者が新たに一から新しい言語を作るとしたらどういう言語を開発するか
という観点で考えて欲しい。

Part2立てたのが>>1じゃないとすれば、こいつかな

998 ：デフォルトの名無しさん：2010/05/30(日) 22:22:15

>>994
やっぱり
話にならんわ

999 ：デフォルトの名無しさん：2010/05/30(日) 22:23:43

999ならRMS死亡

そして次スレ
http://pc12.2ch.net/test/read.cgi/tech/1114223450/

1000 ：デフォルトの名無しさん：2010/05/30(日) 22:23:47

1000ならスレ終了

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。