07/08/05 11:17:42
そんな下らない事で息巻いてたのか…
176:デフォルトの名無しさん
07/08/05 11:26:58
>>174
>で、おまえ等 (一人かも知れんが) のレスのどこに技術の話があるんだ？
俺じゃなくてさ、>>159 の書いてる事が素人っぽかったからね。
「Oberon, Smalltalk は使ってことない」らしいけど、Pascal と Lisp も
殆ど知らないんだろうなと思って。
177:デフォルトの名無しさん
07/08/05 12:26:28
>>175
へ～、君はもっと凄いことについてレスしてるつもりだったんだ。
詳しく説明してくれるかな？
>>176
> Pascal と Lisp も殆ど知らないんだろうなと思って。
そう思うなら、どこか素人っぽいか指摘すればいいだけ。
指摘もできないから、「知らないんだろうな」とか言う技術的じゃ
ないことしか書けないんだろ？
# まさか、「OSのアセンブラコードを吐く」なんて言うわけわかめ
# のことを言ってた奴が絡んでるのかなぁ...。(w
178:デフォルトの名無しさん
07/08/05 12:54:10
この人、リアルでは孤独なんだろうな。。
179:デフォルトの名無しさん
07/08/05 12:57:02
おやまあ
180:デフォルトの名無しさん
07/08/05 12:59:30
シャープマンはそろそろおとなしくしてね
181:デフォルトの名無しさん
07/08/05 13:02:52
"ハードに近い"の定義がされてないのに何この荒れよう。
人によってリアルモードのことだったり割り込みのことだったりしそう。
#リンカスクリプトを言語に統合まだー?
182:デフォルトの名無しさん
07/08/05 13:08:05
自分でやれよｗｗｗｗｗｗｗｗｗ
183:160
07/08/05 13:15:35
>>177
「OSの」は余計って事か。ごめんね。
書いたときは>>152以前は読んでなかったから、OSでも書くつもりなのかと思ってたよ。
>>161には話通じてるみたいだし、スルーされたと思って放置してた。
どのみちファイルに出力できる言語なら何でもできるだろ、
って事を>>148みたいな人へ言いたかったんだけど。
184:デフォルトの名無しさん
07/08/05 13:24:18
ホントにどんな事にでも噛み付いてくる奴は居るもんだな
185:デフォルトの名無しさん
07/08/05 13:41:40
夏だからな
186:デフォルトの名無しさん
07/08/05 13:50:23
>>178-180, >>184-185
「技術的に指摘して」って言ったらこの様ですか...。
まあ、>>185 が言う通り 夏 なんだろうな。
>>181
> "ハードに近い"の定義がされてないのに何この荒れよう。
まあ、最低限として任意のメモリの読み書きができないとダメだろうな。
て言うか、リアルモードとか割り込みなんて事まで言い出すと特定プロセサ
シリーズ専用の言語になるから「標準」でと言うのはないだろうな。
>>183
単に茶化しただけだ、気にしないくれ。
そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
大変面倒なので実際的じゃないという意味) だろ？
て言うか、このスレ自体がネタスレだし...。
> どのみちファイルに出力できる言語なら何でもできるだろ、
>>161 が指摘してる通りそのファイルを実行する手段が必要。
標準の言語仕様としてその機能を持ってる言語ってそんなに多くないよ。
187:デフォルトの名無しさん
07/08/05 14:00:54
>>186
餌欲しい？
188:デフォルトの名無しさん
07/08/05 14:09:42
>>186
各arch毎に言語拡張すれば良くね?
189:デフォルトの名無しさん
07/08/05 14:37:07
>>186
言語仕様に含まれてなくとも、大抵は処理系毎にFFIとかが整備されてるもんだよ。
C言語にしてもasmは標準ではないし、C言語で適当なバイト列を関数アドレスとして
キャストして実行できたりするのも処理系が「たまたま」許してるだけ。
そんな所を君がごちゃ混ぜに語っているのが、分かってないのでは
と言われる理由かと。
190:デフォルトの名無しさん
07/08/05 15:05:34
>186
>そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
>大変面倒なので実際的じゃないという意味) だろ？
大変面倒というのは君の主観でしかないよね。
そういうのは一度作ってしまえばその環境で使いまわせるし、
やることも極めて単純な変換作業だよ。
エミュレータやコンパイラ作ったりする人なら普通に思いつく発想。
で、
>て言うか、このスレ自体がネタスレだし...。
このスレは仮にも「新C言語を作ろう」なんだから、その程度を、
大変面倒と言ってしまうレベルの人間の横槍は遠慮してもらいたい。
191:デフォルトの名無しさん
07/08/05 15:10:02
>>173
ないわけではないよ>>48-61。
>>188
似たようなこととして、DがCPU毎にインラインアセンブリを定めていたはず。
192:デフォルトの名無しさん
07/08/05 15:16:30
>>191
D言語のインラインアセンブラはx86しか(ry
gdcは他のarchの為にasm(gasの文字列);に対応してるけど。
193:>>187 かわいそう...
07/08/05 15:51:36
>>188
そう、実用的には処理系毎の定義と、何らかの言語拡張がなされているのが普通。
特に、ハード周りとかファイル関連はアーキテクチャやシステム毎の差異が大きいので
標準の言語仕様では定義してない方が多い。
Ｃ言語は、PDP + Unix と言うある意味特定環境用の言語として作られたから生い立ちと
して他の言語に比べてそこら辺の定義が比較的されていたんだ。
>>189 の言うキャストなんかも、アーキテクチャが決まっていたから許されていたが、
8086 + DOS みたいにメモリモデルによっては関数へのポインタとデータへのポインタで
ビット幅が違うなんて言う変態的なアーキテクチャだと破綻するので言語仕様からはず
されただけ。
>>189
そういう突込みを避けるために、わざわざ゛>>159 に「標準では」って
言う言葉を入れてあるんだが。
> そんな所を君がごちゃ混ぜに語っている
具体的に指摘よろしく。
>>190
まあ、ちょっと落ち着け。
そういう仕組みを作るのが面倒じゃなくて、単に「ハードに触る」だけで、ファイル作っ
てそれを実行して (必要に応じて結果を) 得るって言うことが面倒だ言ってるんだけど、
理解できてる？
194:デフォルトの名無しさん
07/08/05 15:55:05
もっと毒吐けよｗｗｗｗ
195:デフォルトの名無しさん
07/08/05 16:19:14
>>193
処理系毎じゃなくてarch毎に拡張の標準を決めるべきでね?
196:デフォルトの名無しさん
07/08/05 17:22:27
>>193
>理解できてる？
何を言ってるのかさっぱりわかりませんがその前に、
「君の主観でしかないよね」って言葉は理解してるのかな？
ともかく、何が面倒なのかを焦点に議論するのは無駄でしょう。
重要なのはどういった手法であれ、目的が達成できるかどうか。
よりベターな方法なんて後からいくらでも考えればいい。
>具体的に指摘よろしく。
自覚がないなら遠慮しておきます。
それこそ「面倒」なんで。
197:デフォルトの名無しさん
07/08/05 17:24:43
ANSI Common Lispという本の導入、クロージャを紹介する所でこんなのがある。
(defun addn (n) #'(lambda (x) (+ x n)))
「Cではaddnはどうなるだろう？ちょっとすぐには書けないだろう。
もっとも読者はこんなふうに思うかもしれない。大体こんなことをしたいなどと考え
たりするだろうか、と。しかし、そう考えたりしないのは、プログラミング言語が、それで
できないようなことは、やりたいと思わないように利用者を仕向けているからである。
プログラムを書く言語で考えなければならないのだから、それで書けないことをやり
たいとは考えにくい。私が初めてプログラムを書き始めたころ、それはBasicで書いて
いたのだが、再帰を使いたいなどとは考えなかった。そんなものがあることも知らな
かったのだ。私はBasicで考えていたのだ。
（中略）
(Lispを学習していく)努力の報酬として、上級のC++プログラマがBasicでの
プログラミングに感じるようなやりにくさを、C++に対して感じるようになるだろう。」
198:デフォルトの名無しさん
07/08/05 18:11:01
>>195
例えば、86系用だと io 命令を拡張の標準にするとか？
ちょっとおもしろいかもしれない。
>>196
> 何を言ってるのかさっぱりわかりませんが
ああ、理解できてないなら別にもういいよ。
別に君の意見に反対する気はないし、そういう人に何を言っても無駄だ
と言うことも知ってるから。
> 自覚がないなら遠慮しておきます。
> それこそ「面倒」なんで。
# 指摘できない言い訳を２行も書くのは面倒じゃないんだ...。(w
199:デフォルトの名無しさん
07/08/05 18:13:34
「俺はまともなんだが、どうにも馬鹿が多くて話が進まないなぁ」
と思ってるそこのキミ。それはつまりキミが馬鹿なんです。
200:デフォルトの名無しさん
07/08/05 18:17:02
>>198
> > 自覚がないなら遠慮しておきます。
> > それこそ「面倒」なんで。
> # 指摘できない言い訳を２行も書くのは面倒じゃないんだ...。(w
>>196のこの部分は、
「ああ、理解できてないなら別にもういいよ。
別に君の意見に反対する気はないし、そういう人に何を言っても無駄だ
と言うことも知ってるから。」
という意味のことを、それよりは少し短く言ってるだけだと思うよ。
201:デフォルトの名無しさん
07/08/05 18:17:51
その典型的な例がシャープ
202:デフォルトの名無しさん
07/08/05 18:28:03
できない言い訳に、他人の無能さを持ち出す人って饒舌だからね
203:デフォルトの名無しさん
07/08/05 19:21:10
>>200
はいはい、言い訳はもう結構です。
204:デフォルトの名無しさん
07/08/05 20:37:33
何を話してるのかはさっぱりわからんが、誰が痛いかはよくわかる。
205:デフォルトの名無しさん
07/08/05 20:48:27
>>204
だな。主観で話してるお前が一番痛い。
206:デフォルトの名無しさん
07/08/05 20:57:42
いや、そいつは二番目だ。
一番は俺だからな。
207:デフォルトの名無しさん
07/08/05 21:10:31
いやいや俺だ
208:デフォルトの名無しさん
07/08/19 18:24:44
>>207
そうだな
209:デフォルトの名無しさん
07/08/19 19:23:20
ここは誰が一番痛いか競うスレですかそうですか。
210:デフォルトの名無しさん
07/08/19 19:32:53
そうだよ
君もエントリーするかい
211:209
07/08/19 19:43:53
よろしくお願いします。
一応下記の至らぬスレの主です。
おら！Nをオトメに見つけて++Nを得るムを作らん？！
ｽﾚﾘﾝｸ(tech板)l50
212:デフォルトの名無しさん
07/08/19 20:05:21
ﾜﾛﾀｗ
213:デフォルトの名無しさん
07/08/19 20:10:54
>>211
糞スレ立てるな
214:209
07/08/19 20:21:58
>>212-213
何も成果物を作れないかもしれませんが、
気長に見てやってください。
スレ違い及び売名行為失礼しました。
逝ってきます。
215:デフォルトの名無しさん
07/08/20 18:32:13
酷いスレだな
216:デフォルトの名無しさん
07/08/25 12:46:57
・変数スコープをなくし、全てグローバルとする。
スコープとはいわば開発者に脳内スタックの確保を一段
強要する機能であり、開発の邪魔である。
変数は全て設計者が関数一覧表とそれに付随する変数一覧表にて管理する。
ローカルだからと適当に変数を作り捨てるようなことをするから
ゴミ変数が増え、バグとなる。
・ポインタの廃止。ポインタは労多くして功少なしの典型機能。
・キーワードを全て大文字化する。小文字は小さく目に悪い。
217:デフォルトの名無しさん
07/08/25 12:48:11
全部ボツ
218:デフォルトの名無しさん
07/08/25 15:13:41
>>216
COBOL でも弄ってろ無能。
219:デフォルトの名無しさん
07/08/26 17:08:28
>>216
要約するとガベージコレクションを付けろってことだな
220:デフォルトの名無しさん
07/08/27 02:45:42
>>216
異論の余地がないほど同意
ｃなんかよりBASICのほうが1億光年優れてるよな
221:デフォルトの名無しさん
07/08/27 18:09:12
>>220
>異論の余地がないほど同意
本人だからか？
222:デフォルトの名無しさん
07/09/06 17:28:11
小学校でローマ字を習うまでは大文字しか読めなかったから
BASICはできてもCはできなかった
223:デフォルトの名無しさん
07/09/06 17:39:30
自分は小学校でローマ字を習う以前に公文で英語やってたから小文字も読めた
でもプログラミングはやってなかった
つかPC自体が珍しい時代だった
224:デフォルトの名無しさん
07/09/20 10:00:55
C言語にGCとデリゲートとコルーチンっていうか、ファイバーっていうんだっけ？中断できるやつ。があれば割とすごいことになりそうな感じ。
あ、あとエクスポート可能なテンプレートかジェネリックスもね。
はっきり言ってクラスはなくても何とかなる。thisコールが結構べんりっちゃーべんりだけど。
225:デフォルトの名無しさん
07/09/20 10:25:33
>>216
ローカル変数は無いと再帰処理が出来なくて悲惨だぞ。その再帰も深くなるとばぐっちゃうけどね。
ポインタはローレベル叩くとき必要だけど、普段はあんまり恩恵ないな。イテレータにしても実用上は問題ないかもね。
キーワードは、色つきエディタ使えば解決。え！？もってないの？？？VCが無料だって言うのに。
226:デフォルトの名無しさん
07/09/20 11:41:51
>>216
int i; とかをグローバルにする知り合いがいたんだが、
void g(void) {
for (i = 0; i < Y; i++) 何かする;
}
void f(void) {
for (i = 0; i < X; i++) g();
}
みたいなことやってバグってハマってたな
227:デフォルトの名無しさん
07/09/20 13:09:15
>>216
異論の余地がないほど同意
ｃなんかよりBASICのほうが1億光年優れてるよな
228:デフォルトの名無しさん
07/09/20 13:22:00
同意するなら異論に反論してからにすれば
229:デフォルトの名無しさん
07/09/20 14:06:23
B A S I C
230:デフォルトの名無しさん
07/09/20 15:20:03
俺の専ブラが>>216をグロ判定したんだけど
231:デフォルトの名無しさん
07/09/20 22:53:59
暇があったら俺のじゃんけんプログラム倒してくれ。
＊N８８互換BASICを使っている人・・・・
ｽﾚﾘﾝｸ(tech板)l50 の 24 参照
232:デフォルトの名無しさん
07/09/21 18:11:30
タートルグラフィックを準標準に入れてくれないかねぇ。
任意で実装って感じでさ。
あれこそ、コンピュータグラフィックスだよ。
233:デフォルトの名無しさん
07/09/23 21:37:44
ただのタートルグラフィックじゃだめだな。
3次元に拡張して、タートルがグリグリ動く奴でヨロ。
234:デフォルトの名無しさん
07/12/24 02:30:36
よし、ゲーム向け言語
#include<game.h>
int main()
{
CreateGame(CG_SHOOTING)
return 0;
}
これでシューティングゲームができる言語を作ってみそ
235:デフォルトの名無しさん
08/01/27 17:24:03
無理だろうけど
#iconfile iconfilename
と書くと作成される実行ファイルにiconfilenameで指定したアイコンファイルが関連付けられる機能
236:デフォルトの名無しさん
08/01/28 18:42:16
break+数字で複数のループを抜ける。
while(1) { /* ループ１ */
while(1) { /* ループ２ */
break2;
}
}
237:デフォルトの名無しさん
08/01/28 18:45:05
gotoでいいじゃん。
238:デフォルトの名無しさん
08/01/28 19:09:53
>>236
ＵＷＳＣで使えるけど便利だよね。
あと、forループで規定回数で抜けるのと途中で抜けるのとをスイッチするオプションがあれば・・・
あ、普通にフラグとスイッチ使えばいっか。
239:デフォルトの名無しさん
08/01/28 21:36:08
>>236
数字はやだ、ラベルにしてくれ。
Loop:
while(1) { /* ループ１ */
while(1) { /* ループ２ */
break Loop;
}
}
240:デフォルトの名無しさん
08/01/28 21:37:48
それ gotoって言うんだよ
241:デフォルトの名無しさん
08/01/28 22:57:11
そんなこと言い出したから、while だって、if + goto なわけだが。
242:デフォルトの名無しさん
08/01/29 17:27:37
>>239
まんまD言語な件。いや、Javaでもあったかな。
243:デフォルトの名無しさん
08/02/17 19:38:46
int main(int argc, char *argv[]) {
switch(VersionComparison(argv[1], argv[2])) {
case 1:
printf("%sの方がバージョンが新しいです｡\n", argv[1]);
break;
case 2:
printf("%sの方がバージョンが新しいです｡\n", argv[2]);
break;
default:
printf("%s, %sのいずれもバージョン情報を含んでおりません｡\n", argv[1], argv[2]);
break;
}
return 0;
}
244:デフォルトの名無しさん
08/04/09 20:32:13
あげもかねてＣ言語ネタ投稿 実際にはコンパイルできないソースファイル
#include "Windows.h"
extern "C" __declspec (dllexport) int isosmode(void);
int _tmain() {
switch(isosmode()) {
csae 0:
MessageBox(NULL, "現在のモードは、アドバンスモードです｡", "モード判定", MB_ICONINFORMATION);
break;
case 1:
MessageBox(NULL, "現在のモードは、セーフモードです｡", "モード判定", MB_ICONINFORMATION);
break;
case 2:
MessageBox(NULL, "現在のモードは、デバックモードです｡", "モード判定", MB_ICONINFORMATION);
break;
default:
MessageBox(NULL, "CHKMODE.DLLは存在しません｡", "ファイルの欠落によるエラー", MB_STOP);
break;
}
MessageBox(NULL, "なんちゃって、isosmode()もCHKMODE.DLLも実際には存在しません｡", "注意", MB_ICONINFORMATION);
return 0;
}
245:デフォルトの名無しさん
08/04/09 20:36:34
printf("私は弱者を愛し、守っていきます。");
紳士言語
246:デフォルトの名無しさん
08/04/09 21:05:21
>>245
ここではスレ違いの内容だよ
そういう書き込みは“適当に作ったC言語の関数を貼っていくスレ”の方で。
247:デフォルトの名無しさん
08/06/19 18:33:34
>>225
関数の引数を増やしてそれをローカル変数代りにすればOK。
216が関数の引数もなくせ、と言っているなら知らんが...。
248:デフォルトの名無しさん
08/06/19 21:27:03
>>241
if + goto + goto だと思うが。
249:デフォルトの名無しさん
08/06/19 21:52:07
>>248
大抵のコンパイラは
goto L1
L2:
...
if(...) goto L2
に展開するから、goto + if + goto が正しいな。
って言うか、５ヵ月近く前のレスにレスするほどの内容か？
250:>>249
08/06/19 21:53:13
ラベル付け忘れた... orz
goto L1
L2:
...
L1:
if(...) goto L2
251:デフォルトの名無しさん
08/06/20 22:40:22
>>249
どうしてもレスつけたかったんです、勘弁してください。
252:デフォルトの名無しさん
08/07/24 01:36:50
>>1
やる気があるなら、予約語を全部排除して、
全部自前で定義できるようにしてくれ。
そういう仕様なら乗ってやる。
253:デフォルトの名無しさん
09/01/29 00:57:56
>>252
予約語を自前で定義して何の得があるんだよｗｗｗｗｗ
254:デフォルトの名無しさん
09/01/29 01:56:38
>>252
PL/I思い出した
255:デフォルトの名無しさん
09/01/30 21:43:19
>>252
俺様専用の俺言語が定義できる。
256:デフォルトの名無しさん
09/01/30 23:44:01
schemeでいいよ
257:デフォルトの名無しさん
09/01/30 23:47:48
D言語でいいよ
258:デフォルトの名無しさん
09/02/01 05:23:02
boolは欲しいな。あれ、追加されてたんだっけか。
あと、複素数型とか、HLSLみたいにベクトル扱いやすくする機能も欲しい。
数値計算に特化すれば需要あるんじゃね？
259:デフォルトの名無しさん
09/02/01 05:48:44
そんなのよりステータスレジスタを抽象化して見れるようにしてほしい
わざわざアセンブラで書く手間を減らすために
260:デフォルトの名無しさん
09/02/01 07:48:44
>258
_Bool と _Complex は C99 で追加されている。
261:デフォルトの名無しさん
09/02/01 11:35:51
>>259 無いプロセッサはどうすんだよw
262:デフォルトの名無しさん
09/02/03 22:31:14
URLﾘﾝｸ(d.hatena.ne.jp)
こんなのもあるんだな
1つ目のリンクは切れてるみたいだけど
263:デフォルトの名無しさん
09/02/03 22:47:48
Ｃ++のように無秩序に機能を増やすのではなく、
Cの良さを守りつつ、Cと同じ次元でより使いやすいCを作りたい。
名づけてC+
・オブジェクト指向（クラスその他）は導入せず。
・当然ガベコレなんてついてない。
・標準関数ライブラリは古くなってしまったので全面改訂。
・文字列を扱うstring型の追加。文字列の扱いに関しては全面強化。
・配列・ポインタは当然維持。ただし分かりにくい構文は改訂する。
（配列は int[] array; のように宣言を行うようにする。ポインタも long* x, y; だと*は型名に付いているとする。）
・malloc関数, free関数のキーワード昇格。
・namespace導入。
・ヘッダファイルは不要に。関数プロトタイプ宣言不要。
264:デフォルトの名無しさん
09/02/03 23:27:09
> 名づけてC+
+ は単項演算子じゃないから文法エラーとか
265:デフォルトの名無しさん
09/02/04 02:01:50
互換性は捨てるのね…。
266:デフォルトの名無しさん
09/02/04 12:20:40
>>263
>・当然ガベコレなんてついてない。
けど
>・文字列を扱うstring型の追加。
なのか。遅そうだな。
267:デフォルトの名無しさん
09/02/04 21:58:46
>263
なんかCycloneのサブセットな気が。
268:デフォルトの名無しさん
09/02/15 10:30:52
cycloneってこれ？
URLﾘﾝｸ(cyclone.thelanguage.org)
269:デフォルトの名無しさん
09/02/15 13:36:48
GCと境界チェックさえつけてくれればおｋ
270:デフォルトの名無しさん
09/03/03 01:54:47
>>263 に型周りの強化(強力な型推論、総称型)が入れば十分かなと思う。
271:デフォルトの名無しさん
09/03/03 09:57:34
いろんな言語混在できる言語で。
272:デフォルトの名無しさん
09/03/03 20:25:41
いろいろつけるから、ごちゃごちゃして、使いづらくバグの温床になる。
いっそのこと、ばっさり機能を削ぎ落とすのがよろしい。でも低レベルな操作は行いたい。
というわけで、新仕様を次のようにする。
--
void main()
{
asm文の繰り返しのみ;
}
--
以上。変数も条件文もgoto文も制御構造も何も無いので、覚えやすい。
273:デフォルトの名無しさん
09/03/03 22:51:49
null終端文字列じゃなくて、文字数で管理するようにしようぜ
いや現状のCでも文字数で管理は可能だけど、標準ライブラリがnull終端前提じゃん
274:>>249
09/03/03 23:16:41
標準ライブラリ以前に、文字列定数が文字数で管理するような形になら
ないから、現状のＣでそういうことやるのは激しく困難だと思う。
275:デフォルトの名無しさん
09/03/04 11:56:02
>>273
Pascalでよくね？
276:デフォルトの名無しさん
09/03/04 12:04:03
>>272
各種ジャンプがあるだろ。
277:デフォルトの名無しさん
09/03/04 21:56:44
perlのコードが混ざっててもエラーにならないように作ってくれ
278:デフォルトの名無しさん
09/03/05 00:24:05
>>273
pascal キーワードを導入すればいい。
string cstr = "This is a C string." ; // ヌル終端の標準C文字列型
pascal string pastr = P"This is a Pascal string."; // 先頭がバイト数のPascal文字列型
279:デフォルトの名無しさん
09/03/05 01:22:45
いっそのことコンパイラ作りに特化した仕様にしちゃえYO
その後は各自自分仕様の言語を作ると
280:デフォルトの名無しさん
09/03/05 01:41:25
これからの時代は予約語オーバーロードですよ
281:デフォルトの名無しさん
09/03/05 19:05:08
>>280
それは凶悪すぎるだろうｗｗ
282:デフォルトの名無しさん
09/03/05 20:34:09
C#からもってこれそうなのある？
283:デフォルトの名無しさん
09/03/06 01:17:52
予約語オーバーロード
284:デフォルトの名無しさん
09/03/06 04:22:43
組み込み型に対する演算子オーバーロード
285:デフォルトの名無しさん
09/03/09 11:45:37
匿名メソッド (関数ポインタ)
286:デフォルトの名無しさん
09/03/10 23:55:37
型水路
287:デフォルトの名無しさん
09/03/11 14:03:58
CMカット
288:デフォルトの名無しさん
09/03/11 16:23:26
既存のCのソースを利用したりCへ必ず変換できる言語にしたい。
文法はCと非互換でよい。
現状のマクロをなんとかしたい。
短い記述で濃い内容を書きたい。
289:デフォルトの名無しさん
09/03/11 16:25:42
スクリプトっぽく書けるようにしたい。
グローバルに
puts("hoge");
って書けば
int main(){
puts("hoge");
}
と同じ意味にしたい。
290:デフォルトの名無しさん
09/03/11 16:28:34
do-whileって判定を後ろに書くのが人気無いよね。
前に書けるようにするか。
他言語ではbefore until after untilの構文どうなってるかな。
291:デフォルトの名無しさん
09/03/11 16:31:05
for(int i=0;i<n;++i)
は定型化してるから、もっと単純化できる。
いい構文ある？
292:デフォルトの名無しさん
09/03/11 16:34:28
JavaScriptっぽく;(セミコロン)の省略できたっていいよな。
Pythonっぽくインデントでブロック作れてもいいよな。
いずれも問題点や文句言う奴がいるがうまく丸く収まんないかな。
293:デフォルトの名無しさん
09/03/11 16:41:24
>>285
qsort,signalなんかで使えたらうれしいよね。
294:デフォルトの名無しさん
09/03/11 17:38:55
GCとかの実行時のサポートに頼らない範囲で、出来る限り高水準な言語を作るというのが面白そう
強力な型システムやメタプログラミング能力を用意して、少なくとも無名関数くらいはGCのある言語に近い気楽さで書けるように
一番の問題はたぶんメモリ管理だけど、線形型を使ってなんとかできないだろうか
295:デフォルトの名無しさん
09/03/14 01:08:44
>>283
予約語オーバーライドができる言語なら知ってるんだが
296:デフォルトの名無しさん
09/03/14 04:46:04
#define ですね、わかります
297:デフォルトの名無しさん
09/03/14 04:49:47
#define内で#defineや#ifとかが使えればいいのに
298:デフォルトの名無しさん
09/04/16 00:38:30
そうかなあ
299:デフォルトの名無しさん
09/05/31 20:27:15
いろんなとこから仕様はいただいて、テキトーに短くしたらこうなった
c/Hello{
static v/main(str[] args) >> pub{
printw("Hello,World!");
}
}
300:デフォルトの名無しさん
09/06/04 18:49:17
いじくるつくーるなら for(0,i<n) { (命令文) }; という構文がある。
たぶんＣ言語では無理。
301:デフォルトの名無しさん
09/06/04 21:57:33
D言語ならforeach(i;0..n)でおk
302:デフォルトの名無しさん
09/06/04 22:00:26
指定したハンドルのレジストリキーに関する情報をlpc構造体に渡すRegQueryInfoKey
LPC lpc;
char n[100];
RegQueryInfoKey(HKEY_CLASSES_ROOT, lpc);
wsprintf(n, "HKEY_CLASSES_ROOTの１つ下には%i個のサブキーがあります。", lpc.Subkeys);
MessageBox(NULL, n, "関数RegQueryInfoKey", MB_OK);
303:デフォルトの名無しさん
09/06/18 22:48:47
というかOSがかける程度に強力であり、
かつ高尚で可読性に優れたものが書けるならいうことなしだ
そうするとおもいっきりModula-2になるわけだが。
だからあのｷﾓｲbegin～end構文を｛～｝の構文にして、
コンパイラの実装がしやすく、またプログラミング初心者も覚えやすいような
簡潔な文法があればいい。
あとこれは個人的意見だけど、できるだけソースコードは短く書けたほうがいい。
じぶんのキーボードの打ち方が間違ってるのだろうけど、腱鞘炎になりかけたことがあるから。
304:303
09/06/19 18:52:46
>>291
ちなみにこれについてちょいと思い付いたので書いておく。
型宣言した時点でその型の初期値に初期化されるとして…
for((int i)++ < 5){
//....
}
305:デフォルトの名無しさん
09/06/19 22:13:54
Inferno って OS で使われてる limboo はどう?
306:デフォルトの名無しさん
09/06/20 21:50:33
>>305
後でちょいと調べてみる。
ついでに>>236>>239について思いついたので書いておく。
nest(1)://"nest"とは入れ子という意味。
while(..){
nest(2):
while(..){
break(1);//nest(1)のループを抜ける
}
}
307:303 ◆pFphp4Ej4w
09/06/24 19:28:40
>>278
これについては、
C言語文字列
nullStr
Pascal文字列
byteStr
とすればいい。
この用途のみでPascalキーワードが存在するのは許せない。
あと、306は私だ。
308:303 ◆pFphp4Ej4w
09/06/29 08:17:32
取りあえず考えてみた。
１.変数宣言
変数宣言はC言語のそれとは全く逆。
例)x int;
これは英語の文法にあわせて読みやすくしたため。
２.ポインタ
ポインタは次のように宣言。
例)p: point(int);
or
p: int:;
続きは家に帰ってから。
309:303 ◆pFphp4Ej4w
09/06/30 08:05:49
３.代入演算子
代入演算子には
:=
を使用する。
例)
a int:=5;
３.比較演算子
比較演算子には
=
を使用する。
例)
if(x=0){
...
}
310:デフォルトの名無しさん
09/06/30 23:13:46
C言語への不満ってそういうところじゃねーと思うが。
例えば実行時のコンテキストとソースコード上のlexicalなコンテキストが同一で
あるところとかそういうモデルな部分に革新が必要なんじゃないか？
読みやすさも大事だと思うがそういうのはおれスクリプト言語でやってればよし。
311:303 ◆pFphp4Ej4w
09/07/01 07:45:40
>>310
なるほどねぇ…
確かにそうかもしれない。
その抜本的な改革についてちょっと考えてみるよ。
それと、ポインタ型の宣言について、
p: point(int);
よりも
p point(int);
こっちの方がいいかな？
ただこうするとpがポインタ型と言うことが分かりにくくなってミスが増えるかも。
312:303 ◆pFphp4Ej4w
09/07/01 08:18:08
あと一つ質問。
匿名メソッドは必要かね？と言うかデリゲートは必要か？
313:デフォルトの名無しさん
09/07/01 13:13:15
今からなら新C言語はC言語をベースにするよりD言語からクラス抜いたものをベースにした方が良いと思われ。それにビットフィールドとかC99とかgccの拡張部分とか足してきゃいいよ。
ポインタの実体化はDelphiのがいい。
関数の戻り値の型の書き方はC++0xやEMACScript4で提案されているような後置も特殊化用引数(テンプレート/ジェネリックパラメタ)を戻り値の型より前に持ってくるという点で一理あるが、読みやすさという点では従来の方が高い。まぁ難しい所だね。
314:303 ◆pFphp4Ej4w
09/07/01 16:16:39
>>313
わし的には、
ベースはC言語
クラス、インタフェース、また必要であればデリゲートなどの匿名メソッドの導入(個人的にアレは嫌いだ)
強力な型推論の導入
メモリ管理にはガベージコレクタは用いず、malloc/new･free/delete演算子を使用
ポインタは廃止しない(廃止すると複雑なデータ構造がつくれなくなる。)
文法の抜本的な変更
nullchar/bytechar型の導入
を考えていたのだが…(ついでに名前はシーキューブ。C3またはCqbと書く)
D言語かぁ…
それもありだね。
そしたら名前はD++かな？
315:デフォルトの名無しさん
09/07/01 16:48:50
>>314
D言語は
-class、interface、delegate全てある
-変数初期化時・関数の戻り値の型推論がある
-ポインタも当然ある。
-invariant(char)* (C言語の文字列)とinvariant(char)[] (Pascalの文字列)がある
まぁ違う所は
-メモリ管理はGC基本でマニュアル管理はカスタムアロケータがある
-文法はC言語由来が多い。
って所か。
316:303 ◆pFphp4Ej4w
09/07/01 18:28:42
>>315
となるとD言語からGCを取り外しただけの言語になるわな。
なんか「これがほしい！」って言うのはないの？
317:デフォルトの名無しさん
09/07/01 18:52:26
D言語は細かい所がなおざりだから、改善すべき点は文法も含め多いと思うよ。
318:303 ◆pFphp4Ej4w
09/07/04 20:53:44
そういえば、マクロのこと書きそびれてた。
マクロは#～で定義され複数行をサポートする。
例)
#hoge
...
#hoge end
319:デフォルトの名無しさん
09/07/12 23:56:48
303 はもういないの？
320:303 ◆pFphp4Ej4w
09/07/13 18:50:34
ごめん。この間まで期末テストで今は風邪でダウン中。
321:303 ◆pFphp4Ej4w
09/07/13 21:45:52
追記:
明日から4日ぐらいはずっと学校が休みなのでこのスレに張り付いていられると思います。
322:デフォルトの名無しさん
09/07/14 00:21:22
とりあえず現状どうなってんのか、まとめみたいなのがほしいかな
323:デフォルトの名無しさん
09/07/14 05:29:59
構文変えるなら利点と欠点まとめてほしい。
忘れないで欲しいのが、パーサによる解析しやすさ、IDEによる入力支援の効きやすさ、他人による読みやすさ、データの流れの追いやすさ、書きやすさ。
324:デフォルトの名無しさん
09/07/14 12:29:10
>パーサによる解析しやすさ
こんなこと考えるから C の宣言は判り難くなったんだ。
325:303 ◆pFphp4Ej4w
09/07/14 16:17:01
>>322
了解です。今から書きます。
>>323
>>303でも書いたように
> コンパイラの実装がしやすい
言語にしたいと思ってはいるのでできれば解析はしやすくしたいと思っています。
しかし>>324さんが述べているように構文の読みやすさ、書きやすさなんかを
犠牲にするのはちょっとカンベン･･･
というわけでもしかしたらその点は犠牲になる可能性があります。
とりあえず今のところ(私の中で)決まっている言語仕様:
1.変数宣言
変数は次のようにして宣言される
x int;
利点:英語に従った文法なので初心者が読みやすくなる。
欠点:Cに慣れた人は確実に間違えてエラーを多発させる要因になる。
2.クラス・関数の定義
クラス・関数は次のようにして定義
c/hoge{
void hogehoge(){
...
}
}
クラスに内包されない関数も定義可能。
void hoge(){
...
}
int hogehoge(){
...
}
続く
326:303 ◆pFphp4Ej4w
09/07/14 17:06:23
続き
利点:c/～とやると若干短くなる。
欠点:c/～じゃ最初見た人は何かと思うかもしれない。
また実行時に実行される関数は
int main(){
...
returrn 0;
}
でOK。
3.演算子について
代入演算子
:=
比較演算子
=
!=
<
>
<=
>=
とする。(代入演算子にほんとうは<=を使いたいのだがこれじゃ間違える人が続出すると思うので今のところはこれで。今後変更の可能性大。)
利点:"==”は比較演算子ではないのでで初心者のミスが減る(一人よがりかなぁ？)
欠点:確実に間違えられる。
今日のところはここまで。
327:デフォルトの名無しさん
09/07/14 18:58:54
int foo[][] vs. int[][] fooな論争があるが、foo int[][] (foo is int of array of array)にしちゃうのかぁ。パーサに先読みが必要になるのでかなり速度が低下するのと、IDEの補完的にマイナス…いやこれは既に定義された名前を避けるという意味では問題ないか。
クラス定義は、"c/"を識別子にするってことかな。そうだとすると変数でcを宣言した場合に厄介なことになる。識別子にしないとなるとlexerで分離できないので速度が低下する。
演算子についてはDelphi的なので言うことは無いかな。
328:デフォルトの名無しさん
09/07/14 19:08:55
それと、識別子に使える記号の数は少ないので、アルファベット+記号を識別子にすること自体は賛成かな。
329:303 ◆pFphp4Ej4w
09/07/14 19:41:05
追記:
これはやだ･これを追加しろ･この構文はやだ等ご意見があればご自由に。
と書こうと思っていたら>>327さんがもう書いていらっしゃいました。素早い…
それはさておき、ご意見ありがとうございます。
パーサの速度にしたがってコンパイル速度も落ちるので、これは重大な問題です。しかもこれを解消するには構文を捨てないといけないという…
これについては今後なるべく早く議論して解決策を決定すべきでしょう。(この過疎スレで人が集まるかどうか…)
解決策の一つとしてはこの言語のみに特化したパーサを開発することですが、これじゃ焼け石に水です。
どうしましょうかねぇ…
330:デフォルトの名無しさん
09/07/14 19:45:55
幾つか意見を言わせて貰うね。
----
"c/" は、俺は否定的。
"c" + "/" として扱っても、"c/" としてまとめて扱っても、どちらにせよ 『 b := c/a; 』 が書きにくくなる。
トップレベルに書いた "c/" のみを特別扱いすれば問題ないとは思うけど、CP が悪いわな。
そんなに 100 も 200 もクラス定義するわけじゃないんだから、得られるものは少ないと思うよ。
----
変数宣言と関数宣言の型指定が正反対なのが気になるところ。
変数にあわせるならば 『 hoge() void { ～ } 』 になるんじゃないかな。
C に慣れたひとも、VB or Pascal に慣れた人も、どちらも間違えると思うよ。
どちらかに統一すべきだと思う。
----
代入演算子、"<-" を使ってみたらどうかな。打ちにくいけど。
----
比較演算子で気になるのは、= と != の文字数が違うところかな。
細かいことだけど。
331:303 ◆pFphp4Ej4w
09/07/14 19:50:44
追記:
>>329というわけでこの過疎スレに議論のために人を呼び込まねばなりません。ですから、これからはage進行で行きましょう。
ってなわけでage!
332:303 ◆pFphp4Ej4w
09/07/14 19:57:26
>>330
すびません、リロードし忘れてましたorz
いま外出中で携帯から書き込んでるので家に帰りつくまでお待ちください。
333:デフォルトの名無しさん
09/07/14 20:16:45
>代入演算子、"<-"
a<-5とかそれなりに使う気がするので止めてほしい。
:=も条件演算子との兼ね合いで(識別子として扱えば問題は無いものの)読みにくくなりそう。
334:デフォルトの名無しさん
09/07/14 20:18:42
個人的な案。
c -> newC
= :=
== = or !!=
!= !=
< < or !>=
<= <= or !>
> > or !<=
>= >= or !<
要は、!に否定と言う意味を持たせるなら演算子そのものも否定できたらどうかな、と。
# !の多重を認め出すと、!!!!!!!!!!=なんて書けてしまうのは実は問題かもしれないw
335:334
09/07/14 20:21:18
失礼。醜かったので書き直し。
--
c → newC
= → :=
== → = or !!=
!= → !=
< → < or !>=
<= → <= or !>
> → > or !<=
>= → >= or !<
336:デフォルトの名無しさん
09/07/14 20:22:21
>>334
D言語には!>=とか普通にあるが<とは意味が違う(浮動小数点のNAN的な意味で)。
337:336
09/07/14 20:25:50
これな。
URLﾘﾝｸ(www.digitalmars.com)
<>とか<>=とか!<>=とかもある
338:303 ◆pFphp4Ej4w
09/07/14 20:46:16
今家に帰り着きました。
･･･つついてみれば意外と人がいるもんですね。
>>330
については、そこまで頭回ってなかった私の問題です。申し訳ない。
というわけで改訂版。
2.クラス・関数の定義
クラス・関数は次のようにして定義
c/hoge{
hogehoge void(){
...
}
}
クラスに内包されない関数も定義可能。
hoge void(){
...
}
hogehoge int(){
...
}
あと"c/"について。
そうですか･･･。やっぱりclass{...}にしたほうがいいですかね？
ここは議論の余地があるようです。
>>334さんのは全面採用したいですね･･･
まぁ"!"は2文字以下でという限定をつければいいと思うので。
339:デフォルトの名無しさん
09/07/14 20:51:10
>>338
hoge int() { ... }
って表記はどうなのかな。
変数宣言と合わせると LALR なら問題ないだろうけど、LL なら 3 くらいは欲しいよね。
340:303 ◆pFphp4Ej4w
09/07/14 21:42:41
>>339
なんだか考えるべきことが大量に増えてきましたね…
私はそろそろ寝たいと思います。(風邪も治したいので。)では、おやすみなさい。
341:デフォルトの名無しさん
09/07/14 22:02:02
>>1
C++の何が不満なのかまず説明してくれ
それが説明出来ないなら議論する価値もない
342:デフォルトの名無しさん
09/07/14 22:50:14
a = a + b を a += b と書けるように、
別の書き方をしたら記述量が減るなら意味があるけど、
>>334 みたいなのにどういう利点があるのかいまいちわからない。
343:デフォルトの名無しさん
09/07/14 22:54:15
まあでも代入と比較が:=と=なのは趣味の問題、別に構わないと思う。
Cっぽくない構文の言語なら珍しくはない。
344:デフォルトの名無しさん
09/07/15 01:43:31
ちょっと視野が狭すぎやしないか？
その程度の違いならC言語でいいじゃんと思ってしまう。
参考までに303 ◆pFphp4Ej4wが使えるプログラミング言語は何だい？
345:デフォルトの名無しさん
09/07/15 03:30:46
GNOME 用の C 言語拡張みたい
Valaについて語りませんか
ｽﾚﾘﾝｸ(linux板)
346:303 ◆pFphp4Ej4w
09/07/15 09:11:34
>>344
私が使えるのですか？
ObjectPascal
Java
C言語
C++
D言語は現在勉強中。
347:デフォルトの名無しさん
09/07/15 21:09:58
>>341
たしかにそこは聞きたいな。C++でなくてもいいけど。
今あるCの後継的な雰囲気の言語のどこがまずいと考えていて、
どう直そうとしているのか。それによって何が良くなるのか。
誰（言語ユーザ、コンパイラ制作者、ライブラリ制作者、IDE、etc）が得するのかなどなど……。
348:デフォルトの名無しさん
09/07/15 21:26:49
代入演算子変えるなら、もはや「新C言語」じゃないのでは？
349:303 ◆pFphp4Ej4w
09/07/15 22:01:26
>>348
それいっちゃオシマイです…
それと、>>305についていまさらながら調べてみました。
LimbooというのはC言語の作者が設計したPascalライクなC言語のようです。
やはりC言語をつくった人にも思うとこがあったのですかねぇ…
350:デフォルトの名無しさん
09/07/15 22:25:00
演算子なんてjavascript程度が用意してるので十分だと思うんだよね。
そんなに既存のcやその他追随してる言語に不都合な点があるのかな。
351:デフォルトの名無しさん
09/07/15 22:28:42
>>350
Perlまで増やせとは言わんが、ECMAScript 3程度じゃ全然足りん。
352:デフォルトの名無しさん
09/07/15 22:33:24
演算子いらね, 結局 (+ x y) の 2 引数関数じゃん
353:デフォルトの名無しさん
09/07/15 22:36:33
もっと三項演算子を増やせとな?
354:デフォルトの名無しさん
09/07/15 22:39:24
宣言以外の文を無くして全部式にしようぜ
355:303 ◆pFphp4Ej4w
09/07/15 23:18:57
>>354
それじゃ関数型言語そっくりに…
どうもわたしは規制に巻き込まれたようです。
何もしてないんだけどな…
こういうもんなんですかね？
356:デフォルトの名無しさん
09/07/15 23:25:40
そういうもんです。
ぶっちゃけ、既存の言語を超えようとしたり、改善しようとしたりするのが間違ってると思う。
自分が作りたいものを作りたいように作ればいいんじゃないかな。俺はそれで満足する。
357:デフォルトの名無しさん
09/07/15 23:35:13
>>356
目的が自分が満足するためならそれでいいのだろうけど。
358:303 ◆pFphp4Ej4w
09/07/15 23:56:47
>>356
確かに。それの見本がC++ですね。
359:デフォルトの名無しさん
09/07/16 06:25:30
>>349
LimbooじゃなくてLimboだよ。w
Limbo は並行計算が目玉と思われ。Erlangよりずっと分かりやすい。
C言語の悪評極まる宣言についてはリッチー先生さすがに反省したようで
Pascal風に直してあるね。
Limboに先行してAlefという言語もある。
360:303 ◆pFphp4Ej4w
09/07/16 10:25:19
>>359
すいません。おっちょこちょいなもんで…
361:303 ◆pFphp4Ej4w
09/07/17 22:43:22
なんか規制解除されてるかわかんないので携帯から書き込みます。
４.基本構文
４.１for構文
for構文とは指定した回数だけその命令を繰り返す構文である。
for構文は次のように定義する。
(とりあえず3回繰り返す場合。)
for((i int)++ < 3){
...
}
362:303 ◆pFphp4Ej4w
09/07/17 22:47:18
>>361
ま、間違えた…
４じゃなくて３だった…
あと、言いそびれてましたが変数は定義したときにその変数の初期値に初期化されます。
363:デフォルトの名無しさん
09/07/17 23:02:05
指定した回数繰り返すと言うのなら、<演算子を使う必要はないのでは？
<が出て来るということは、今のCのforみたいにwhileのような自由な条件指定を許すように思える。
それなのに、361の文章では、「指定した回数繰り返す」と言い切っている点が気になる。
単に、今のCのforみたいに、主に指定回数の繰り返しに使われるというのなら理解できるけど。
364:363
09/07/17 23:05:40
例えば、BasicのFor i = 0 To 2やRubyの3.timesなんかが
比較演算子を使わずに繰り返しの構文を実現している。
（もちろん、どっちもwhileが別にある）
365:デフォルトの名無しさん
09/07/17 23:11:08
MATLABの構文もそんな感じだったな
for i = 1 : 1 :10
1ずつ増やしながら1～10まで繰り返すみたいな
366:デフォルトの名無しさん
09/07/17 23:13:17
fortranっぽい配列使えるようにしてくれ
367:303 ◆pFphp4Ej4w
09/07/17 23:31:12
>>363
ぬわぁ…
すみません。
毎回毎回勉強になるなぁ…
とりあえずここでは「主に指定した回数だけ繰り返される」とします。
これを踏まえて一つ質問を。
ある命令を指定した回数のみ実行するのみの構文は必要でしょうか？
368:デフォルトの名無しさん
09/07/18 00:11:15
どういう方向性か知らないけど、foreachがあればforなんてなくてもなんとかなるよ。Pythonのforがそう。
#リストlsの各要素を順に出力
ls = ["hoge", "foo", "bar"]
for x in ls:
print x
#0から2までを順に出力
for x in xrange(3):
print x
でもまあ、こんなところCのままでいいじゃないと思うけどね。
配列（のようなもの）の各要素に～するって系統の関数を充実させれば、for/foreachの出番なんてぐっと少なくなるし。
369:デフォルトの名無しさん
09/07/18 00:11:39
逆に何でそれがいるのかが聞きたい
370:デフォルトの名無しさん
09/07/18 02:15:20
>>346
やはり似たような言語ばっかりだね。
limboがでてたけど、そんな感じの根本的に違う思想の
言語を一度勉強した方が参考になると思うよ。
特に関数プログラミング系は必須といっていいと思う。
listかschemeは当然だし、また実行効率の良さはMLとその派生も勉強になるものが多い。
C言語の拡張でいうとcycloneとかも見てみるといい。
あれはCの実行効率の良さを維持しつつ型安全性を組み入れてる。
そういうのみるとはっきり言って俺for文とかどうでもいい話に思えるよ。
バカにするつもりはないけどもう少し見聞を広げるべき。
371:デフォルトの名無しさん
09/07/18 02:37:16
・C/C++
・Pascal
・Smalltalk
・Self
・Io
・Lisp, Scheme
・Haskell
・Prolog
・Erlang
・ConcurrentClean
・GHC/KL1
・BrainF*ck, Unlambda
・SKI combinator
これくらい見聞きすれば新しい世界が開けるよ
372:デフォルトの名無しさん
09/07/18 02:50:21
>>371
その中で一つ選ぶならやっぱり Lisp だね。
常用する気にはなれないけど、学ぶ事は多かった。
373:デフォルトの名無しさん
09/07/18 02:56:43
やっぱり並列プログラミングが安全で簡潔に書ける言語がほしいね。
単純なスレッドむき出しじゃないやつで。
374:デフォルトの名無しさん
09/07/18 03:00:23
>>371
D(メタプログラミング・関数乗っ取り対抗策など)とかC#(LINQ)とかCω(スレッド周り)とかECMAScript3/ECMAScript4(プロトタイプ思考)とかJava(命名規則など)とかも必要。
誰か言語の良い所・悪い所をまとめてほしいかも。んで良いとこ取りすればおk。
375:デフォルトの名無しさん
09/07/18 03:05:48
つーかC言語の後継であるなら、OSが書ける、デバドラが書ける、
とかそういうのが目的の言語であってほしい。
なんでもあり言語はPL/Iみたくなってうまくいかないでしょ。
376:デフォルトの名無しさん
09/07/18 03:12:26
>>374
自分は、客観的な各言語の評価よりも、
303自身の主観でのCとその後に続く言語（>>346の中ではC++/Java/Dの）の評価を聞きたいな。
377:デフォルトの名無しさん
09/07/18 05:17:21
>>375
PL/Iが普及しなかった理由はそういうことでは無いけど(MulticsはPL/Iで書かれている)、整理はされてて欲しいね。
378:303 ◆pFphp4Ej4w
09/07/18 07:28:01
>>376
そうですねぇ…
Java
一番最初に使ったオブジェクト指向の言語です。
はっきり言ってしまうとかなりわかりやすく、簡単･便利で初心者に最適な言語だったと思います。
ただ、プログラマのもつ能力に足かせをはかせてるような感じがします。あと、私は結構パフォーマンスを気にするたちなので(ただの貧乏性)VMを使うせいで速度が遅い･メモリを触れないJavaはなんだか性にあいません。
C++
ポインタを理解するまでかなり時間を食いました。(C言語を始める前だった)
Javaだとそこら辺は巧妙にかくされてます。
ただ、C言語のようにプログラマのもつ能力を最大限生かせる点と速度がかなり速い点については最高だと思います。(これでコンパイルが速ければ…)
D言語
まだまだ学んでる途中なので細かいことは言えませんが、C++とJavaを足して2で割ったような言語です。
GCがついている以外に不満な点は特にありません。
つまりまとめちゃうと取りあえず私は、今あるC言語系の構文にこれといった不満をもっていません。
はっきりいうとこれまでだしてきた変数宣言や様々な構文は私が本心から考えているものではありません。ただ初心者に優しいであろうと思うもののみをあげているだけです。
ぶっちゃけJavaみたいに初心者に優しくて、Dみたくコンパイルが速くて、C++みたく柔軟な使い方ができて実行速度が速い言語なら私はそれでいいのです。
379:デフォルトの名無しさん
09/07/18 10:05:40
とりあえず、「新C言語」という名前をやめてほしい。
こういう名前をつければ、スレッドの客寄せにはいいだろうが、
構想はまったくCと違う方向に進んでいる。
世の中で、C言語の改良版が欲しい人たちは、
Cとまったく違う変な構文なんて望んでいないはずだ。
まったく別の名前でまったく別の理念でやってくれ。
380:デフォルトの名無しさん
09/07/18 10:16:35
Ｇ言語
381:デフォルトの名無しさん
09/07/18 10:51:15
新C言語としてOCamlを開発すればよい
382:デフォルトの名無しさん
09/07/18 12:23:13
>>380
自慰言語ですね。わかります
383:デフォルトの名無しさん
09/07/18 12:42:19
コンパイル速度まで評価対象になるのなら、実装方法もコミで考えてかないと。
単にこんな機能が欲しい！だけじゃダメだろ。
384:デフォルトの名無しさん
09/07/18 12:47:25
つーか、Cでのちょっとした不満とか良くないところの改善っていう目的を忘れたらあかん。
385:デフォルトの名無しさん
09/07/18 18:45:24
コンパイラ屋さんの俺が来ましたよ。
専門は最適化なのでそっちしか興味ないんだけど、簡単なCへのトランスレータくらいだったら作ってみようかな～
386:303 ◆pFphp4Ej4w
09/07/18 20:27:00
>>384
ってなわけでじゃんじゃかC言語の悪いところを書き出してってください
>>385
ぜひともお願いします(まだ言語仕様さえも決まってませんが･･･)
387:デフォルトの名無しさん
09/07/18 20:41:33
とりあえず文法を FIX しよう。話はそれからだ。
388:デフォルトの名無しさん
09/07/18 20:43:12
あと、名称も FIX しないとね。
389:デフォルトの名無しさん
09/07/18 21:00:07
はじめてきたんだけど
ちょっとここまでの進捗を3行でまとめて
390:デフォルトの名無しさん
09/07/18 21:02:45
す
す
んでない
391:385
09/07/18 21:17:44
>>386
とりあえずただＣをパースしてＣを吐くだけのやつを明日作ってみようか。でそのパーサなり何なりをいじって文法を修正していくと。
言語ががらっと変わるなら仕様を先に練る必要があるけど
392:デフォルトの名無しさん
09/07/18 21:24:31
進んでないのか
また来るね
ヘッダファイルを編集するだけの簡単なお仕事です
393:303 ◆pFphp4Ej4w
09/07/18 23:43:39
>>391
どうもありがとうございます。よろしくお願いします。
明日は模試があるので顔をだせないかもしれませんが…
394:デフォルトの名無しさん
09/07/19 00:45:11
Java に乗っけたいね。JSR223 対応させて。
けど 303 にその気が無いようで残念。
395:デフォルトの名無しさん
09/07/19 00:47:10
Javaにのせたい気持ちがわからない
396:デフォルトの名無しさん
09/07/19 01:23:40
わかんない？
そいつは残念だ。
397:デフォルトの名無しさん
09/07/19 01:26:42
それはC言語の役割ではない
398:デフォルトの名無しさん
09/07/19 01:49:26
むしろJavaScriptで作ってブラウザ上に、というほうがまだ分かる。
それはともかく、やりたい人間が自分で作ればいいじゃないか、JRubyのように。
399:394
09/07/19 02:03:01
いや、作る気が無いわけじゃないんだけど、
ポインタをサポートするなら JVM の上にさらに独自の VM 乗せることになって
そこまですることになるなら俺の能力を超えるなぁ、って考えていたところ。
Java じゃなくて、JavaScript でも似たようなことが起きるはず。
400:デフォルトの名無しさん
09/07/19 03:21:48
Cくらい軽量で低水準な関数型言語が使いたいなー
401:デフォルトの名無しさん
09/07/19 04:25:40
それなら、とりあえず全変数は読み取り専用、書き換え可能な変数はmutable修飾子を付けるという方向にしよう。
402:デフォルトの名無しさん
09/07/19 10:51:16
>>400
runtimeなしで関数型言語作るのはかなり難しいだろう。
純粋関数型言語ならある程度可能だが。
403:303 ◆pFphp4Ej4w
09/07/19 16:24:49
どうも。やっと模試が終わりました。死んだ…
>>401
なるほど。
それはprivate,public修飾子を残した上で付け加えるということでよいでしょうか？
この他「これがいやだからこうしてほしい」等要望をなんなりと。
それから、取りあえず「新C言語」の名前を決めたいのですが、なんかありませんか？(時期尚早と言うなら取り下げます。)
404:デフォルトの名無しさん
09/07/19 16:51:31
「Ｃ」という文字を入れるか入れないか、それが問題だ。
入れなくてもいいなら、「 Zig 」とかをさっきふと思いついたり。
あと、こうしたいああしたいっていう要望聞くのは良いんだけど、
上手く舵取りして取捨選択しないと、汚い言語ができるよ。
ちゃんと設計理念ってものを自分なりに考えていかなきゃねー
405:401
09/07/19 16:52:12
>>403
いや、構文的にはCのconst/volatileの位置を考えている。
406:デフォルトの名無しさん
09/07/19 16:56:05
C言語のautoやregisterはキーワードとして再利用しても大丈夫だろう
407:デフォルトの名無しさん
09/07/19 17:00:55
const int x = 123;
mutable int x = 123;
みたいな感じか。
408:デフォルトの名無しさん
09/07/19 17:02:24
ここでふと聞いてみたい。
俺言語を作ろうと思ったことがある奴、実際に作ったことがある奴、どのくらいいるんだ？
ノ
409:デフォルトの名無しさん
09/07/19 17:03:42
>>406
とりあえずautoはC++0x同様の型推論で決定だな。
410:デフォルトの名無しさん
09/07/19 17:03:57
言語ってか、ＡＤＶツクールみたいなの作ろうとしたら、
どんどん言語っぽくなっていった。
411:デフォルトの名無しさん
09/07/19 17:19:11
Cの実行モデル的にmutablは無駄にコードを長くするだけだと思うな…
412:デフォルトの名無しさん
09/07/19 17:21:31
mutableね タイポ
413:385
09/07/19 18:36:40
そんじゃ夜から何か作り始めるよ。
実装言語はバリアントがあるOCamlとかの方が楽だけど誰でも改造しやすいようにJavaとかにしたほうがいいのかな？
>>403
とりあえず名前だけでも決めてくれると嬉しい。
414:デフォルトの名無しさん
09/07/19 18:46:18
>>413
いや、是非385自身が一番使いたい言語で実装してほしい。そっちに俺は1票を投じるぞ。
415:デフォルトの名無しさん
09/07/19 18:49:21
新C言語だから・・・
SINCL: SINCL Is New C Language
416:デフォルトの名無しさん
09/07/19 18:58:36
QINC Is Not C-language.
417:303 ◆pFphp4Ej4w
09/07/19 19:47:12
>>405
なるほど。いいですね。
>>413
よろしくお願いします。私はそっち方面は全くわからないのですごく助かります。
>>415
>>416
GNUですかww
他に名前の候補ありませんか？
418:デフォルトの名無しさん
09/07/19 19:52:56
開発コードネームはLouiseがいいです
419:デフォルトの名無しさん
09/07/19 20:00:19
>>418
して、その心は？
420:デフォルトの名無しさん
09/07/19 20:02:35
だって可愛いらしくて素敵な名前じゃないですか
421:デフォルトの名無しさん
09/07/19 20:10:30
Lowrise?
422:デフォルトの名無しさん
09/07/19 20:19:00
省略記法をたくさん作ってくれ
void引数の関数の()を省略できるとか
423:デフォルトの名無しさん
09/07/19 20:43:27
>>422
関数ポインタとの区別をどうする？
という問題は置いといて、それは何が嬉しくなるの？
424:デフォルトの名無しさん
09/07/19 20:54:06
省略が多いほうがタイプ楽でええやん
425:デフォルトの名無しさん
09/07/19 20:54:25
構文糖は、劇的にコード量が変わったり新たな意味が付与されるものでない限り、
あると逆に邪魔になるものが多いよ。
Java の拡張 for とか Haskell の do とかなら存在意義があるけど、
単に省略できるようにしたいだけなら、
引数 0 個の関数呼び出しでは、() を書いてはいけない
という仕様にしたほうが、まだ収まりが良いよね。
426:385
09/07/19 21:39:24
帰宅したので今から作ります。
>>414 に甘えてOCamlで実装することにしました。
名前が決まっていないみたいだから、とりあえず一番早かったSINCLで書いとく。
427:デフォルトの名無しさん
09/07/19 22:22:33
新Cを作るのなら
以下2点が希望かな
関数のファーストクラス化
プリプロセッサの廃止とその代替機能の追加
プラスアルファするとしたら
名前空間またはモジュール機構
並列処理の考慮(メモリモデル等)
機能追加は最小限でいい
比較的小さなのがCの良いところ
428:385
09/07/19 23:05:03
Cは識別子の管理が激しくめんどい。
誰かに改良案考えてほしいな～。
429:デフォルトの名無しさん
09/07/19 23:08:27
識別子の管理ってどこが面倒なんだっけか。
430:385
09/07/19 23:14:49
識別子の意味が文脈で変わるんだよ。
URLﾘﾝｸ(www.syuhitu.org)
がとても分かりやすい。
とりあえずここのとおりに実装してる。
431:デフォルトの名無しさん
09/07/19 23:26:23
typedef 周りか。解決策といったら……
その１：typedef なんて無くせばいいよ！
その２：型名は大文字から始まることにすればいいよ！
その３：AST 作ってから識別子を解析すればいいよ！
くらいじゃないのかな。
文法に注意すれば、それが型名なのか変数名なのかが一意に決まるから、
とりあえず構文木作っちゃえば良いんじゃないかと思う。
432:303 ◆pFphp4Ej4w
09/07/19 23:47:33
>>426
頑張ってください！
>>431
typedefの消滅はちょっと…(私的には。)
だから現実的にはその2かその3が解決策だと思います。
その他ご希望をなんなりと。新C言語の名称も引き続き受け付けます。
433:デフォルトの名無しさん
09/07/19 23:47:43
識別子が型名か変数名か分からないとASTが作れないのが問題なんじゃないのか？
434:385
09/07/19 23:56:13
typedefの問題は構文を修正する事で解決できると思う。
typedefがstaticやexternなどと文法規則が同じだというがややこしい原因のようだ。
435:デフォルトの名無しさん
09/07/19 23:56:36
>>430を斜め読みもしていなくて済まないけど、
typedefの宣言そのものが面倒のか、それともtypedefされた名前を使うのが面倒なのかどっち？
前者なら、typedefを別文法で実現すればいいはず（C#/C++0xのusingなど）。
後者は、Cっぽい文法を維持する限りどうしようもないよなあ。typedef禁止にしても
C++/Java/C#みたいにclass量産できれば同じような状況になるだろうし。
436:デフォルトの名無しさん
09/07/19 23:57:49
>>432
ほむ。気分はわかる。
>>433
具体的に reduce/reduce 競合起こすのって、どことどこだっけ。
起こしたらその部分の文法を変えちゃえばいいんじゃないかなーと。
437:デフォルトの名無しさん
09/07/20 00:09:34
すぐ思いつくのは、
変数宣言int (a);と関数呼び出しf(a);の区別が付かない
キャスト(int)(a)と関数呼び出し(f)(a)の区別が付かない
438:385
09/07/20 00:19:42
とりあえずtypedefの問題は「typedefは必ず先頭に付ける」という規則があれば解決できるね。
つまり
typedef int x; などはOK
int typedef x; などはNG
にすればよい。
439:デフォルトの名無しさん
09/07/20 00:23:52
reduce/reduce 競合起こすところを徹底的に消していけば、
とりあえず AST 作れるから、後はどうにでもなると思う。
440:デフォルトの名無しさん
09/07/20 00:33:10
>>438
そういう誰も書かないやり方は新言語でも禁止してしまえ。
441:385
09/07/20 00:43:27
修飾子の順番は制限しちゃってもよさそうですね。異論あるのかな。
int staticとか禁止。
void inline f(...) { ...}
とかも禁止でいいよね？
typedefやinline -> staticやextern -> intやdouble
という順番ということにして作ります。
442:デフォルトの名無しさん
09/07/20 01:01:29
typedef は修飾詞なのか……
単に型名の別名を定義する構文にしちゃだめなのかな。
typedef struct FOO { ～ } BAR;
みたいなのも禁止で良いんじゃないかなって思う。
struct FOO { ～ };
typedef struct FOO BAR;
だけ使えれば良いんじゃないかと。
というか、型名 "struct FOO" が使える理由ってなんなんだろう。
これも無くしちゃって良いんじゃない？
443:デフォルトの名無しさん
09/07/20 01:04:14
Javaは規約でこういう順番に書こうってのがあったはずだけど、構文で縛っても構わないと思う。
強いていればC/C++でconst char*派のほか、希にchar const*派がいるくらい。
あと、inlineは要らないと思う。registerみたいにオプティマイザの決めることになりつつある。
持っている言語も珍しいし。
444:385
09/07/20 02:36:19
寝ます。明日の午前中くらいには動くものが出来そうです。
>>303
の意見を全く聞いていないですが、現状では「修飾子の並び順」のみの修正のみをしてみます。
異論があれば後で直します。
それから自分が汚いと思ってた文法。見た目でなく文法がね。
unsigned, signed, short,long,char,intがすべて同じ種類の構文要素。修飾子とそうでないものがごちゃ混ぜ。
配列、ポインタの構文。
Javaみたいに
int[3] x;
とかの方が宣言文の構文が
{型} {識別子} ;
と統一できるのに。
switch文の構文
case x:
expr1;
expr2;
は構文的には
[ case x: expr1 ] と [ expr2 ]
というくくりになるが、
[ case x: ] と [ expr1; expr2; ]
となるべきでは？
etc.
445:デフォルトの名無しさん
09/07/20 07:28:26
> 関数のファーストクラス化
意味わかって言ってんのか
> プリプロセッサの廃止とその代替機能の追加
むしろCPPは互換性ないと困るな
わざわざC言語を選択する理由には資産の活用がある
この手のスレは最終的にLISPに向かう事は判ってるんだから
LISPをどうやってLISPっぽくないよう変形するのかを考えた方が早いぞ
446:303 ◆pFphp4Ej4w
09/07/20 08:32:15
>>444
全然聞かなくてOKですので。
447:デフォルトの名無しさん
09/07/20 08:42:20
もうさ、Javaにポインタ付けて
ネイティブに対応させればいいんじゃない?
Javaの良さは、javaDocだと思うけどな
448:デフォルトの名無しさん
09/07/20 08:47:09
>>447
それ何てC#のunsafe？
449:デフォルトの名無しさん
09/07/20 09:06:11
>>447
何というD言語
450:デフォルトの名無しさん
09/07/20 09:15:26
>>448
unsafe有ってもvm外せんからネイティブに対応とはならん気ガス
>>449
GCのメモリコンパクションやジェネリックが無いのが残念だな
まぁジェネリックはテンプレートである程度代用はできるが
451:デフォルトの名無しさん
09/07/20 09:57:58
>>450
単に実装がないだけで、言語仕様ではVMに依存していないよ。
URLﾘﾝｸ(www.ecma-international.org)
452:385
09/07/20 12:08:46
おはようございます。すいません、今起きました。
午前中までというの取り消し。
453:デフォルトの名無しさん
09/07/20 12:15:42
>>445
おまえよりはわかっているから大丈夫
互換性は捨てるって言ってるんだから
負の遺産を残す必要性はない
454:303 ◆pFphp4Ej4w
09/07/20 13:43:01
>>451
そうなんですよね。誰かネイティブコンパイラ実装したら面白そうですね。(使いませんけど…)
>>452
急がなくてかまいませんよ。
455:デフォルトの名無しさん
09/07/20 17:13:03
プリプロセッサで再帰的にマクロディレクティブを解釈できたらいい。
C++テンプレートの型なし縮小版みたいなことね。
456:デフォルトの名無しさん
09/07/20 17:22:52
Cライクな新しい言語作るよりC++から機能削減した方が現実的じゃないだろうか。
独自警告設定ツールみたいなのを。
457:デフォルトの名無しさん
09/07/20 23:30:54
何でもいいが、Cに変換できればいい
C++も最初はCへのトランスレータだったし
458:385
09/07/20 23:46:09
パーサは完成して動作するようになりました。想像以上にめんどかった。
可変長引数とかビットフィールドとかいろいろ後回しにしてます。
Prettyprintを実装してトランスレータとして使えるようになったらうｐします。どこがいいかな。
現状では文法はCのサブセットになってます。
さてこれをどういじりましょうか。
459:303 ◆pFphp4Ej4w
09/07/20 23:51:02
>>458
激しく乙です。
これからどうしていくかはここでの議論で決まっていくでしょう。
というわけでみなさんアイデアをじゃんじゃかどうぞ。
460:デフォルトの名無しさん
09/07/21 11:11:00
新言語は今ある全ての言語のスーパーセットにして、こんな感じで言語を切り替えられるようにして欲しい。Pl/Iっぽいけど。打倒SWIGで。
#lang C
void *do_something(void){
return NULL;
}
#endlang
#lang Delphi
(*よー知らん*)
#endlang
#lang D
void main(string[] args){
do_something();
}
#endlang
…perlにこんな機能有った気がする。
461:デフォルトの名無しさん
09/07/21 11:43:28
455の言うプリプロセッサ側の強化は言語自体をいじるより有効だと思う。
文脈に関係なくコードをぶった切れるのは力だ。
462:デフォルトの名無しさん
09/07/21 18:25:12
>>461
IDEにとって邪魔にならない？
C++やDのテンプレートやLispのマクロみたいに言語本体に組み込んだほうがいいと思うのだけど。
463:303 ◆pFphp4Ej4w
09/07/21 21:30:16
>>460
こんなことしたらプログラマのミスがますます増えそうですが･･･
>>461
>>462
たしかにIDEにとっちゃすごく邪魔でしょうね。
これだとすごく「IDEがつかえない」言語になりそうです･･･
464:デフォルトの名無しさん
09/07/22 02:55:47
>>462
そういやD言語がASTマクロを実装すると言ってたね。
これの45ページ目から。
URLﾘﾝｸ(s3.amazonaws.com)
465:デフォルトの名無しさん
09/07/22 06:08:07
突然で悪いけど、GCを使わない理由ってなんだろう
基本は手動メモリ管理だけど解放忘れやdangling pointerをコンパイル時に弾く、って言語を考えてるんだが、
調べれば調べるほどGCで良いような気がしてきた
一応、GCの明確な欠点としては「予測不可能なタイミングで長時間実行が止まること」があるんだが、他にはないかな
466:デフォルトの名無しさん
09/07/22 06:56:40
弱参照やファイナライザに関する問題の洗い出しがむずかしそう
467:デフォルトの名無しさん
09/07/22 07:02:45
>>465
っ リージョン推論
その欠点だけならインクリメンタルGCやコンカレントGCが明確な解決方法になっちゃいそう。
欠点をもうひとつ言うならば、挙動を静的に解決できないってのが挙げられるかと思う。
468:デフォルトの名無しさん
09/07/22 07:38:06
>>466-467
ありがとう。結構微妙な話みたいだな
確かに静的な情報は減るけど、malloc/freeだって断片化云々の話なんかになったら静的には挙動が分からないし
ところでリージョン推論って使い物になるの？
極端な例だけど、リージョン推論をする言語でLispのインタプリタを素朴に(GCのある言語で書くのと同じように)書いたとして、
それがリークなしで動作するとは思えない(もしリークなしで動作したら実質的にGCがあるってことだよな？)
リージョン推論をするという触れ込みのJHCというHaskellコンパイラは、少なくとも俺が試した時点では目に余るほどリークしたし
やっぱりmalloc/freeをどこに入れるかはプログラマが考えないとダメなんじゃないかと思うんだが
469:デフォルトの名無しさん
09/07/22 07:57:30
どっかにFIFOを用意してさ、別のスレッドで解放すればいいんじゃない？
470:デフォルトの名無しさん
09/07/22 07:58:19
LispみたいなGC入り言語でも、malloc/freeを使わないのと同じように
GCを発生させない静的な区間を作る事はできるよ
言語で保証されてるわけでもなく、実装に詳しくないといけないけど
471:385
09/07/22 13:38:37
昨日は作業できなかったですが、今日後でアップします。
>>468
詳しく読んでないですが少なくともCポインタのある言語でリージョン推論は実装できないと思われます。
メモリは基本的に一次元なので、ポインタが一つでもあればメモリ上の
あらゆるデータがアクセスされる可能性があります。
472:デフォルトの名無しさん
09/07/22 14:05:53
何をうぷしてくれるん？
473:303 ◆pFphp4Ej4w
09/07/22 16:13:54
>>472
すこしはレスを読んでください。
>>471
乙です。
>>465
俺様アプリをつくったとき、実行時のメモリ使用量をバージョンをあげるたびに減らしていくという楽しみが消失するから。
474:252
09/07/22 20:13:34
今更だが、
>>253
C++の様な新たな機能が増えても予約語追加でない悲劇を防げる。
どっかで整合性を取る必要はあるけどな。
475:デフォルトの名無しさん
09/07/22 20:24:00
ようするにschemeみたいにするのね
どんどんLISPに近づくね
476:デフォルトの名無しさん
09/07/22 21:26:17
美しさを追求していくと、どうしてもＬＩＳＰに近づいてしまうね。
でも、新Ｃ言語ってことは静的型になるわけだから、ＬＩＳＰ風ＭＬになる？
Ｃの場合、弱い静的型付けだけど、これを強くしたらどうなるんだろう。
替わりにパターンマッチを追加して。
でも、Cの利用場面を考えると型付けは弱くないとダメなのかな。
477:デフォルトの名無しさん
09/07/22 21:30:24
>>474
コードの互換性が最低になる
478:デフォルトの名無しさん
09/07/22 23:17:24
>>468
Cycloneではポインタの機能を制限してregion-inferenceを実現してるよ。GCあるけど。
JHCに関してはアルゴリズムが調整段階でメモリリーク起すって書いてるから、もしかしたらうまくいくはずなのかもしれない。
479:デフォルトの名無しさん
09/07/22 23:40:27
GCがあろうとなかろうと、finally的に実行される処理をクラス定義内に書ける仕組み、
——C++デストラクタ、C#のusing/IDisposable、scopeクラスみたいなもの——は必ず欲しい。
GC管理のメモリ以外のリソースのために。
480:デフォルトの名無しさん
09/07/23 00:11:06
じゃあC++かC#を使えよ
このスレの趣旨はなんだ？
481:デフォルトの名無しさん
09/07/23 00:31:04
>>479
それって、loan patternで十分じゃない？
クロージャは必須になるが、どっちにしろクロージャは欲しいでしょ。
482:デフォルトの名無しさん
09/07/23 00:48:16
クロージャすなわちGCだからイラネ
コンスト/デストラクタはあったらいいけど
既存のfinallyみたいな構文は場所が離れ過ぎて読みにくすぎる
変数の前後とかにまとめて書ける形になるといい
{ void *pool = __cons__ { return malloc(1024); } __dest__ { free(pool); };
}
みたいな
483:デフォルトの名無しさん
09/07/23 00:51:25
これをtypedefできるといいかな
typedef void *pool_t = __cons__ { return malloc(1024); } __dest__(p) { free(p); };
{ pool_t a; // この時点で__cons__実行
} // __dest__実行
484:デフォルトの名無しさん
09/07/23 00:56:42
ここまで書いて、例外機構が絡むとややこしくなると判る
setjmpも。内部的にデストラクタのチェインが必要になる
強制的に未処理の__dest__部を実行するunwindとか
485:デフォルトの名無しさん
09/07/23 01:00:16
>>482
C# の using/IDisposable で必要十分なような。
486:デフォルトの名無しさん
09/07/23 01:03:19
ああLispのwith系と同じやつね
487:デフォルトの名無しさん
09/07/23 01:19:07
typedef char *fillmem_t =
__cons__(size_t size, int c) { char *p=malloc(size); memset(p, c, size); return p; }
__dest__(void *p) { free(p); };
{ fillmem_t m(1024, 0xff);
}
この場合サイズがわからないから別管理だね
typedef struct {
void *p;
size_t size;
} *mem_t =
__cons__(size_t size, int c) {
mem_t p=(mem_t)malloc(sizeof(*p));
p->size = size;
p->p = malloc(size);
memset(p->p, c, size);
return p; }
__dest__(p) { free(p->p); free(p); };
この場合__cons__中のmem_tとかポインタ渡しで破綻するね
{ mem_t a(1024, 0xff), b = a; // bの実体は？
}
488:デフォルトの名無しさん
09/07/23 01:24:07
コピーコンストラクタを用意するかはともかく、
初期のC++と同じ轍を踏むことになるね
489:385
09/07/23 01:33:18
githubにアカウントを作って現状の物を公開しました。
github.com/385
README読んで下さい。現状はCのコードをパースしてCのコードを吐くだけです。
型チェックなど一切してません。バグバグです。
まぁトイプログラムとして読んで下さい。
Cの文法の汚い部分を綺麗にしようといろいろいじりましたので、コンフリクトが沢山あります。
これらを解消するのは結構無理があるので完全にCの文法にするか、
一から文法を作り直した方がいいかもしれません。
文法をどうにかしたらクラスとか無名関数とか実装してみたいですね。
それが使いものになるかどうかは別にして個人的な興味として。
490:479
09/07/23 01:46:40
>>481
ごめん忘れていた。自分の分類では、loan patternはあり。
491:デフォルトの名無しさん
09/07/23 01:50:04
>>482
__dest__相当のほうは、D言語のscope(exit)が構文的に参考になると思う。
>>483
そこまで書くと、C++のクラス定義の構文糖にしか見えない。
492:303 ◆pFphp4Ej4w
09/07/23 07:12:23
>>489
乙です。
493:303 ◆pFphp4Ej4w
09/07/23 18:50:48
> これらを解消するのは結構無理があるので完全にCの文法にするか、
> 一から文法を作り直した方がいいかもしれません。Cの文法をとる場合
C++やC#のコピーみたくなる。(個人的にはこっちのほうがいい。)
完全にCの文法を捨てる場合
簡単な文法になるかもしれないが、ほかのプログラマが使ってくれることはまずない。
どっちをとりましょうか。
494:303 ◆pFphp4Ej4w
09/07/23 19:08:39
申し訳ない。改行入れ忘れた。
495:デフォルトの名無しさん
09/07/23 19:14:13
どの道Cのソース流用できないんだろうから、好きにやったほうが良いんじゃないの。
496:デフォルトの名無しさん
09/07/23 20:12:35
構造化プログラミング推奨ということで
gotoは捨てて
指定数のループを脱出するbreak nを入れるのはどうか
497:デフォルトの名無しさん
09/07/23 20:30:01
break :LABEL;
498:デフォルトの名無しさん
09/07/23 20:31:38
nよりbreak ラベルの方がいいな
それってgoto
499:デフォルトの名無しさん
09/07/23 20:35:25
データ型を即値とオブジェクトへの参照のみにするとか
そうするとGC必要かねえ
500:デフォルトの名無しさん
09/07/23 20:40:00
言語の可能性を狭めてどうする
gotoは必須
gccのラベル配列相当も入れるべき
アセンブラで書くしかない所を(やや)高級言語でも書けるという事に価値がある
501:デフォルトの名無しさん
09/07/23 20:43:49
廃止するならむしろcontinueだ
制御の流れを混乱させるだけ
continue ラベルなんてあったらどうよ
糞だろうが
502:デフォルトの名無しさん
09/07/23 20:45:00
continue -> next
503:デフォルトの名無しさん
09/07/23 20:47:59
switchのbreakを廃止して、必要なところはgotoで飛ばす・・・いや、
そうすると
case 0: case 1: case 2: case 3: case 4:
break;
みたいな楽ができない
どうせ入れるなら関数型のパータンマッチだろう
504:デフォルトの名無しさん
09/07/23 20:51:30
だったらループ構文自体を廃止して全部再帰かgotoでいいよ
505:デフォルトの名無しさん
09/07/23 20:57:38
制御構造の書式を凝っても仕方ない。
条件分岐とジャンプさえあれば極端な話どうでもいいわけだ。
それよりもデータの生存期間の方が重要だ。
506:デフォルトの名無しさん
09/07/23 20:59:32
case 0, 1, 2, 3, 4:
break;
507:デフォルトの名無しさん
09/07/23 21:05:57
Cでもスタックにあるデータの生存期間は
{}を使えば制御出来るけどな
508:デフォルトの名無しさん
09/07/23 21:08:01
gotoでも？
509:デフォルトの名無しさん
09/07/23 21:24:12
他のブロックへgoto飛ばしたらそいつの責任てことで
その処理系のエキスパートが判っててやる場合もあるから
あとは飛んで終りなのか、コンストラクタとかとも連携さすのか
インテリジェントgotoと名付けよう
510:デフォルトの名無しさん
09/07/23 21:54:39
gotoを抽象化したものが継続だが、
継続は一旦その場所に行かないと得られない。
511:デフォルトの名無しさん
09/07/23 21:57:56
ちなみに、C++だと、コンストラクタというか変数宣言を飛び越えるgotoは禁止、コンパイルエラー。
#include <string>
void f()
{
goto l;
std::string s;
l:;
}
ただし、ブロックごと飛び越える場合は問題ない。
void g()
{
goto l;
{
std::string s;
}
l:;
}
512:385
09/07/23 23:03:50
>>493
一から作り直すというのは、Cの文法を元に拡張していくのはつらいので、
一からC風文法を作り直すという意味です。
ほとんどJavaとかC#とかの真似になると思いますね。
513:303 ◆pFphp4Ej4w
09/07/23 23:10:20
>>496
まぁ、基本的に条件分岐と例外処理の構文さえ用意してあればgotoっていらないんですけどね…。
>>500
ごもっともです。言語の幅を狭めることはプログラマの「出来ること」をも狭めてしまう傾向にありますからね。
514:303 ◆pFphp4Ej4w
09/07/23 23:14:45
>>512
うにゃ。すいません。
意味を取り違えてたみたいです。
あ、あと、人が結構増えてきたのでこれからはまたsageますね。
515:デフォルトの名無しさん
09/07/24 03:02:56
>>503
case (1 or 2 or 3 or 4 or 6..9) and not5($_) : hoge();
とか
int t = case /\d/: ( case 2 : hoge(); case 3 : 5);
とか書けると最初だけ嬉しいかも
この構文を拡張して case 文っぽいものを関数みたいに自分で定義できるとおもしろいかも
516:デフォルトの名無しさん
09/07/24 03:38:51
1 or 2 or 3 or 4 or 6..9 -> 15
517:デフォルトの名無しさん
09/07/24 09:32:27
そういや範囲caseってgccの拡張構文にあったな
518:デフォルトの名無しさん
09/07/24 10:58:26
そういうのはLISPだとすぐ試せる・・・
てか、デジャブをえらく感じるスレだ
519:デフォルトの名無しさん
09/07/24 11:04:38
string型が欲しい。
520:デフォルトの名無しさん
09/07/24 11:26:16
>>515
Scalaのパターンマッチが参考になるかもね。
ユーザ定義型を、自由にcaseに書ける。
521:デフォルトの名無しさん
09/07/24 11:40:17
OCamlやF#でも515みたいなのは普通にできる
match 3 with 1 -> 1 | 3 -> hoge();;
let a = match 3 with i when i=1 or i=2 -> i | _ -> hoge();;
let b = match 2 with i when i=1 or i=2 -> i | _ -> hoge();;
aはhoge(),bは2
522:303 ◆pFphp4Ej4w
09/07/24 16:31:24
「SINCL」の新しい構文の提案用テンプレ
構文名:
-----------------------
構文例:
-----------------------
メリット:
デメリット:
-----------------------
備考:
523:303 ◆pFphp4Ej4w
09/07/24 23:41:48
>>522
あと、SINCLは仮称ね。
別にこれでいいならいいけど。
524:デフォルトの名無しさん
09/07/24 23:56:47
303が何をしたいのか判らない
つまり提案しようがない
テンプレつーか一度方針をまとめてくれ
525:デフォルトの名無しさん
09/07/25 00:07:57
>>524に同意
LL的な構文の工夫より、
まずどんな問題を解決する言語であるのかを決めるべきだと思う。
おれ的にはとりあえず
- あくまでシステム記述言語であること
- 効率的なマルチコアプログラミングが書きやすいこと
であってほしい。
526:デフォルトの名無しさん
09/07/25 00:14:45
自分が実装できそうな手軽な範囲だと、ヘッダファイルを無くしたいのと、マクロを改良できるならしてみたいです。
まずはCへのトランスレータしか考えてないのでランタイムが必要な機能は無理です。
それから型推論とかですかねー
527:385
09/07/25 00:16:29
メール欄と間違えました。すいません。
528:デフォルトの名無しさん
09/07/25 00:41:37
言語仕様とはあんまり関係ないかもだけど、
マルチスレッドとかそういうのに対応するタイプのＣってできないかね？
529:デフォルトの名無しさん
09/07/25 00:43:29
>>526
型推論は地雷原だよー
foo(x) {
return x;
}
ためしに、この関数 foo の型を求めてみい。
530:デフォルトの名無しさん
09/07/25 00:54:24
>>525
>>303は主に構文に不満があるんだろ
だから構文を真っ先に議論するのは自然
531:デフォルトの名無しさん
09/07/25 00:55:51
型推論とかいらなくね？
何でそんなのが必要なの？
532:デフォルトの名無しさん
09/07/25 00:57:25
Haskellっぽくてかっこいいからに決まってるだろ
533:385
09/07/25 01:00:26
>>526
関数型言語を作った事があるので分かります。
多相型をサポートしようとしたら確かに悲惨ですね～。
ディクショナリパッシングとか考えたんですけど、Cではワード長が一定ではないので難しそうですね。
C++のtemplateのように型ごとに関数を展開するなら出来ないということもない気がしますが、ちゃんと考えてません。
534:385
09/07/25 01:01:58
>>531
あまり必要だとは思ってません。自分は実装に興味があるだけです。
535:デフォルトの名無しさん
09/07/25 01:04:09
>>533
へいゆー自分にアンカー付けてるぜよ。
template で多相型をサポートするなら（問題山盛りにせよ）可能だと思います。
ただ template 周りの文法と、コード生成に失敗したときのエラー表示が難点かと。
536:385
09/07/25 01:12:24
あら。
>>535
確かにその通りですね。
ただC++のテンプレートは展開しながら，型エラーになったところで初めてエラーメッセージを生成するからあんなことになるんだと思っています。
ちゃんと型検査を事前に行えるような仕様にして，型検査に通ってから展開するようにすれば多少マシにできないでしょうか。
537:デフォルトの名無しさん
09/07/25 02:02:33
>>529
a'->a'
538:デフォルトの名無しさん
09/07/25 05:11:32
>>529
C++だと戻り値の型推論は面倒だね (この場合は楽だけど)。
D言語だとこんな感じ。
import std.stdio;
auto foo(T)(T x){
return x;
}
void main(){
writeln(foo(10));
writeln(foo("str"));
}
539:デフォルトの名無しさん
09/07/25 10:08:27
>>529
高階関数をサポートしないならa->aのみ
さもなければ多相型を含む最小の型は一意にきまるが(a->a)
この関数に適応する多相型は無限にある
型推論が全てのケースで動くなら
関数定義の際、引数と戻り値の型宣言も省略して
f(x){return x;}
g(x,y,z){return x(y(z));}
みたいにできるだろうね
C言語っぽくは見えないが
540:303 ◆pFphp4Ej4w
09/07/25 13:16:21
>>524
お叱りごもっともです。
>>530
フォローありがとうございます。
しかし実際のところ、私は一つか二つ爆弾投下して逃げるつもりでした。その後なんだかズルズルとここまで来てしまったので、SINCL(仮称)の方針を明示する機会がありませんでした。
また、皆さんの「プログラミング言語に求めていること」を取り込んで言語仕様を提案しようと思っていたので、「もっとプログラマの意見を聞くべきではないか」と思っていました。
そのため、方針を示さなかったし、逆に示せなかったのです。それについて不快に思ったのであれば深くお詫びします。
さて、肝心の方針についてですが、385さんとまだコンタクトをとっていないので(すいません。近日中に連絡します。)深いことは決めていません。
541:303 ◆pFphp4Ej4w
09/07/25 13:17:35
>>524
お叱りごもっともです。
>>530
フォローありがとうございます。
しかし実際のところ、私は一つか二つ爆弾投下して逃げるつもりでした。その後なんだかズルズルとここまで来てしまったので、SINCL(仮称)の方針を明示する機会がありませんでした。
また、皆さんの「プログラミング言語に求めていること」を取り込んで言語仕様を提案しようと思っていたので、「もっとプログラマの意見を聞くべきではないか」と思っていました。
そのため、方針を示さなかったし、逆に示せなかったのです。それについて不快に思ったのであれば深くお詫びします。
さて、肝心の方針についてですが、385さんとまだコンタクトをとっていないので(すいません。近日中に連絡します。)深いことは決めていません。
続く
542:303 ◆pFphp4Ej4w
09/07/25 13:20:07
すいません。携帯から二重投稿してしまいました…
ただ、私のプログラミング言語に対する哲学としては「プログラミングは楽しむべき」だし、「やりかたはいくらでもある」べきです。
また、プログラマの能力を最大限サポートするよう柔軟であるべきだと考えています。ですからそのような言語方針が示されることになるでしょう。
…どうも私は木の根っこでなく葉っぱからはじめようとしていたようです。ごめんなさい。
続く
543:303 ◆pFphp4Ej4w
09/07/25 13:22:11
それを踏まえた上で皆さんにお聞きします。
どのようなものをサポートした言語仕様がいいでしょうか。
皆様の意見をお聞かせください。
544:デフォルトの名無しさん
09/07/25 14:17:21
あんまりＣから逸脱するなら、もう新言語を作ろうスレでいいと思うｗ
545:デフォルトの名無しさん
09/07/25 16:57:41
周りの意見を聞くのは良い事だけど、そもそも周りは、それぞれが自分の立場で
好き勝手言ってるだけだから、それらをぜんぶ取り入れたら無法地帯になるよね。
極端な話をするなら、C + Ruby + Lisp + Haskell + Java + Smalltalk のスーパーセットを作れば
みんな満足する素晴らしい言語ができると思うよ。素晴らしすぎて誰も使わないだろうけど。
そうじゃなくて、周りの意見を聞いたうえで 「さて何を取り入れようか」 を 303 には考えてもらいたい。
というより今までの流れの中で 「これだけは捨てられない」 ってポイントが、３点くらいはすぐに挙げられると思う。
そのポイントが「方針」だと思う。まずはそれを聞かせて欲しい。
546:303 ◆pFphp4Ej4w
09/07/25 18:28:39
> 好き勝手言ってるだけだから、それらをぜんぶ取り入れたら無法地帯になるよね。
あぁ…それ忘れてた(；´д｀)
> そうじゃなくて、周りの意見を聞いたうえで「さて何を取り入れようか」を303には考えてもらいたい。
> というより今までの流れの中で「これだけは捨てられない」ってポイントが、３点くらいはすぐに挙げられると思う。
そうですねぇ…
１.マルチスレッド周りの強化
２.後方参照の導入
３.ヘッダファイルの廃止
４.クラス、テンプレートの導入
ですね。なんか545さんの意見に便乗するようで悪いのですが、これが標準ということでよろしいですか？
547:デフォルトの名無しさん
09/07/25 18:33:41
a ? b : c
みたいなのもっとくれ
548:デフォルトの名無しさん
09/07/25 18:35:12
>>546
まんまD言語じゃん。D言語からGC外すの頑張った方が良くね?
>１.マルチスレッド周りの強化
標準でTLS、推移的なimmutableやsharedあり
>２.後方参照の導入
(前方参照と言うのだがまぁいいとして)これも採用されている。
>３.ヘッダファイルの廃止
ヘッダファイルもない。
>４.クラス、テンプレートの導入
クラスもC++以上のテンプレートもある。
549:デフォルトの名無しさん
09/07/25 18:47:55
あんなバグ言語参考にするだけ毒
550:デフォルトの名無しさん
09/07/25 18:50:52
D言語の仕様がバグってるの？
それともまともなコンパイラがないだけなの？
551:デフォルトの名無しさん
09/07/25 18:56:54
549じゃないけど…
コンパイラのバグはまぁ多いかな。特に想定されてないと思われる組み合わせを使うとバグに遭遇しやすい。
仕様のバグもまぁぼちぼちあるが(配列リテラルのキャストとか)、直していける範囲だと思う。
552:デフォルトの名無しさん
09/07/25 19:03:38
ただ再実装となるとD言語は複雑過ぎてC言語へのトランスレータですら現実的じゃない気が。
dmdのソース(GPL)を改造するならともかく。
553:デフォルトの名無しさん
09/07/25 19:19:31
>>546
>>548でも指摘されてるけど向きはパーサ基準だから
画面の下方向が前方になるよ
554:303 ◆pFphp4Ej4w
09/07/25 19:37:46
>>548
そうなんですよね…
いま現在のプログラミングの研究が進んだ社会ではC言語の後継を目指そうとオブジェクト指向を取り入れるとC#かD言語になってしまうのですよねぇ…
いっそのことオブジェクト指向はばっさりと切り捨ててしまいましょうか？
555:デフォルトの名無しさん
09/07/25 19:40:30
新しいパラダイムを作り出すの？
556:303 ◆pFphp4Ej4w
09/07/25 19:41:46
>>554
訂正
～オブジェクト指向やその他諸々を取り入れるとC#かD言語になってしまうのですよねぇ…
557:デフォルトの名無しさん
09/07/25 19:43:49
>>555
新しいパラダイムか。いいねぇ。
イベント駆動のパラダイムを全面に出した言語が欲しいなぁ
558:303 ◆pFphp4Ej4w
09/07/25 20:11:59
>>557
本当は、構造化プログラミングパラダイムであるC言語のパラダイムを受け継ごうという意味だったのだけど、それはいいなぁ…
ちょっと考えてみるね。
559:デフォルトの名無しさん
09/07/25 20:13:06
smalltalk
560:デフォルトの名無しさん
09/07/25 23:16:29
入力と出力が複数ある、時間軸を持った言語
561:デフォルトの名無しさん
09/07/25 23:22:30
インタプリタとしても使えるコンパイラ
562:デフォルトの名無しさん
09/07/25 23:41:01
そういえば
kコンパイラ使ったわ
ほとんど覚えてないけど
563:デフォルトの名無しさん
09/07/26 10:33:46
こーやって当初の方針からどんどん反れてガッカリ言語になるんですね。
564:303 ◆pFphp4Ej4w
09/07/26 21:26:47
385さん、githubにアカウント登録してメールをお送りしましたので、お読みください。
565:デフォルトの名無しさん
09/07/27 01:47:01
C言語の骨格はあまり変えないで欲しい。
ライブラリの話だけど、文字列バッファやファイル、ソケットとかを
一緒くたにできるようにしてほしい。
文字列をFILE *にアサインしてfprintfとかで読み書きでけるとか。
FILE *fp = string_open(buf, size, "r+b");
みたいな。
まあソケットへの適用は微妙だね。ソケットに対してfgets、ungetc
とか使えると便利ではあるけど。
ライブラリ作るのも大変だ。
566:385
09/07/27 02:08:05
>>564
メール読みましたが，別にメールで話すようなことでもないのでここに書きますね。
私は主に実装に興味があるので面白ければなんでもいいんですが、客観的に意見をいうと
「イベント駆動のパラダイムを全面に出した言語」というのがそもそもどういったものを
指しているのか良くわかりません。
イベント駆動のプログラムは大体どんな言語でも書けますし、結局のところ
コールバックを登録するだけなのだから、こんな構文があったらうれしいとかいうのも
想像できません。
並列処理のことなども考えるとイベント駆動について考えるのは重要だと思いますが、
言語の中心に据えるようなものなんでしょうか？
567:デフォルトの名無しさん
09/07/27 02:14:14
>>565
それ、fmemopen。今はPosix止まりだけど、今度のCの規格改定(C1X)で入る予定。
ソケットも、Unix系はfdopen、Windowsは_open_osfhandleして_fdopenでFILE*にできるのが現状。
だから、新言語のライブラリでもそう大変ではないはず。
なんでもファイル読み書きの如く扱えるのが当然という言語は多いけど、
なんだかんだでCでもそうできている。
自分はWindowsの人間なんで使ったこと無いけど、funopenやfopencookieとかも。
568:デフォルトの名無しさん
09/07/27 04:00:14
>>566
>「イベント駆動のパラダイムを全面に出した言語」
Reactive Programmingのこと言いたかったんじゃね?
似てるし。
569:303 ◆pFphp4Ej4w
09/07/27 09:11:06
だんだん自分が何したいのかわかんなくなってきました…
いったん勉強して、また出直します…
570:デフォルトの名無しさん
09/07/27 11:27:41
昔、C言語でOSのAPIみたいなのは使わずに、ラウンドロビンか何かで
スタック退避したりしてマルチタスクする、って本があった。
プリエンティブだったかどうか忘れたけど、
タスク切り替えのトリガは何だったかな。
571:デフォルトの名無しさん
09/07/27 12:06:05
>>570
fiberのこと?