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のこと?
572:デフォルトの名無しさん
09/07/27 12:08:26
microthreadって言った方がいいか。
573:デフォルトの名無しさん
09/07/27 19:08:43
打ち止めか・・・
やっぱり登り始めちまったようだな
LISPへの道を
この道は険しいから、相当の覚悟が必要だ
574:385
09/07/27 19:28:49
303が居なくなってしまったんで、自分で好き勝手に作って遊びます。
何かできたらここに書くかもしれないし書かないかもしれません。では。
575:デフォルトの名無しさん
09/07/27 22:53:20
LISPから下りはじめたらどうなる？
576:デフォルトの名無しさん
09/07/27 22:55:06
Cだけに未完！
577:デフォルトの名無しさん
09/07/28 00:13:42
綺麗なオチしてるだろ・・・
死んでるんだぜ、スレ
578:デフォルトの名無しさん
09/07/28 00:58:09
ま、勝つことが目的になってたら、勝てるものも勝てないよな。言語作りは奥が深いよ。
303 の悪いところは、良い所だけを考えて、それ以外の細かい部分を疎かにしていたこと、かな。
最後まで作りこんだ経験があればまた話は違ったのかもしれないけどね。
579:デフォルトの名無しさん
09/07/28 01:05:53
……批判してばかりもなんだし、劣化コピー前提で色々考えてみるかな。
思い立ったが吉日生活さー
580:デフォルトの名無しさん
09/07/28 11:04:16
>>510ってどういう事？
581:デフォルトの名無しさん
09/07/28 13:07:34
>>580
抽象化って言葉がバズワード化してる。
継続を得ると言っているのはおそらく
returnとかbreakとかcontinueのようなオブジェクトを得る
ということ。
582:デフォルトの名無しさん
09/07/28 20:03:21
You shall never return home.
583:デフォルトの名無しさん
09/08/01 20:23:03
>>581
バズワード化なんてしてないと思うけど。
単にキミが頭悪いだけじゃないの？
>>510の2行目の表現はちょっと意味不明なところがあるが…
言っとくけど俺は>>510じゃないよ。
584:303 ◆pFphp4Ej4w
09/08/02 00:17:33
みなさんどうもお久しぶりです。303です。とりあえず近況報告のみさせていただきます。
あれから自分の頭を冷やし、他の言語の仕様を調べたり、関数型言語を軽く調べたり、学んだりしていました。
そのかいあってか、私の中ではかなり具体的にSINCLの言語仕様が固まってきました。
おそらく近日中にSINCLの言語仕様案をこのスレのなかで提示することが出来ると思っております。
またSINCLの言語としての方針もそのとき示すことができるでしょう。
とりあえず今日言いたかったことはこれだけです。それでは失礼いたします。おやすみなさい。
585:デフォルトの名無しさん
09/08/02 06:26:23
楽しみにしてるよー
586:303 ◆pFphp4Ej4w
09/08/07 15:48:17
諸事情ありまして発表が大幅に遅れます。
申し訳ございません。（発表待ってる人いないと思うけどとりあえず。）
587:デフォルトの名無しさん
09/08/07 18:57:24
えー
588:303 ◆pFphp4Ej4w
09/08/13 17:27:02
みなさん、お久しぶりです。303です。
いま携帯から書き込んでいるので今後のSINCL(仮称)の方針についてお話しするに留めておきます。
当分はC言語へのトランスレーター向けの言語仕様を策定していくつもりです。これがSINCL(仮称) version1となります。
恐らく言語仕様に盛り込まれるのは
テンプレート
名前空間
半端な型推論
となるでしょう。文法はあまりC言語とは変わらなくなると思います。(一部の変態的構文のみ廃止または改訂されます。)
SINCL version2(仮称)はコンパイラ向けの言語仕様になると思います。
SINCL(仮称) version3はオブジェクト指向が盛り込まれると思います。
SINCL(仮称) version4は返り値に関数が指定できるようになると思います。
…これらが今後のSINCL(仮称)について私が抱いている青写真です。
今後このプロジェクトがどのような方向に進むかわかりませんがどうか皆様よろしくお願いします。
それでは、失礼いたします。
589:デフォルトの名無しさん
09/08/13 20:11:57
頑張れー
590:デフォルトの名無しさん
09/08/13 23:21:00
SINCLはSuper INdent C Languageの略称です
591:デフォルトの名無しさん
09/08/13 23:29:44
関数が返せるってのはつまりクロージャ？
どうやって実装するつもり？
592:デフォルトの名無しさん
09/08/14 01:00:43
クロージャを受けるオブジェクトと参照カウンタで作れる
593:デフォルトの名無しさん
09/08/14 01:10:54
その作り方はセンスないだろ
あくまで新C言語なんだから。
594:デフォルトの名無しさん
09/08/14 01:31:43
>>588
何かもうそれだとC++0xっで良くね?
595:303 ◆pFphp4Ej4w
09/08/14 10:37:17
>>591
>>592氏が言っているようなやり方でできると思います。
まぁversion4での話ですから、言語仕様の策定は当分先、早くても2011年頃になると思います。
ですから今から実装の話をするのはちょっと早すぎるような…
そこらへんは385氏と話さないとなんとも言えませんね…
>>594
SINCL(仮称)はオブジェクト指向でないという点が違います。(version2まで)
596:デフォルトの名無しさん
09/08/14 13:09:30
つまりversion3からはC++0x？
597:303 ◆pFphp4Ej4w
09/08/14 14:33:45
>>596
そういうことになるのかなぁ…
ただ、SINCL(仮称)=C++と言う訳ではないので同じものであるとは言えません。
ま、まだ先の話ですから。
598:デフォルトの名無しさん
09/08/15 06:58:02
全然目的が見えない。
599:303 ◆pFphp4Ej4w
09/08/15 14:31:17
>>598
目的…それは今のC言語の特徴を残しつつ、それを越えたプログラミング言語(新C言語)を、実装･言語仕様共に皆様に提供することに他ならないと私は考えています。
600:デフォルトの名無しさん
09/08/15 18:54:47
残したいC言語の特徴って何？
601:デフォルトの名無しさん
09/08/15 19:53:00
303
お前は何も作る気が無いと言ってるのと同じ
しかもまだ385に頼るつもりでいるのか？
別に誰も期待してないし、もう出てこなくていいよ
602:303 ◆pFphp4Ej4w
09/08/15 19:54:07
>>600
重要度の高いものから順に
1.高い移植性
2.OSさえも(アセンブリ言語を一部使用しなければならないにしても)書けてしまうという高い柔軟性
3.高いパフォーマンス性能
603:デフォルトの名無しさん
09/08/15 20:34:56
>>602
評論家みたいな抽象論だね。
1.と3.は要するに言語仕様に環境に依存する機能は含めない（環境の違いは
ライブラリで吸収）すること、2.は要するにポインタのことでしょ。
しかし、何もガラガラポンの全とっかえである必要は何もないと思うんだが。
Cのマズい仕様を変更し、不足している機能を補う、それで十分じゃないのか。
発展的継承って理論でもものづくりでも一番オーソドックスな進歩の方法でしょ。
604:デフォルトの名無しさん
09/08/15 20:37:14
Cへのトランスレータなんだから、全とっかえでは無いのじゃないかな
と、横槍
605:デフォルトの名無しさん
09/08/15 20:53:12
ガキじゃないんだったら否定するまえにアイデアをだせな。
おれはメモリ空間を超えられる言語がおもしろいと思うな。
OpenCLとかあるけど、仕様が現行GPUの都合で決められてて汚すぎ。
GPU以外にも例えばCell B/EのPPEとSPEがシームレスにプログラミングできるとか、
サーバクライアントのアプリががひとつのソースから作れるとか。
ランタイムをどれだけ最小限に抑えられるかがミソだと思う。
つうかこれ数年前に作り始めて途中で挫折したんだけどさ。
606:303 ◆pFphp4Ej4w
09/08/15 20:55:21
>>603
そういうつもりなんですが、あの文じゃわかんないか(；´д｀)
607:デフォルトの名無しさん
09/08/15 21:05:54
>>602
C言語へのトランスレータだった時代のC++のサブセットを再発明して、その後C++0xのサブセットを再発明するとしか見えない。
がっかりだ。
608:デフォルトの名無しさん
09/08/15 23:18:21
何ががっかりだよ。
じゃあお前は何をつくれるんだ？
609:デフォルトの名無しさん
09/08/15 23:23:08
何故そういう話になるんだか。
610:デフォルトの名無しさん
09/08/15 23:28:04
上から目線で否定してるのは確かにいらっとする。
建設的な話ができないやつは厨房って自覚した方がいいね。
611:デフォルトの名無しさん
09/08/15 23:32:15
建設的って。建設的な話題は手前の方で出したよ。
その結果がこれじゃぁね。
#あるコンパイラを弄ったことあるから協力するつもりで居たのに残念という意味合いが強い。まぁ期待しすぎただけだが。
612:デフォルトの名無しさん
09/08/15 23:34:22
作る本人は良いとして、これができたからと
いって、使い道はあるんだろうかね。
613:デフォルトの名無しさん
09/08/15 23:35:44
個人的に強力なジェネリックとかあると使ってみたい気はするが。
614:デフォルトの名無しさん
09/08/15 23:36:28
ネイティブ言語でのジェネリックは俺も興味あるな
615:303 ◆pFphp4Ej4w
09/08/15 23:58:58
>>607
ここでつくられる言語がガッカリなものになるかどうかはここで皆様が下さる助言に少なからず関わってくると思います。
あ、あと、あまり私に過度な期待をかけないほうがいいと思います。
投げ出すつもりはありませんが、所詮はどこにでもいる高校1年生ですし。
616:デフォルトの名無しさん
09/08/16 00:04:10
どうせ釣るんなら
ちなみに女です
とか気を利かせろよ
617:デフォルトの名無しさん
09/08/16 00:18:13
>>615
仕様制定のプロセスの問題について言いたいこともあるが、まぁいいや。
まずは既存の実装のソースを弄ることから始めてみるといいよ。そうしないと全体像掴めないだろうしね。C言語コンパイラのtccやD言語コンパイラのdmd辺りを弄るのがお手軽かな。
本当は分かりやすいC++実装があると良いのだけどね。
URLﾘﾝｸ(bellard.org)
URLﾘﾝｸ(ftp.digitalmars.com) (dmd2/src/dmd内)
#llvmのclang(cfe)とかgccとかは試してないので難しさは分からないけどざっと見ややこしそう。
#上の方で紹介されてたcycloneもソースあるようだけどもcyclone自身で書かれているようなので理解には向かない予感。
618:303 ◆pFphp4Ej4w
09/08/16 00:29:18
> >>615
> 仕様制定のプロセスの問題について言いたいこともあるが、まぁいいや。
言いたいことはじゃんじゃか言ってしまって結構ですよ。
とりあえず紹介して下さった実装のソースコードを見てみることにします。
619:デフォルトの名無しさん
09/08/16 00:40:52
>>618
>言いたいこと
後でいいや。
>ソースコードを見てみることにします
忘れてたけどこれも張っとく。
ソースコードを読むための技術
URLﾘﾝｸ(i.loveruby.net)
構造が分かるようになれば面白くなってくるから頑張れ。
620:デフォルトの名無しさん
09/08/16 00:42:56
いつから初心者が作るコンパイラスレになったんだ
別スレたててやれよ
621:デフォルトの名無しさん
09/08/16 00:46:22
実装知らんと仕様作れんだろjk
622:303 ◆pFphp4Ej4w
09/08/16 18:46:00
えーっと、とりあえずversion3とversion4については皆さんの反感がかなり強いので、このバージョンの言語仕様の策定･実装の提供は一時的に凍結いたします。
今後皆さんの要望があれば凍結が解除されると思いますが、これじゃそんなことはないだろうな(；´д｀)
623:デフォルトの名無しさん
09/08/16 19:21:24
>>622
頑張れ。技評の"要求を仕様化する技術・表現する技術"って本読んでおくと良いよ。プロセスの問題が分かるから。
624:303 ◆pFphp4Ej4w
09/08/16 20:38:25
>>623
ちょいと図書館で探して見ます。
625:デフォルトの名無しさん
09/08/17 23:31:16
今日本屋に行ったら、コンパイラを作るって本が売ってたな。
作例がＣフラットとかいうのｗ
626:デフォルトの名無しさん
09/08/18 00:59:12
今
日本屋
627:303 ◆pFphp4Ej4w
09/08/18 09:37:00
>>625
そういえば今年はコンパイラ関係の本が次から次へと出版されてますよね。ドラゴンブックとか。
今年はコンパイラ本の当たり年なんですかね。
628:デフォルトの名無しさん
09/08/20 09:44:14
ネーミング(仮)のSINCLなんだけど
Common Lisp と間違えそう
629:デフォルトの名無しさん
09/08/20 10:10:34
じゃあ間違えないようにCommonLisp処理系作ればいいよ
630:303 ◆pFphp4Ej4w
09/08/20 18:27:48
>>628
…いいかげん仮称じゃなくて正式名称をきめたいですねぇ…
631:デフォルトの名無しさん
09/08/20 18:54:14
もう、面倒だから"303c"でいいよ。
632:303 ◆pFphp4Ej4w
09/08/20 19:33:48
>>631
いやいや。ここの人たちのアドバイスがなきゃ私は言語仕様作れませんし。
それじゃ株式会社ジェーンの二の舞に…
633:デフォルトの名無しさん
09/08/20 21:30:20
どうせ作る気もないんだろ。
303c、TB303みたいでかっこいいじゃん。
634:デフォルトの名無しさん
09/08/21 00:12:55
CB-303とかパチモン臭強くした方がいい。
さて、Bは何の略にしようか。
↓
635:デフォルトの名無しさん
09/08/21 06:19:03
Ｃ委員長
636:デフォルトの名無しさん
09/08/21 08:42:07
名前って結構悩むよね
実務で変数とか関数にhogeとかつけてるとすぐにクレームが＾＾；
スレ主が決めちゃえばいいと思うんだけど「みんなで決めよう」ってことなら
開発用のコードネームをとりあえず決めちゃえばいいんじゃない？
SINCLでもいいと思うよ
仕様が決まり出してから正式名を決めれば？(アンケートとかで)
303好きな人が多いのでリアルタイム特化型にしたら
CR-303とかパチンコみたいな名前になるかも
637:303 ◆pFphp4Ej4w
09/08/21 11:46:22
>>636
そうします。
638:デフォルトの名無しさん
09/08/21 12:15:27
高校1年生でコンパイラ作れるってすごいな。
C言語のトランスレータだったら最適化フェーズはないんだろうけど。
それでもすごい。
コンパイラ構成論の勉強したの？
名前は美緒さんとかw
639:デフォルトの名無しさん
09/08/21 12:33:59
>CR-303
ボタン電池みたいだな。
だがそれがいい。
640:デフォルトの名無しさん
09/08/22 04:23:40
名前は
コンパ イラ
641:デフォルトの名無しさん
09/08/22 05:56:14
>>639
30mm x 3mmですね。わかります
642:デフォルトの名無しさん
09/08/23 04:13:39
Cの当時からlambdaが導入されてりゃC++ももっと違う言語になってたろうな。
Bool bool(a==b);
bool.
True([](){puts("Equal")}).
False([](){puts("Not Equal")});
こんなSmalltalkライクな構文も書ける訳だし。
643:デフォルトの名無しさん
09/08/23 09:40:35
生存期間の問題がある
644:デフォルトの名無しさん
09/08/23 10:58:31
クロージャをコピー不可にすれば大丈夫じゃね？
645:デフォルトの名無しさん
09/08/23 11:23:59
↑クロージャへの参照(ポインタ)のコピーだった。
関数の引数として渡すのはOK
646:デフォルトの名無しさん
09/08/23 23:24:43
マルチスレッドですぐ破綻するクロージャなんてない方がまし
647:デフォルトの名無しさん
09/08/24 02:33:56
そういう使い方ならスタティックやヒープに置けば問題ない。
要するに置き場所を選べるように作ればいい。
648:デフォルトの名無しさん
09/08/24 17:25:04
>>641
寧ろそれは、3mmΦ*0.3mm厚じゃないのか?
例えばCR-2016は20mmΦ*1.6mm厚だぞ。
649:デフォルトの名無しさん
09/08/27 23:00:23
あんま関係なさそうな話だけど、
s = hogehoge(s);
みたいなのを、
s *= hogehoge;
とかみたいに書けるってのはどうだろう。記号はともかくとして。
++がアリなら、こういうのもアリな気はする。
他の言語だとどんな文法使うんだろ。こういうのって。
650:デフォルトの名無しさん
09/08/27 23:11:53
>>649
それ少しも複雑性が減ってるように思えないんだけど・・・
しかも代入演算子の書き方と少しもシンメトリックじゃないってどういうことだ
651:デフォルトの名無しさん
09/08/27 23:29:16
a = a - b;
a = b - a;
代入演算子を使えるのは前者のみ
652:デフォルトの名無しさん
09/08/28 00:39:57
>>650
perlの正規表現みたいな感覚でもいいんだけど、
そういうのにふさわしい記号が思いつかない。
653:デフォルトの名無しさん
09/08/28 01:09:52
むしろ
s.hogehoge
ですな
追加のような単純な処理ではなく、
全体に変更を加えるような意図なら
演算子化は避けるべき
654:デフォルトの名無しさん
09/08/28 04:57:22
>>649
hogehoge(&s);
655:デフォルトの名無しさん
09/09/02 22:12:36
興味あるので落ちないように上げとく
自分としては強力なマクロが欲しい
m4ぐらいの…
あまり無理せずにマターリと！
656:303 ◆pFphp4Ej4w
09/09/02 22:48:59
>>655
どうもありがとうございます。自分なりにリファレンス書いたり実装をちょびちょび書いているのですが…もうすぐ学校の文化祭でして（10月）しばらく手がつけられなさそうです。
657:デフォルトの名無しさん
09/09/02 23:04:07
高校生がC言語ライクなコンパイラ作れるってすげーな。
理論は独学？
658:デフォルトの名無しさん
09/09/02 23:09:20
高校生なの？凄いな最低でも大学生かと思ってたわ
659:デフォルトの名無しさん
09/09/03 00:00:22
>>657
いやいやただのトランスレーターですよ。
まぁそのうちコンパイラも…
660:303 ◆pFphp4Ej4w
09/09/03 00:04:27
>>657
いやいや、ただのトランスレーターですよ。
まぁそのうちコンパイラも…
ただ最適化とかいれるとなると私の手におえなくなりますが…
第一こんなアホな発言ばっかりしてるのに大学生と思われてたってのは…何?
661:303 ◆pFphp4Ej4w
09/09/03 00:16:02
だぁっ!
二重投稿してしまった…
662:デフォルトの名無しさん
09/09/03 06:21:45
>>303 は大学受験に落ちる
663:デフォルトの名無しさん
09/09/03 16:59:17
これが303の人生で最大の偉業になるかもな
664:デフォルトの名無しさん
09/09/05 02:03:54
トランスレータでも構文解析の知識はいるだろうに。
665:デフォルトの名無しさん
09/09/05 13:16:04
その辺もすべて385にやらせようとしてたみたいだが・・・
技術者より経営者に向いてるかもよ！
666:デフォルトの名無しさん
09/09/06 07:26:28
ソースはどこで見れんの？
667:デフォルトの名無しさん
09/09/06 07:37:40
俺も以前C言語作ろうとしたんだけど
C言語て記号いろいろ使ってて、作るのめんどくなって途中で投げたんだ
printfと、if,elseまで作った時点でかなりソースが膨らんでてやる気がな････
303がどこまで作れたのか興味深い
668:303 ◆pFphp4Ej4w
09/09/06 09:00:21
>>664
まぁそうですが、最適化と実行ファイル生成とかがないだけ楽です。
>>666
URLﾘﾝｸ(github.com)
で385氏がOCamlで書いたものが見れます…と思ったら無くなってますね…
とりあえずソースは手元にあるのでどこかうｐろだ紹介してくださればそこにあげます。
>>667
C系の言語って他のプログラミング言語より圧倒的に演算子が多いですからね…
669:303 ◆pFphp4Ej4w
09/09/06 09:11:00
あ。h抜き忘れた。
670:デフォルトの名無しさん
09/09/10 10:20:15
>>668
That page doesn't exist!ってなってる
671:デフォルトの名無しさん
09/09/10 20:45:51
>>668
>で385氏がOCamlで書いたものが見れます…と思ったら無くなってますね…
>とりあえずソースは手元にあるのでどこかうｐろだ紹介してくださればそこにあげます。
672:デフォルトの名無しさん
09/09/10 22:23:36
>>668
Wikiを作ってWikisourceみたいな使い方すればリファレンスも書けて一石二鳥
673:デフォルトの名無しさん
09/09/10 22:30:09
俺はもうこれで良いや。特にクロージャの追加の所。
URLﾘﾝｸ(www.open-std.org)
674:デフォルトの名無しさん
09/09/12 00:28:34
>>672
っ[Wiki]
URLﾘﾝｸ(ja.project-sincl.wikia.com)
675:デフォルトの名無しさん
09/09/12 08:15:57
ちょwww
ああああふぃぃいぃぃぃ 多いよ^^;
676:303 ◆pFphp4Ej4w
09/09/12 14:13:26
>>674
作ってくださったのですか？ありがとうございます。
677:デフォルトの名無しさん
09/09/12 21:11:08
atwikiとかのが無難だろ
ああそうか、わざわざ変な道を行くのがこのスレの趣旨でしたね
678:デフォルトの名無しさん
09/09/12 21:40:53
ウィキペディアがいろいろと普及? したので、
MediaWikiで書きたいという需要が最近増えてるが、
atwikiだとMediaWiki互換機能はかなりあやしい。
679:674
09/09/12 23:05:18
>>677
atwikiだとソースコードモードで10000行200000バイトまでしかかけないのでMediaWikiかなと。
680:デフォルトの名無しさん
09/09/13 03:42:41
どちらかというとpukiwiki系の方が好きだな
681:デフォルトの名無しさん
09/09/13 08:37:13
Pukiwiki使っているところはページの階層構造が分かりにくいことが多いと自分は感じる。
管理のしっかりしているサイトなら気にならないんだけど。
MediaWikiはカテゴリによって適当にやってもそれなりに階層構造ができているように見えるのがいい。
WikipediaやChakuWikiのような誰でも編集できるところはMediaWikiがあっていると思う。
682:デフォルトの名無しさん
09/09/14 22:48:09
gccを適当に拡張して本家にマージさせたら楽そうだな
アレ以上何を拡張するんだか知らんが
683:デフォルトの名無しさん
09/09/16 22:30:30
gccフロントエンドは結構な鬼門のイメージがあるがな
684:デフォルトの名無しさん
09/09/17 00:51:42
え、何？
LLVM のフロントエンドを作りたいの？
685:303 ◆pFphp4Ej4w
09/09/18 21:11:39
>>625にあった「ふつうのコンパイラをつくろう」を学校のメディアセンター(図書室)に注文しました。
いずれはコンパイラを作ることになるので今のうちに読んでおこうかと。
686:デフォルトの名無しさん
09/09/18 21:40:50
コンパイラまで作る気あるんだ
687:デフォルトの名無しさん
09/09/19 01:59:07
よくある、関数で最初に１回だけ実行される部分を何かの書き方にするのはどうか。
static int first = 1;
if(first){ ほげほげ first = 0; }
みたいなのを、
first{
ほげほげ
}
みたいに書けるとか。
688:デフォルトの名無しさん
09/09/19 02:05:11
じゃあ2回だけ実行されるのも追加しないとな
689:デフォルトの名無しさん
09/09/19 02:33:55
first よりも once の方が良いかもね。
static int once = 1;
while(once--) { ikkaidake() };
690:デフォルトの名無しさん
09/09/19 07:20:42
なかなか便利そうですね
int hogehoge() {
何かの処理
once { huga1 }
何かの処理
once { huga2 }
}
みたいに複数書けるとさらにうれしいかも
691:ぅゅ ◆e6.oHu1j.o
09/09/19 14:04:30
#define Ikkai \
static int ikkai; \
if( !( ikkai || ikkai++ ) )
defineでやれるだろカス
てかこれ、バグの元になるってのわかってんの？
初心者はそこらじゅうに
static int first = 1;
if(first){ ほげほげ first = 0; }
こんなソース書きまくるが
それはさっさとやめさせてまともな設計を考えさせるべき
692:デフォルトの名無しさん
09/09/19 14:08:34
まともな設計をするときは、C++でやるお(^q^)
693:ぅゅ ◆e6.oHu1j.o
09/09/19 14:51:08
きーてねーよカス
694:デフォルトの名無しさん
09/09/19 15:01:16
>>687-690の構文は議論の余地があると思うけど、基本的にはあるべきと感じる。
>>691のマクロもマルチスレッド時を考慮していないように見えるのが残念。
Javaの静的初期化ブロック、C#の静的コンストラクタ、VistaのInitOnceExecuteOnceなど、
マルチスレッドプログラムで1度しか実行されない保証というのは需要がある。
だから、そのための構文を作るアイディアは悪くないと思う。
というより、上に例を挙げたように正直に言って珍しくもなんともない。
あとは、どういう構文にするか。
695:デフォルトの名無しさん
09/09/19 15:55:36
>>689は構文というか、現行のCで使える方法だよ。
696:ぅゅ ◆e6.oHu1j.o
09/09/19 19:01:39
>>694
＞マルチスレッド時を考慮していないように見えるのが残念。
は？
この流れでマルチスレッドって発想は無かった
俺はもう一種類この手のマクロを持ってる
それはこのマクロで宣言されるstatic変数のアドレスを保存していって
初期化したくなったら、初期化関数を呼んで、またブロックを1回だけ通るようにするという仕組み
俺はマルチスレッドプログラムは組まないけど
Aスレッドが1個しか走らないプログラムなら
そのスレッドの終了時に初期化させればいいし
Aスレッドが同時にいくつも走るならスレッド作成時に識別子を与えれば普通に判定できるんじゃね
697:デフォルトの名無しさん
09/09/20 05:38:17
>>691
バグの元になりそうなのでマクロじゃなく構文に入れようとしてるんだろ？
698:ぅゅ ◆e6.oHu1j.o
09/09/20 07:35:42
そうなんですか？
じゃあ一つ385、303の書いてるソースもっていたら
static int first = 1;
if(first){ ほげほげ first = 0; }
こういう処理やってる場所を探し出してもらえませんか
ソース何処にあるか知らないけど
コンパイラとか作ってるならソース見なくても普通は無いと確信できる
699:ぅゅ ◆e6.oHu1j.o
09/09/20 07:38:08
スレ汚したな
自分の好きなように作ればいいよ
その処理は悪用されると怖いってだけで自分も極まれに使う事はある
700:デフォルトの名無しさん
09/09/20 09:48:34
なんか言っていることがよく解らないんだが…
トランスレータなりコンパイラなりを作ろうとしているんでバグが発生しやすいような
こういう処理やよく書く処理をこういう風に展開して欲しいとみんな言ってるのだと思う
701:デフォルトの名無しさん
09/09/20 12:40:11
>>698の意図がよく分からん。彼は何がしたかったんだろうか。
702:デフォルトの名無しさん
09/09/20 13:28:21
つーか、マルチスレッドはともかく、こんなの超安全な部類だと思うが。
それよりも自称プロがなんかわざわざ難しく見えるコード書いて俺ＳＵＧＥＥしてる方が危険ｗ
703:デフォルトの名無しさん
09/09/20 13:34:04
トランスレーター系はバグが出たらかなりデバッグしにくい。
トランスレーターの出力をある程度理解している人間じゃないと使えないから
結局統合される運命にある。
だからそのままリリースしておしまいってことにはならない。
もしそうなら開発者のオナニ－でしかいない。
LISPはその辺うまくできている。
704:デフォルトの名無しさん
09/09/20 13:52:22
Lisp がどうかはさておき、そんな当たり前の話を上から目線で話されてもなあ…
705:デフォルトの名無しさん
09/09/20 13:55:56
ついでに言えば、CL だろうと Scheme だろうとマクロにバグがあったら
デバッグはそれなりに面倒だと思うけど…
706:デフォルトの名無しさん
09/09/20 23:37:23
関数で最初に１回だけ実行される
ってのがそもそも設計間違ってる可能性が高いと思うんだが。
関数に状態持たせるなよ。
707:デフォルトの名無しさん
09/09/20 23:53:57
つまり君は、クロージャを採用している言語は設計間違ってる可能性が高いと思う訳か。
おいそれと JavaScript も書けんな…
708:デフォルトの名無しさん
09/09/21 00:09:28
新C言語だろ？
クロージャ採用は間違ってる可能性が高いと俺も思う
709:デフォルトの名無しさん
09/09/21 00:14:18
世の流れに棹さすのも悪くないと思うけど、理由くらい言って行こうや。
710:デフォルトの名無しさん
09/09/21 00:18:04
>>706
そうだよ。
ただ、インスタンス的に関数を使うやり方なだけだからな。
711:デフォルトの名無しさん
09/09/21 00:18:28
>>707
はぁ？
クロージャはモデルが違うだろ。
クロージャオブジェクトが関数と環境を持ってるんだよ。
言語スレの住人だったらメタモデルぐらい考えてみような。
712:デフォルトの名無しさん
09/09/21 00:18:34
>>708
>新C言語だろ？
つうか Blocks 知らんのか…
713:デフォルトの名無しさん
09/09/21 00:21:34
>>711
君は自分で自分の言ってる事が理解出来てるのかな?
714:デフォルトの名無しさん
09/09/21 00:29:02
>>713
さぁね。
環境という言い方でわかる人はわかるはずだけどね。
715:デフォルトの名無しさん
09/09/21 00:35:12
つまり君は『状態』と『環境』の違いを知っていると言う訳だ?
716:デフォルトの名無しさん
09/09/21 00:37:36
つーか、クロージャの場合はそういう話ではないと思うが。
ジェネレータの話か？
717:デフォルトの名無しさん
09/09/21 00:38:34
何かこの会話には、暫く前にデザパタが流行った時と同じ空しさを感じるな…
>>716
>>713
718:デフォルトの名無しさん
09/09/21 00:50:41
そうだね。
>>707の突っ込みが的外れなわけで。
それを認めるのがいやで言葉尻をとらえようと必死になってる。
そういう構図。
719:デフォルトの名無しさん
09/09/21 00:55:02
さぁ盛り上がって参りましたw
720:デフォルトの名無しさん
09/09/21 04:44:27
もっと中身の無い口先だけの議論を見たかったのに～
721:デフォルトの名無しさん
09/09/21 09:35:19
いいスレですよね～
スキルの高そうな人たちがそれぞれの信念のもとに突っ込んできますね～
書き込んでる人全員の意見を考慮し出したら前へ進まないので
作ろうとしている人たちが採用／不採用を決めればいいと思います
自分の意見としては
a:いろんなOS/アーキテクチャで使用できる
b:既存のC/C++のコードを最小限の変更(変更なしが望ましい)で流用できる
が最低限必要かと思います
a,bが満たされないとオナニー言語で終わってしまうかもしれません
逆に満たされると「スーパーコンピュータでも使えます」みたいな～
C言語へのトランスレータが良いかも(異議は認める)
722:デフォルトの名無しさん
09/09/21 12:19:28
関数内スコープな関数が有用か否かって問題でそ
723:303 ◆pFphp4Ej4w
09/09/21 14:02:15
なんかとてもめんどくさい流れになってますね…
>>708
クロージャ採用の話は凍結になったはずですが。
>>721
C言語へのトランスレーターである限りではどっちも満たせるんじゃないかと。
724:デフォルトの名無しさん
09/09/21 15:56:55
303が調子に乗ってる
なんかむかつく！
725:デフォルトの名無しさん
09/09/22 11:31:44
○既存言語の一部を仕様変更する際に、トランスレータは有効である (>>721)
×トランスレータは、既存言語の一部を仕様変更するために作成される (>>723)
303 の用語の使い方に、揚げ足取り。
726:303 ◆pFphp4Ej4w
09/09/23 20:07:43
wikiに385氏の実装のソースコードあげました。
と言ってもPDFファイルとODTファイルですが…
727:デフォルトの名無しさん
09/09/24 01:40:59
変更したい症候群の方は一度LISPを使ってみるべき
728:デフォルトの名無しさん
09/09/25 22:56:07
LISPで下痢が治りました
729:デフォルトの名無しさん
09/09/26 07:41:06
gelips
730:デフォルトの名無しさん
09/09/27 07:58:11
まだかなあ
731:デフォルトの名無しさん
09/09/27 11:52:04
俺的には
ジェネリックとオーバーロードと名前空間を足したCがあれば満足
クラスとかはいらんぽ
あとは型安全性の強化
732:デフォルトの名無しさん
09/09/28 01:03:07
>>731
オーバーロードの機能をよく吟味すると、C++と同じ型ロジックが必要だとわかるよ
つまりC++使えって事
733:デフォルトの名無しさん
09/09/28 03:06:59
C++を使うならJavaかDの方がいいな
734:デフォルトの名無しさん
09/09/28 03:13:05
このスレ的にGC言語はお呼びでないだろ
735:デフォルトの名無しさん
09/09/28 10:57:46
つまりDでいいと
736:デフォルトの名無しさん
09/09/28 11:03:47
そもそもC++なんかでいいなら新C言語なんて発想はない訳で…
737:デフォルトの名無しさん
09/09/28 20:36:41
>>1
現状報告をして下さい
738:303 ◆pFphp4Ej4w
09/09/28 21:08:42
>>731
ジェネリックはテンプレートでどうにかなるかと。
でもC++みたいなテンプレートだと時間かかるんだよなぁ…
739:デフォルトの名無しさん
09/09/28 23:05:11
>>1は逃げたの？
740:デフォルトの名無しさん
09/09/29 01:56:36
1は最初からいねーだろｗ
741:デフォルトの名無しさん
09/10/01 18:56:57
>>739
実現できそうになるのに2年かかるから>>1はいなくなったと考えるのが普通。
742:デフォルトの名無しさん
09/10/13 01:00:13
っ[age]
743:デフォルトの名無しさん
09/10/13 04:34:45
>>738
それはC++の実装というか仕様が糞なだけ。
744:303 ◆pFphp4Ej4w
09/10/18 02:13:02
保守あげ。
#年内にリリース出来たらいいなと希望的憶測でものを言ってみる。
745:デフォルトの名無しさん
09/10/18 02:25:47
tamarimahenna
746:デフォルトの名無しさん
09/10/18 04:46:05
C++、Java、C#の類は新C言語じゃねーの？シンタックス的に。
てかC99とC++のextern Cってどの程度同居できるの？
747:デフォルトの名無しさん
09/10/19 00:31:01
extern "C"は通常、名前修飾に関する扱いがCと同じになるというだけだが、
名前修飾がC99とそれ以前と異なる処理系なんて見たことないぞ。
748:デフォルトの名無しさん
09/10/20 18:09:27
名前修飾？
＠マークつきDLL関数ってCだとLoadLibraly使わないといけないけど
Basicだとそのまんま＠マークつきで関数定義できちゃうよね。
そういう話じゃなくて？
749:デフォルトの名無しさん
09/10/20 22:22:48
Windows以外も触っとけよ
750:デフォルトの名無しさん
09/11/03 17:40:08
ほしゅ
751:デフォルトの名無しさん
09/11/04 21:33:06
C + Smalltalk -> Objective-C
みたいなかんじで
C + CLOS -> 新C を妄想する
752:303 ◆pFphp4Ej4w
09/11/04 22:44:53
どうも。303です。
githubにあった385氏の実装のコード置き場が復活していました。
(落ちる前にわしがフォローしていたから？)
URLﾘﾝｸ(github.com)
と言うわけで、385氏の実装をビルドする際はgithubからソースを取ってきてビルドすることを強く推奨します。
ではでは。
753:303 ◆pFphp4Ej4w
09/11/12 07:03:26
なんかGoなんてのが出てきたみたいですね…。
利点:
コンパイルが速い
GC付き
並列処理を意識した設計
欠点:
パフォーマンスはCと比べ10%程悪い?(GCを採用しているからか?)
テンプレートがない
GCがある
構文はPascalとCを足して2で割ったような感じですね。D言語のスレで「将来的にDと競合するのでは?」なんて議論されてますが、むしろSINCLと競合するような気がしてなりません。被害妄想だと言われればそれまでですが。(まだ実装さえ出してないし)
Googleは何を目指してるんですかね…
…というわけで何が言いたいのかわからない雑文でした。
ついでにあげます。
754:デフォルトの名無しさん
09/11/12 08:38:59
Cには似てない
Pascal+Javascriptに見える
755:303 ◆pFphp4Ej4w
09/11/14 10:07:51
GoとかD言語のスレは盛り上がっているのにここは全然盛り上がらない(´;ω;｀)ﾌﾞﾜｯ
756:デフォルトの名無しさん
09/11/14 10:55:39
速いは正義
757:デフォルトの名無しさん
09/11/14 11:41:57
動くものが正義だよ。
758:デフォルトの名無しさん
09/11/14 14:20:11
かわいいは正義
759:デフォルトの名無しさん
09/11/14 20:00:37
正義すぎる市議
760:デフォルトの名無しさん
09/11/15 15:44:15
SBのCEOは正義
761:デフォルトの名無しさん
09/11/16 01:14:30
孫なこと聞いてねーよ
762:デフォルトの名無しさん
09/11/16 14:37:36
孫に関わると皆損する
763:デフォルトの名無しさん
09/11/19 19:12:49
ちんぽ切ると皆損する
764:デフォルトの名無しさん
09/11/25 17:12:39
「コンパイラ・スクリプトエンジン」相談室14
ｽﾚﾘﾝｸ(tech板)
このスレで今「俺言語」が話題になってる。
「俺言語」の変換先言語を感がえてみては？
765:303 ◆pFphp4Ej4w
09/12/09 11:32:34
すみません、
typedef struct Hoge{
/* ... */
union piyo{
int foo;
char bar;
}u;
}Hoge;
Hoge hogege;
hogege.u.foo = 3;
って感じで共用体をを使う人ってどれくらいいます？
766:デフォルトの名無しさん
09/12/09 11:35:53
>>765
unionは普通そういう使い方はしない。
構造体内でバイト列の読み替えをするのに定義することが多い。
union piyo {
int foo;
char bar[4];
short poo[2];
};
といった感じ。
767:303 ◆pFphp4Ej4w
09/12/09 11:44:40
>>766
確かにそういう使い方もありますわな。(完璧に処理系依存で、ほめられた使い方じゃないですが)
…で今回聞きたいのはそういうことではなくて、「構造体の中で共用体を宣言してしまう」人がいるか聞いたのですが…
768:303 ◆pFphp4Ej4w
09/12/09 11:49:21
あ、間違えた。
> 「構造体の中で共用体を宣言してしまう」
じゃなくて
「構造体の中で、共用体の宣言と共用体の変数宣言を同時にやってしまう」でした…
769:デフォルトの名無しさん
09/12/09 12:41:07
>>767
おいおい。処理系依存じゃないよ。char、short、long intは
それぞれ最低取りうる値の範囲がC言語の規格書で決められているぞ。
（ただし1バイトが8ビットかどうかは処理系定義と明記してあるが）
その意味ではintと書いて4バイトとみなすのは「処理系依存」だが、それならlong intと書けばいい。
せめてJISの規格書くらいは目を通そうな。
URLﾘﾝｸ(www.jisc.go.jp)
＞…で今回聞きたいのはそういうことではなくて、「構造体の中で共用体を宣言してしまう」人がいるか聞いたのですが…
Linuxカーネルのソースコード読んでみな。
770:303 ◆pFphp4Ej4w
09/12/09 13:08:58
>>769
> その意味ではintと書いて4バイトとみなすのは「処理系依存」だが、
あ、そういう意味です。申し訳ない。
> Linuxカーネルのソースコード読んでみな。
やっぱ結構いるんですかねぇ…
なんでこんなことを聞いたかと言うと、struct hoge型の宣言と変数宣言を同時に行うことはSINCLでは出来ないので(同様に配列、共用体なども)、
struct Hoge{
/* ... */
};<-この";"(名前忘れたorz)はなくてもいいんでないかと考えたからです。(…typedefはどうしたって？
もうstructとかの名前の扱い方C++と同じでいいと思って…
でも、こうするとこんどはstructの一括代入が不可能なCでは色々とめんどくさいのですがそれはおいといて。)