新C言語を作ろう

実はC言語はこんなこともできないのです。
int f(int n) { return n + 1; }
int g(int n)
{ int x = f(n);
{ int x = f(x);
{ int x = f(x);
return x;
}
}
}
int main() {
printf("g()=%d\n", g(1));
return 0;
}

さて、g(1)はいくつを返すでしょう？
このコードに対してエラーも警告も出さなかったコンパイラがあったら要注意です。
C言語は { int x = f(x); 〜} を期待通り処理しません。
初期化式中のxは変数宣言xによって既に親を上書きしています。
つまりこの規則は変数のアドレスを再帰的に初期化式に
適用したいというかなり特殊な状況以外に全く役に立ちません。
h() {
struct _tag {
struct _tag *next, *prev;
} a = {&a, &a};
printf("&a=%d a.next=%d a.prev=%d\n", &a, a.next, a.prev);
}
変数のアドレス限定なのは、初期化式中に変数の値を参照しても
何の意味もないからです。もし参照してたらエラーにすべきでしょう。

?

int g(int x)
{ int x = f(x);
{ int x = f(x);
{ int x = f(x);
return x;
}
}
}
だとエラーになった
: error C2082: 仮引数 'x' が再定義されました。
int g(int n)
だと警告
: warning C4700: 値が割り当てられていないﾛｰｶﾙな変数 'x' に対して参照が行われました。

(VC6SP4)

>>55
で、お前はそれがどうなったらいいと思う？

初期化式では、初期化対象の変数がまだ見えないようにするのか、
そもそもコンパイルエラーになるようにするのか、
はたまたそれ以外の方法があるというのか。

では、この辺の規則がしっかりしてるSchemeだとどうなるでしょう。
(define (f x) (+ x 1))
(define (g x)
(let ((x (f x))) (let ((x (f x))) (let ((x (f x))) x))))

(g 1)
=>4
まさに期待通りです。
まったくSchemeは素晴らしいですね。

>>55
そんなの当たり前のじゃん…

>>50
LISPみたいなのだったらありだ。

Cプロセッサは、C自体の字句解析と独立しているから、
IDEの入力支援機能なんかと相性が悪いはず。俺はそれが嫌なんだ。

>>57
いきなり関数の引き数と同じ名前で自動変数宣言すんなｗ

むしろ何を期待すれば>>55になるの？

>>55-59
そりゃ、変数に対する考え方が違うから当然だろ。
Cの変数つうか識別子は、つまるところ名前付きメモリ領域だからな。

ん、むしろ、これで当然（そしてSchemeも当然）と思える
俺の方がどうかしてるのか？
何か悩んだり面白がったりするものなのか？

>>64
どうかしてる。
>>57相当の事をしたいとなると、わざわざ別名を考える必要が
出てきて思考の妨げになるじゃん。

変数の初期化式中にその変数自身が含まれるべき、
なんて普通は考えないからな。違うスコープにある方が自然だろ。
C言語が一般的になりすぎたとか、そういう言語に慣れすぎたとかで、
その違和感に気付かないのかもしれないな。

変数でどうにかしようと考えるからだ。
C系言語的には、そういうときは変数名じゃなく型名を定義する事を考える。
つまりクラスにする。
あ、Cではクラス無理かw

C言語だとマクロに変数が入る時とかで困るんでは。

#define G(n) do { int x = f(n); return x; } while(0)
int g(int n)
{ int m = f(n);
{ int x = f(m);
G(x);
}
}
: warning C4700: 値が割り当てられていないﾛｰｶﾙな変数 'x' に対して参照が行われました。

その例なら、C99やC++でインライン関数使えばいいよ。

すまんこれはマクロでないと無理だなorz

>>59のgは
(define (g x) ((lambda (x) ((lambda (x) ((lambda (x) x) (f x))) (f x))) (f x)))
と等価という考え方であり、つまり初期化式は関数適用と同じスコープで
評価されるので、xは親を参照するという事が自然と自明になり、
文脈上のあいまいさもありません。Schemeにはletの他にlet*やletrecもあり、
こういった束縛規則をコントロールできます。
Schemeの変数束縛はとても理に適った設計なのです。

何か似たような問題を（もっと実用的な例で）解けるデザパタがあったような。
TMPという手もあるけど、それは今の流れ的にお呼びでなさそうだな

>>71
だから変数の考え方が違うと何度言えば

つまりboost::lambdaがあるC++最強だな

> struct _tag {
> struct _tag *next, *prev;
> } a = {&a, &a};
おれもこれは最初ｷﾓｲなーと思ったけど、必要悪かな。
グローバル変数のテーブルの初期化とかでちょっとイイ思いができるとか。
(初期化でコードを書かなくて済む)
書き忘れさせないとか、消極的な理由。
今の言語にはコンストラクタがあるから、そういう事気にするのは減ったけど。

>>73
そのｵﾒｴの考え方がそもそもｷﾓｲんだよ、というお話では

>>74違うw

新しいC言語には
classical int x = f(x) ; // エラー
int x = f(x) ; // OK
という風にclassicalキーワードを用意してみては

struct _tag {
struct _tag *next, *prev;
} a = {&a, &a}; // えらー 無効なaを参照した

>>78そのfに渡す初期値はどう決めるのよ？

>>74
boost::scheme…いや何でもない。冗談。

ヘッダファイルをやめようぜ

同意。
コンポーネント単位でインクルード出来てもいい。

確かに>>55は見ただけだと問題なく通りそうではあるし、
移植を繰り返して警告沢山出る様な引継ぎコードの一部だったりして、
しかもテスト環境がたまたまxが普通の値をとったりして、
とんでもない間違いにそのまま気付かないでデスマーチ突入とか
ありそうで笑える。

俺ならこんなの発見したら、
即消して書き直すかな…

つーか
int x = f(x);
と書いている時点で相当キモイ
こういうキモイ書き方を右辺のｘがより広いスコープのxだと思って書く奴はもっとキモイ
そしてそれを期待する奴はどうしようもなくキモイ
そうなる様に言語仕様を変えろという奴は氏んでくれ

lisperは害悪ということだけは分かった

>>84
お前が子ねカス

>>84
DとかC#とかだとコンパイルエラーになったような気がする。

階層的なデータ構造をコードで記述していく場合、
同じ名前の変数を宣言したい事がよくある。
例えばこういう画面レイアウトの構造を定義したい時、
--------------------------

[button1]　　(空き)　　[button2]

--------------------------
　　　　　　[button3]
　　　　　　　(空き)
　　　　　　[button4]
-------------------------
こんな感じの定義方法を思いついた。
{ void *resource; lay_t lay = layout_create();
{ lay_t vert = layout_push_vertical(lay);
{ lay_t vert2 = layout_push_vertical(vert);
layout_push_control(vert2, "button1");
layout_push_blank(vert2);
layout_push_control(vert2, "button2"); }
{ lay_t horiz = layout_push_horizontal(vert);
layout_push_control(horiz, "button3");
layout_push_blank(horiz);
layout_push_control(horiz, "button4"); }}
resource = layout_make_resource(lay);
layout_destroy(lay);
return resource;
}
この時、vert2の箇所をそのままvertとしてしまったり、
さらに階層が必要になった時、その変更を元に戻したくなった時、
定義した構造ブロックを他で使いまわしたい時、
などで修正が面倒になる。
まあ適当な構造記述言語でも作ればいいんだけど。

ごめん、上で定義した構造は↓の間違い。
--------------------------
　　　　　　[button1]
　　　　　　　(空き)
　　　　　　[button2]
--------------------------

[button3]　　(空き)　　[button4]

--------------------------

もうね、関数内でも名前空間を定義できるようにしたら万事解決だよ。
int g(int n)
{
  namespace n1
  {
    int x = f(n);
    namespace n2
    {
      int x = f(n1::x);
      namespace n3
      {
        int x = f(n1::n2::x); //C++的名前空間ならn2::xでもいけると思う
        return x;
      }
    }
  }
}
俺はこんなの欲しくないけど。

Perlだと理屈の上ではpackageでそれができる。
しかしそういうキモイ書き方使い方は見たことない。

話がズレ始めてるんで一応書いておきますが、
特別な事をしなくとも
#define letend }}
#define let1(type, var, init) \
{ type let_tmp = init; \
{ type var = let_tmp;
#define let2(type, var, init, type2, var2, init2) \
{ type let_tmp = init; type2 let_tmp2 = init2; \
{ type var = let_tmp; type2 var2 = let_tmp2;
実はこれだけでschemeのlet束縛を再現できます。(>>72おしい)

int f(int n) { return n + 1; }
int g(int x)
let2(int, x, f(x), int, y, x)
printf("x=%d, y=%d\n", x, y);
let1(int, x, f(x))
let1(int, x, f(x))
return x;
letend
letend
letend
ここでyの初期化式として使われるxはgの引数のままであり、
f(x)の影響を受けません。g(1)を実行するとx=2, y=1と
表示されることから、Schemeのletと同じ動作だと確認できます。

あーブロック2重にするのか。思いつかんかった。

コンパイラの実装の手間も考えようぜ。

標準Ｃコンパイラのソースってどこかに無料であったりするの？
それを拡張していけばいいのでは

GCCは？
すでに拡張されてるけど

tccとか

なぜ今更C言語を拡張?
D言語(gdc)やC++0x(g++)をベースに改良すればいいのに。

D言語w

>>98
D や C++ は太り過ぎだから

Cがガンダム、初期C++がゼータ、テンプレ付きC++がダブルゼータだとしたら、
百式ぐらいのをきぼんぬ
つーかシャアが乗ってそうなやつ

#include <stdio.h>
int main() {
　printf("Hello, World!\n");
　return 0;
}

とりあえず、これの拡張版はどんな感じになる？

#using <mscorlib.dll>

int main()
{
  System::Console::WriteLine("Hello, World!");
}

List x = [1,2,3,4,5];
List y = [];
for (int i=0; i < x.length; i++) {
y = x.drop(i)::y;
}

// y = [5,4,3,2,1]

import std.stdio;
void main(){
  "Hello, World".writefln();
}

おい、おまいらもっと一瞬見ただけで「それは使ってみたい」と思わせるような提案してください

#pragmaで切り替えることで新CとC++のコードを混在できる。

>>1
は夏休みに入った中学生かなんかだろ
もしかして本当に新C言語ができちゃうかも
そうしたら俺の名前って有名にならね？とか

拡張からはじめたほうがいい。
拡張しやすいフリーのコンパイラは？
gccはなんかね・・。
Ｃ言語のコアの部分だけひっぱってきて。

前方参照が欲しいなぁ。

とりあえず今までスレで出たのまとめてみた。

重要なもの
-クラス・テンプレートの追加(>>1)
-型推論と例外処理(>>47)
-マクロ強化(>>50,>>54)
-ヘッダファイルをやめる(>>80-81)
-#pragmaで新CとC++を切り替えられる(>>107)
-前方参照(>>110)

あまり重要じゃないもの
-変数名・関数名で日本語が使えるように(>>37)
-関数内でも名前空間が使えるように(>>90)

矛盾しそうなもの
-言語仕様をDやC++より軽く(>>100)

ああ、それとC言語+クラスだけでいいならObjective-Cで十分な気ガス。
あと、これらを実装するならg++かgdcをベースに要らない機能を削ってってそれを基にした方が良いと思う。

> -変数名・関数名で日本語が使えるように(>>37)
これ今の仕様でもできるっしょ。

>>112
Cで出来たっけ？C99ではできるのか？

日本語見ると、どうしても文字列リテラル内と勘違いするんだよな……

自分C#もやってるけど日本語識別子は使ったこと無いな

ＶＢＡでたまに使う＞日本語
使う理由は英語スキルが低いので名前考えるのが面倒ってだけ。

>>113
少なくとも処理系依存の範疇で可能なはず。
つまり、やれるようにしたところで規格違反にはならないということ。

それよりも個人的には全角空白を空白類文字として使用可能にしてほしい。
（もっと一般にUnicodeの空白系の文字全般を対象にすればいい）
掲示板で全角空白使ったコードをそのままコンパイルできないのは不便。

http://seclan.dll.jp/c99d/c99d03.htm#dt19990509

XML 2.0 で要素名にいろんな言語が利用できるようになったけど、これって互換性の維持や
他か国語の環境での可読性とかで酷評されてたと思う。

やっぱり日本語変数とかは勘弁して欲しいと思う。

日本国内の環境でも
enum SMAP {中居, ...};
とかで「草薙」が表示できるかできないかとかで悩まなければならないのはまずいと思うし。

>>111
>ああ、それとC言語+クラスだけでいいならObjective-Cで十分な気ガス。

残念ながら ObjC は動的型付けなので、十分とは言えない人間も居るのです。

>-前方参照(>>110)

これってどういうの？

とりあえず、クラスだけ追加してみては。

その際に、C++よりjavaを基にしてほしい。
多重継承なし。とか、
C++のクラス定義はきもい。スコープ演算子::とか？

C++の設計と進化 (D&E)によれば、最初は::ではなく . を使っていたんだが、
class X X;のようにクラス名と同名の変数が作られたときに曖昧さが起こるから、
これを回避するために::を導入したとある (§3.11.3)。

>>121
後ろで宣言したものでも使える。後方参照とも言う。
Dの例(前方参照あり):
void foo(){
  bar();
}
void bar(){
}

Cの例(前方参照無し):
void bar(void);
void foo(void){
  bar();
}
void bar(void){
}

>>121 じゃないけど、後方参照は知ってるが、後方参照の事を前方参照と呼ぶ人もいたのか
どっちが一般的なんだろ

「前”から”参照」 か 「前”を”参照」 かのどっちかなんだから、あまり気にしないほうが良いと思う。

forward referenceとback referenceが区別できないのは困ると思うけど。

前方参照　後方参照
前方宣言　後方宣言

>>124
「後ろで宣言した」と言うのが間違い。

コンパイラは「ソースを読み進めて行く」んだから、
ソースの下のほうが「前方」だよ。

勘違いしている人が多いので、後方参照とか書いてあるバカ本があったりする。

なるほろ
視点はあくまでコンパイラ…と

へー、そういう解釈の一派もあるんだ…

先読みって言い方はするね

>>131 バカ本著者乙 (w

>>133
誤爆？

まともに(？）煽っていて誤爆に見えないが。

まともには見えないが。

それはあなたが無知だからです。

>>133 を読むのに知識が必要とは思えないが。

>>135を読み取る知識が無かったということです。

>>135 が言っているのはこういう事でしょ。

1. >>133 は煽っている
2. >>133 の煽りは煽りとしては特に不可解な所は無い
3. よって >>133 は誤爆ではない

俺は >>133 は煽りとして不可解だと感じたから、誤爆だろうと思った。
あまり知性も感じられない書き込みだし、よく誤爆する人間なんだろうと。

知力のない人間が知性のない人間に突っ込んだわけだ

単に136が135の「まとも」の使い方を誤読しただけ

>>142
>>140 が >>135 の意図した事と異なるのであれば、
>>135 がまともな日本語でないのが原因だよ。
まともに相手してあげた俺がバカだったみたいだね。

なぜか140の話を始める阿呆がいる

いちいち阿呆とか馬鹿とか付けないと文章書けない人か

C言語はハードに近い部分を記述することができますが
最近の言語では、それは無くなってきていますね。
良いことか分かりませんが。

>>131=>>134=>>136=>>138=>>140=>>143=>>145 自演乙

>>146
> 最近の言語では、それは無くなってきていますね。

FORTRAN の時代からハードに近い部分は高級言語では書けなかったけど？

>>147
自演つーか、明らかに全部俺だけど…
もしかして今まで気付いてなかったのか？
大丈夫？

>>146
148という訳で、むしろCのほうが異例とさえ言える。

>>147は自分が正しいと思ったら絶対曲げないタイプでしょ？

OS が書ける言語ならハードに近い部分も書けるんじゃないのかな。
Pascal, Oberon, Lisp, Smalltalk, C++, etc...

c言語+gcc拡張で書き直されたosのsetup codeの例
http://kerneltrap.org/node/11754
http://lkml.org/lkml/2007/7/11/362

それでもまだアセンブラ(*.S)な部分があるのがなんだかなぁだが。

個人的には、コンパイラに強く依存するくらいならアセンブラで書いた方が良いな

アセンブラはＣＰＵに強く依存しないか？

それがアセンブラで書くべき局面なら躊躇無くアセンブラで書くよ

移植性がなくても、可読性や保守性の点で高級言語を使う利点もあるでしょ。

コンサバじゃないGC

>>151
間違ってると言うなら、ソースつきで反論どうぞ。
バカ本はダメだよ。(w

>>152
Pascal と Lisp には標準ではハードを直接触る機能はないと思ったけど。

Oberon, Smalltalk は使ってことないからよくわからんが。

頭固い奴だな
OSのアセンブラコードを吐くプログラム書けばいいじゃん

それを実行時にやるというなら、生成したコードを実行するために、
任意のアドレスへジャンプもしくは関数呼出などができる機能を
持っている必要があるという制約が生じるね。

頭固い奴だな
実行ファイル吐く(略

ようするにブートストラップという概念を知らんのね。

Lisp も弄った事無いで話してそうだな

>>163
ブートキャンプしか知りません。

>>159
本云々じゃなくて、お前の人間性な

>>160
ＯＳのアセンブラコードってなんだ？

自分用語は、ご自身のブログだけにしといてくれ。

>>166
反論できないから、人格攻撃か。

わかりやすい奴だな。(w

>>147に対する「ソース付きの反論」って
どんなのを想定してたんだろう、この子。

恐らく本人も良く分かってないのではないかな
脊髄反射で何となく汚い言葉を並べているだけでしょう
だいぶ前から会話が成立していない様ですし

>>167
じゃあさ、お前1冊でも本書いてみろよ
俺様が添削してやるから

>>168-169
反論できないから、人格攻撃か。

わかりやすい奴だな。(w

# 夜中まで乙。

>>170
指摘されたぐらいでそんなに熱くなるな。

以上、言い負けてから先が威勢の良い典型的な厨房でした。

簡単な技術の話も出来ないなら他所へ行ったら良いのにな。

それはさておき、C に機能を追加する話題ばかりだったけど、
C から取り除いた方が良いと思われる機能は無いのかな。

>>172-173
> 典型的な厨房でした。

反論できないから、人格攻撃か。
わかりやすい奴だな。

> 簡単な技術の話も出来ないなら他所へ行ったら良いのにな。

で、おまえ等 (一人かも知れんが) のレスのどこに技術の話があるんだ？

反論したければ、単に >>129 の解釈に対する反例をあげれば済む話なのに
できないからうだうだ言ってるんだろ？

そんな下らない事で息巻いてたのか…

>>174
>で、おまえ等 (一人かも知れんが) のレスのどこに技術の話があるんだ？

俺じゃなくてさ、>>159 の書いてる事が素人っぽかったからね。
「Oberon, Smalltalk は使ってことない」らしいけど、Pascal と Lisp も
殆ど知らないんだろうなと思って。

>>175
へ〜、君はもっと凄いことについてレスしてるつもりだったんだ。
詳しく説明してくれるかな？

>>176
> Pascal と Lisp も殆ど知らないんだろうなと思って。

そう思うなら、どこか素人っぽいか指摘すればいいだけ。

指摘もできないから、「知らないんだろうな」とか言う技術的じゃ
ないことしか書けないんだろ？

# まさか、「OSのアセンブラコードを吐く」なんて言うわけわかめ
# のことを言ってた奴が絡んでるのかなぁ...。(w

この人、リアルでは孤独なんだろうな。。

おやまあ

シャープマンはそろそろおとなしくしてね

"ハードに近い"の定義がされてないのに何この荒れよう。
人によってリアルモードのことだったり割り込みのことだったりしそう。
#リンカスクリプトを言語に統合まだー?

自分でやれよｗｗｗｗｗｗｗｗｗ

>>177
「OSの」は余計って事か。ごめんね。
書いたときは>>152以前は読んでなかったから、OSでも書くつもりなのかと思ってたよ。
>>161には話通じてるみたいだし、スルーされたと思って放置してた。
どのみちファイルに出力できる言語なら何でもできるだろ、
って事を>>148みたいな人へ言いたかったんだけど。

ホントにどんな事にでも噛み付いてくる奴は居るもんだな

夏だからな

>>178-180, >>184-185
「技術的に指摘して」って言ったらこの様ですか...。

まあ、>>185 が言う通り 夏 なんだろうな。

>>181
> "ハードに近い"の定義がされてないのに何この荒れよう。

まあ、最低限として任意のメモリの読み書きができないとダメだろうな。

て言うか、リアルモードとか割り込みなんて事まで言い出すと特定プロセサ
シリーズ専用の言語になるから「標準」でと言うのはないだろうな。

>>183
単に茶化しただけだ、気にしないくれ。

そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
大変面倒なので実際的じゃないという意味) だろ？

て言うか、このスレ自体がネタスレだし...。

> どのみちファイルに出力できる言語なら何でもできるだろ、

>>161 が指摘してる通りそのファイルを実行する手段が必要。
標準の言語仕様としてその機能を持ってる言語ってそんなに多くないよ。

>>186
餌欲しい？

>>186
各arch毎に言語拡張すれば良くね?

>>186
言語仕様に含まれてなくとも、大抵は処理系毎にFFIとかが整備されてるもんだよ。
C言語にしてもasmは標準ではないし、C言語で適当なバイト列を関数アドレスとして
キャストして実行できたりするのも処理系が「たまたま」許してるだけ。
そんな所を君がごちゃ混ぜに語っているのが、分かってないのでは
と言われる理由かと。

>186
>そもそも、>>160 の書き込み自体洒落 (=原理的には可能だけど、実施が
>大変面倒なので実際的じゃないという意味) だろ？

大変面倒というのは君の主観でしかないよね。
そういうのは一度作ってしまえばその環境で使いまわせるし、
やることも極めて単純な変換作業だよ。
エミュレータやコンパイラ作ったりする人なら普通に思いつく発想。
で、

>て言うか、このスレ自体がネタスレだし...。

このスレは仮にも「新C言語を作ろう」なんだから、その程度を、
大変面倒と言ってしまうレベルの人間の横槍は遠慮してもらいたい。

>>173
ないわけではないよ>>48-61。


>>188
似たようなこととして、DがCPU毎にインラインアセンブリを定めていたはず。

>>191
D言語のインラインアセンブラはx86しか(ry
gdcは他のarchの為にasm(gasの文字列);に対応してるけど。

>>188
そう、実用的には処理系毎の定義と、何らかの言語拡張がなされているのが普通。

特に、ハード周りとかファイル関連はアーキテクチャやシステム毎の差異が大きいので
標準の言語仕様では定義してない方が多い。

Ｃ言語は、PDP + Unix と言うある意味特定環境用の言語として作られたから生い立ちと
して他の言語に比べてそこら辺の定義が比較的されていたんだ。

>>189 の言うキャストなんかも、アーキテクチャが決まっていたから許されていたが、
8086 + DOS みたいにメモリモデルによっては関数へのポインタとデータへのポインタで
ビット幅が違うなんて言う変態的なアーキテクチャだと破綻するので言語仕様からはず
されただけ。

>>189
そういう突込みを避けるために、わざわざ゛>>159 に「標準では」って
言う言葉を入れてあるんだが。

> そんな所を君がごちゃ混ぜに語っている

具体的に指摘よろしく。

>>190
まあ、ちょっと落ち着け。

そういう仕組みを作るのが面倒じゃなくて、単に「ハードに触る」だけで、ファイル作っ
てそれを実行して (必要に応じて結果を) 得るって言うことが面倒だ言ってるんだけど、
理解できてる？

もっと毒吐けよｗｗｗｗ

>>193
処理系毎じゃなくてarch毎に拡張の標準を決めるべきでね?

>>193
>理解できてる？
何を言ってるのかさっぱりわかりませんがその前に、
「君の主観でしかないよね」って言葉は理解してるのかな？
ともかく、何が面倒なのかを焦点に議論するのは無駄でしょう。
重要なのはどういった手法であれ、目的が達成できるかどうか。
よりベターな方法なんて後からいくらでも考えればいい。

>具体的に指摘よろしく。
自覚がないなら遠慮しておきます。
それこそ「面倒」なんで。

ANSI Common Lispという本の導入、クロージャを紹介する所でこんなのがある。

(defun addn (n) #'(lambda (x) (+ x n)))

「Cではaddnはどうなるだろう？ちょっとすぐには書けないだろう。
もっとも読者はこんなふうに思うかもしれない。大体こんなことをしたいなどと考え
たりするだろうか、と。しかし、そう考えたりしないのは、プログラミング言語が、それで
できないようなことは、やりたいと思わないように利用者を仕向けているからである。
プログラムを書く言語で考えなければならないのだから、それで書けないことをやり
たいとは考えにくい。私が初めてプログラムを書き始めたころ、それはBasicで書いて
いたのだが、再帰を使いたいなどとは考えなかった。そんなものがあることも知らな
かったのだ。私はBasicで考えていたのだ。
（中略）
(Lispを学習していく)努力の報酬として、上級のC++プログラマがBasicでの
プログラミングに感じるようなやりにくさを、C++に対して感じるようになるだろう。」

>>195
例えば、86系用だと io 命令を拡張の標準にするとか？

ちょっとおもしろいかもしれない。

>>196
> 何を言ってるのかさっぱりわかりませんが

ああ、理解できてないなら別にもういいよ。

別に君の意見に反対する気はないし、そういう人に何を言っても無駄だ
と言うことも知ってるから。

> 自覚がないなら遠慮しておきます。
> それこそ「面倒」なんで。

# 指摘できない言い訳を２行も書くのは面倒じゃないんだ...。(w

「俺はまともなんだが、どうにも馬鹿が多くて話が進まないなぁ」
と思ってるそこのキミ。それはつまりキミが馬鹿なんです。

>>198
> > 自覚がないなら遠慮しておきます。
> > それこそ「面倒」なんで。
> # 指摘できない言い訳を２行も書くのは面倒じゃないんだ...。(w
>>196のこの部分は、
「ああ、理解できてないなら別にもういいよ。
別に君の意見に反対する気はないし、そういう人に何を言っても無駄だ
と言うことも知ってるから。」
という意味のことを、それよりは少し短く言ってるだけだと思うよ。

その典型的な例がシャープ

できない言い訳に、他人の無能さを持ち出す人って饒舌だからね

>>200
はいはい、言い訳はもう結構です。

何を話してるのかはさっぱりわからんが、誰が痛いかはよくわかる。

>>204
だな。主観で話してるお前が一番痛い。

いや、そいつは二番目だ。
一番は俺だからな。

いやいや俺だ

>>207
そうだな

ここは誰が一番痛いか競うスレですかそうですか。

そうだよ
君もエントリーするかい

よろしくお願いします。
一応下記の至らぬスレの主です。

おら！Nをオトメに見つけて++Nを得るムを作らん？！
http://pc11.2ch.net/test/read.cgi/tech/1187428876/l50

ﾜﾛﾀｗ

>>211
糞スレ立てるな

>>212-213
何も成果物を作れないかもしれませんが、
気長に見てやってください。

スレ違い及び売名行為失礼しました。
逝ってきます。

酷いスレだな

・変数スコープをなくし、全てグローバルとする。
スコープとはいわば開発者に脳内スタックの確保を一段
強要する機能であり、開発の邪魔である。
変数は全て設計者が関数一覧表とそれに付随する変数一覧表にて管理する。
ローカルだからと適当に変数を作り捨てるようなことをするから
ゴミ変数が増え、バグとなる。

・ポインタの廃止。ポインタは労多くして功少なしの典型機能。
・キーワードを全て大文字化する。小文字は小さく目に悪い。

全部ボツ

>>216
COBOL でも弄ってろ無能。

>>216
要約するとガベージコレクションを付けろってことだな

>>216
異論の余地がないほど同意
ｃなんかよりBASICのほうが1億光年優れてるよな

>>220
>異論の余地がないほど同意
本人だからか？

小学校でローマ字を習うまでは大文字しか読めなかったから
BASICはできてもCはできなかった

自分は小学校でローマ字を習う以前に公文で英語やってたから小文字も読めた
でもプログラミングはやってなかった
つかPC自体が珍しい時代だった

C言語にGCとデリゲートとコルーチンっていうか、ファイバーっていうんだっけ？中断できるやつ。があれば割とすごいことになりそうな感じ。
あ、あとエクスポート可能なテンプレートかジェネリックスもね。

はっきり言ってクラスはなくても何とかなる。thisコールが結構べんりっちゃーべんりだけど。

>>216
ローカル変数は無いと再帰処理が出来なくて悲惨だぞ。その再帰も深くなるとばぐっちゃうけどね。
ポインタはローレベル叩くとき必要だけど、普段はあんまり恩恵ないな。イテレータにしても実用上は問題ないかもね。
キーワードは、色つきエディタ使えば解決。え！？もってないの？？？VCが無料だって言うのに。

>>216
int i; とかをグローバルにする知り合いがいたんだが、

void g(void) {
　　for (i = 0; i < Y; i++) 何かする;
}

void f(void) {
　　for (i = 0; i < X; i++) g();
}

みたいなことやってバグってハマってたな

>>216
異論の余地がないほど同意
ｃなんかよりBASICのほうが1億光年優れてるよな

同意するなら異論に反論してからにすれば

B　　　　A　　　　S　　　　　I　　　　　　C

俺の専ブラが>>216をグロ判定したんだけど

暇があったら俺のじゃんけんプログラム倒してくれ。

＊N８８互換BASICを使っている人・・・・
ttp://pc11.2ch.net/test/read.cgi/tech/1189476569/l50　の　24　参照

タートルグラフィックを準標準に入れてくれないかねぇ。
任意で実装って感じでさ。
あれこそ、コンピュータグラフィックスだよ。

ただのタートルグラフィックじゃだめだな。
3次元に拡張して、タートルがグリグリ動く奴でヨロ。

よし、ゲーム向け言語


　　#include<game.h>
　　
　　int main()
　　{
　　　　CreateGame(CG_SHOOTING)
　　　　return 0;
　　}


これでシューティングゲームができる言語を作ってみそ

無理だろうけど
#iconfile iconfilename
と書くと作成される実行ファイルにiconfilenameで指定したアイコンファイルが関連付けられる機能

break+数字で複数のループを抜ける。

while(1) { /* ループ１ */
　　　while(1) { /* ループ２ */
　　　　　break2;
　　　}
}

gotoでいいじゃん。

>>236
ＵＷＳＣで使えるけど便利だよね。

あと、forループで規定回数で抜けるのと途中で抜けるのとをスイッチするオプションがあれば・・・
あ、普通にフラグとスイッチ使えばいっか。

>>236
数字はやだ、ラベルにしてくれ。

Loop:
　while(1) { /* ループ１ */
　　while(1) { /* ループ２ */
　　　break Loop;
　　}
　}

それ gotoって言うんだよ

そんなこと言い出したから、while だって、if + goto なわけだが。

>>239
まんまD言語な件。いや、Javaでもあったかな。

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;
}

あげもかねてＣ言語ネタ投稿　実際にはコンパイルできないソースファイル

#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;
}

printf("私は弱者を愛し、守っていきます。");

紳士言語

>>245
ここではスレ違いの内容だよ
そういう書き込みは“適当に作ったC言語の関数を貼っていくスレ”の方で。

>>225
関数の引数を増やしてそれをローカル変数代りにすればOK。
216が関数の引数もなくせ、と言っているなら知らんが...。

>>241
if + goto + goto だと思うが。

>>248
大抵のコンパイラは

　goto L1
L2:
　...
　if(...) goto L2

に展開するから、goto + if + goto が正しいな。

って言うか、５ヵ月近く前のレスにレスするほどの内容か？

ラベル付け忘れた... orz

　goto L1
L2:
　...
L1:
　if(...) goto L2

>>249
どうしてもレスつけたかったんです、勘弁してください。

>>1
やる気があるなら、予約語を全部排除して、
全部自前で定義できるようにしてくれ。
そういう仕様なら乗ってやる。

>>252
予約語を自前で定義して何の得があるんだよｗｗｗｗｗ

>>252
PL/I思い出した

>>252

俺様専用の俺言語が定義できる。

schemeでいいよ

D言語でいいよ

boolは欲しいな。あれ、追加されてたんだっけか。
あと、複素数型とか、HLSLみたいにベクトル扱いやすくする機能も欲しい。
数値計算に特化すれば需要あるんじゃね？

そんなのよりステータスレジスタを抽象化して見れるようにしてほしい
わざわざアセンブラで書く手間を減らすために

>258
_Bool と _Complex は C99 で追加されている。

>>259 無いプロセッサはどうすんだよw

ttp://d.hatena.ne.jp/textfile/20090128/lang
こんなのもあるんだな
1つ目のリンクは切れてるみたいだけど

Ｃ++のように無秩序に機能を増やすのではなく、
Cの良さを守りつつ、Cと同じ次元でより使いやすいCを作りたい。

名づけてC+

・オブジェクト指向（クラスその他）は導入せず。
・当然ガベコレなんてついてない。
・標準関数ライブラリは古くなってしまったので全面改訂。
・文字列を扱うstring型の追加。文字列の扱いに関しては全面強化。
・配列・ポインタは当然維持。ただし分かりにくい構文は改訂する。
　（配列は int[] array; のように宣言を行うようにする。ポインタも long* x, y; だと*は型名に付いているとする。）
・malloc関数, free関数のキーワード昇格。
・namespace導入。
・ヘッダファイルは不要に。関数プロトタイプ宣言不要。

> 名づけてC+

+ は単項演算子じゃないから文法エラーとか

互換性は捨てるのね…。

>>263
>・当然ガベコレなんてついてない。
けど
>・文字列を扱うstring型の追加。
なのか。遅そうだな。

>263
なんかCycloneのサブセットな気が。

cycloneってこれ？
ttp://cyclone.thelanguage.org/

GCと境界チェックさえつけてくれればおｋ

>>263 に型周りの強化(強力な型推論、総称型)が入れば十分かなと思う。

いろんな言語混在できる言語で。

いろいろつけるから、ごちゃごちゃして、使いづらくバグの温床になる。
いっそのこと、ばっさり機能を削ぎ落とすのがよろしい。でも低レベルな操作は行いたい。
というわけで、新仕様を次のようにする。

--
void main()
{
asm文の繰り返しのみ;
}

--
以上。変数も条件文もgoto文も制御構造も何も無いので、覚えやすい。

null終端文字列じゃなくて、文字数で管理するようにしようぜ
いや現状のCでも文字数で管理は可能だけど、標準ライブラリがnull終端前提じゃん

標準ライブラリ以前に、文字列定数が文字数で管理するような形になら
ないから、現状のＣでそういうことやるのは激しく困難だと思う。

>>273
Pascalでよくね？

>>272
各種ジャンプがあるだろ。

perlのコードが混ざっててもエラーにならないように作ってくれ

>>273
pascal キーワードを導入すればいい。

string cstr = "This is a C string." ; // ヌル終端の標準C文字列型
pascal string pastr = P"This is a Pascal string."; // 先頭がバイト数のPascal文字列型

いっそのことコンパイラ作りに特化した仕様にしちゃえYO
その後は各自自分仕様の言語を作ると

これからの時代は予約語オーバーロードですよ

>>280
それは凶悪すぎるだろうｗｗ

C#からもってこれそうなのある？

予約語オーバーロード

組み込み型に対する演算子オーバーロード

匿名メソッド (関数ポインタ)

型水路

CMカット

既存のCのソースを利用したりCへ必ず変換できる言語にしたい。
文法はCと非互換でよい。
現状のマクロをなんとかしたい。
短い記述で濃い内容を書きたい。

スクリプトっぽく書けるようにしたい。

グローバルに
puts("hoge");
って書けば

int main(){
 puts("hoge");
}
と同じ意味にしたい。

do-whileって判定を後ろに書くのが人気無いよね。
前に書けるようにするか。
他言語ではbefore until after untilの構文どうなってるかな。

for(int i=0;i<n;++i)
は定型化してるから、もっと単純化できる。
いい構文ある？

JavaScriptっぽく;(セミコロン)の省略できたっていいよな。
Pythonっぽくインデントでブロック作れてもいいよな。

いずれも問題点や文句言う奴がいるがうまく丸く収まんないかな。

>>285
qsort,signalなんかで使えたらうれしいよね。

GCとかの実行時のサポートに頼らない範囲で、出来る限り高水準な言語を作るというのが面白そう
強力な型システムやメタプログラミング能力を用意して、少なくとも無名関数くらいはGCのある言語に近い気楽さで書けるように
一番の問題はたぶんメモリ管理だけど、線形型を使ってなんとかできないだろうか

>>283
予約語オーバーライドができる言語なら知ってるんだが

#define ですね、わかります

#define内で#defineや#ifとかが使えればいいのに

そうかなあ

いろんなとこから仕様はいただいて、テキトーに短くしたらこうなった

c/Hello{
static v/main(str[] args) >> pub{
printw("Hello,World!");
}
}

いじくるつくーるなら for(0,i<n) { (命令文) }; という構文がある。
たぶんＣ言語では無理。

D言語ならforeach(i;0..n)でおk

指定したハンドルのレジストリキーに関する情報を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);

というかOSがかける程度に強力であり、
かつ高尚で可読性に優れたものが書けるならいうことなしだ

そうするとおもいっきりModula-2になるわけだが。

だからあのｷﾓｲbegin〜end構文を｛〜｝の構文にして、
コンパイラの実装がしやすく、またプログラミング初心者も覚えやすいような
簡潔な文法があればいい。
あとこれは個人的意見だけど、できるだけソースコードは短く書けたほうがいい。
じぶんのキーボードの打ち方が間違ってるのだろうけど、腱鞘炎になりかけたことがあるから。

>>291
ちなみにこれについてちょいと思い付いたので書いておく。
型宣言した時点でその型の初期値に初期化されるとして…
for((int i)++ < 5){
//....
}

Inferno って OS で使われてる limboo はどう?

>>305
後でちょいと調べてみる。

ついでに>>236>>239について思いついたので書いておく。
nest(1)://"nest"とは入れ子という意味。
while(..){
nest(2):
while(..){
break(1);//nest(1)のループを抜ける
}
}

>>278
これについては、
C言語文字列
nullStr
Pascal文字列
byteStr
とすればいい。
この用途のみでPascalキーワードが存在するのは許せない。
あと、306は私だ。

取りあえず考えてみた。
１.変数宣言
変数宣言はC言語のそれとは全く逆。
例)x int;
これは英語の文法にあわせて読みやすくしたため。
２.ポインタ
ポインタは次のように宣言。
例)p: point(int);
or
p: int:;
続きは家に帰ってから。

３.代入演算子
代入演算子には
:=
を使用する。
例)
a int:=5;
３.比較演算子
比較演算子には
=
を使用する。
例)
if(x=0){
...
}

C言語への不満ってそういうところじゃねーと思うが。
例えば実行時のコンテキストとソースコード上のlexicalなコンテキストが同一で
あるところとかそういうモデルな部分に革新が必要なんじゃないか？
読みやすさも大事だと思うがそういうのはおれスクリプト言語でやってればよし。

>>310
なるほどねぇ…
確かにそうかもしれない。
その抜本的な改革についてちょっと考えてみるよ。
それと、ポインタ型の宣言について、
p: point(int);
よりも
p point(int);
こっちの方がいいかな？

ただこうするとpがポインタ型と言うことが分かりにくくなってミスが増えるかも。

あと一つ質問。

匿名メソッドは必要かね？と言うかデリゲートは必要か？

今からなら新C言語はC言語をベースにするよりD言語からクラス抜いたものをベースにした方が良いと思われ。それにビットフィールドとかC99とかgccの拡張部分とか足してきゃいいよ。
ポインタの実体化はDelphiのがいい。
関数の戻り値の型の書き方はC++0xやEMACScript4で提案されているような後置も特殊化用引数(テンプレート/ジェネリックパラメタ)を戻り値の型より前に持ってくるという点で一理あるが、読みやすさという点では従来の方が高い。まぁ難しい所だね。

>>313
わし的には、
ベースはC言語
クラス、インタフェース、また必要であればデリゲートなどの匿名メソッドの導入(個人的にアレは嫌いだ)
強力な型推論の導入
メモリ管理にはガベージコレクタは用いず、malloc/new･free/delete演算子を使用
ポインタは廃止しない(廃止すると複雑なデータ構造がつくれなくなる。)
文法の抜本的な変更
nullchar/bytechar型の導入
を考えていたのだが…(ついでに名前はシーキューブ。C3またはCqbと書く)

D言語かぁ…
それもありだね。
そしたら名前はD++かな？

>>314
D言語は
-class、interface、delegate全てある
-変数初期化時・関数の戻り値の型推論がある
-ポインタも当然ある。
-invariant(char)* (C言語の文字列)とinvariant(char)[] (Pascalの文字列)がある
まぁ違う所は
-メモリ管理はGC基本でマニュアル管理はカスタムアロケータがある
-文法はC言語由来が多い。
って所か。

>>315
となるとD言語からGCを取り外しただけの言語になるわな。

なんか「これがほしい！」って言うのはないの？

D言語は細かい所がなおざりだから、改善すべき点は文法も含め多いと思うよ。

そういえば、マクロのこと書きそびれてた。
マクロは#〜で定義され複数行をサポートする。
例)
#hoge
...
#hoge end

303 はもういないの？

ごめん。この間まで期末テストで今は風邪でダウン中。

追記:

明日から4日ぐらいはずっと学校が休みなのでこのスレに張り付いていられると思います。

とりあえず現状どうなってんのか、まとめみたいなのがほしいかな

構文変えるなら利点と欠点まとめてほしい。
忘れないで欲しいのが、パーサによる解析しやすさ、IDEによる入力支援の効きやすさ、他人による読みやすさ、データの流れの追いやすさ、書きやすさ。

>パーサによる解析しやすさ
こんなこと考えるから C の宣言は判り難くなったんだ。

>>322
了解です。今から書きます。

>>323
>>303でも書いたように
> コンパイラの実装がしやすい
言語にしたいと思ってはいるのでできれば解析はしやすくしたいと思っています。
しかし>>324さんが述べているように構文の読みやすさ、書きやすさなんかを
犠牲にするのはちょっとカンベン･･･
というわけでもしかしたらその点は犠牲になる可能性があります。

とりあえず今のところ(私の中で)決まっている言語仕様:
1.変数宣言
変数は次のようにして宣言される
x int;
利点:英語に従った文法なので初心者が読みやすくなる。
欠点:Cに慣れた人は確実に間違えてエラーを多発させる要因になる。
2.クラス・関数の定義
クラス・関数は次のようにして定義
c/hoge{
void hogehoge(){
...
}
}
クラスに内包されない関数も定義可能。
void hoge(){
...
}
int hogehoge(){
...
}
続く

続き
利点:c/〜とやると若干短くなる。
欠点:c/〜じゃ最初見た人は何かと思うかもしれない。
また実行時に実行される関数は
int main(){
...
returrn 0;
}
でOK。

3.演算子について
代入演算子
:=
比較演算子
=
!=
<
>
<=
>=
とする。(代入演算子にほんとうは<=を使いたいのだがこれじゃ間違える人が続出すると思うので今のところはこれで。今後変更の可能性大。)

利点:"==”は比較演算子ではないのでで初心者のミスが減る(一人よがりかなぁ？)
欠点:確実に間違えられる。
今日のところはここまで。

int foo[][] vs. int[][] fooな論争があるが、foo int[][] (foo is int of array of array)にしちゃうのかぁ。パーサに先読みが必要になるのでかなり速度が低下するのと、IDEの補完的にマイナス…いやこれは既に定義された名前を避けるという意味では問題ないか。
クラス定義は、"c/"を識別子にするってことかな。そうだとすると変数でcを宣言した場合に厄介なことになる。識別子にしないとなるとlexerで分離できないので速度が低下する。
演算子についてはDelphi的なので言うことは無いかな。

それと、識別子に使える記号の数は少ないので、アルファベット+記号を識別子にすること自体は賛成かな。

追記:
これはやだ･これを追加しろ･この構文はやだ等ご意見があればご自由に。
と書こうと思っていたら>>327さんがもう書いていらっしゃいました。素早い…
それはさておき、ご意見ありがとうございます。
パーサの速度にしたがってコンパイル速度も落ちるので、これは重大な問題です。しかもこれを解消するには構文を捨てないといけないという…
これについては今後なるべく早く議論して解決策を決定すべきでしょう。(この過疎スレで人が集まるかどうか…)
解決策の一つとしてはこの言語のみに特化したパーサを開発することですが、これじゃ焼け石に水です。
どうしましょうかねぇ…

幾つか意見を言わせて貰うね。

----

"c/" は、俺は否定的。

"c" + "/" として扱っても、"c/" としてまとめて扱っても、どちらにせよ 『 b := c/a; 』 が書きにくくなる。
トップレベルに書いた "c/" のみを特別扱いすれば問題ないとは思うけど、CP が悪いわな。

そんなに 100 も 200 もクラス定義するわけじゃないんだから、得られるものは少ないと思うよ。

----

変数宣言と関数宣言の型指定が正反対なのが気になるところ。

変数にあわせるならば 『 hoge() void { 〜 } 』 になるんじゃないかな。
C に慣れたひとも、VB or Pascal に慣れた人も、どちらも間違えると思うよ。
どちらかに統一すべきだと思う。

----

代入演算子、"<-" を使ってみたらどうかな。打ちにくいけど。

----

比較演算子で気になるのは、= と != の文字数が違うところかな。
細かいことだけど。

追記:
>>329というわけでこの過疎スレに議論のために人を呼び込まねばなりません。ですから、これからはage進行で行きましょう。
ってなわけでage!

>>330
すびません、リロードし忘れてましたorz
いま外出中で携帯から書き込んでるので家に帰りつくまでお待ちください。

>代入演算子、"<-"
a<-5とかそれなりに使う気がするので止めてほしい。
:=も条件演算子との兼ね合いで(識別子として扱えば問題は無いものの)読みにくくなりそう。

個人的な案。
c -> newC
= :=
== = or !!=
!= !=
< < or !>=
<= <= or !>
> > or !<=
>= >= or !<
要は、!に否定と言う意味を持たせるなら演算子そのものも否定できたらどうかな、と。
# !の多重を認め出すと、!!!!!!!!!!=なんて書けてしまうのは実は問題かもしれないw

失礼。醜かったので書き直し。
--
c → newC
=　→ :=
== → = or !!=
!= → !=
<　→ < or !>=
<= → <= or !>
>　→ > or !<=
>= → >= or !<

>>334
D言語には!>=とか普通にあるが<とは意味が違う(浮動小数点のNAN的な意味で)。

これな。
http://www.digitalmars.com/d/2.0/expression.html#floating_point_comparisons
<>とか<>=とか!<>=とかもある

今家に帰り着きました。
･･･つついてみれば意外と人がいるもんですね。

>>330
については、そこまで頭回ってなかった私の問題です。申し訳ない。
というわけで改訂版。
2.クラス・関数の定義
クラス・関数は次のようにして定義
c/hoge{
hogehoge void(){
...
}
}
クラスに内包されない関数も定義可能。
hoge void(){
...
}
hogehoge int(){
...
}

あと"c/"について。

そうですか･･･。やっぱりclass{...}にしたほうがいいですかね？
ここは議論の余地があるようです。

>>334さんのは全面採用したいですね･･･
まぁ"!"は2文字以下でという限定をつければいいと思うので。

>>338
hoge int() { ... }

って表記はどうなのかな。
変数宣言と合わせると LALR なら問題ないだろうけど、LL なら 3 くらいは欲しいよね。

>>339
なんだか考えるべきことが大量に増えてきましたね…
私はそろそろ寝たいと思います。(風邪も治したいので。)では、おやすみなさい。

>>1
C++の何が不満なのかまず説明してくれ
それが説明出来ないなら議論する価値もない

a = a + b を a += b と書けるように、
別の書き方をしたら記述量が減るなら意味があるけど、
>>334 みたいなのにどういう利点があるのかいまいちわからない。

まあでも代入と比較が:=と=なのは趣味の問題、別に構わないと思う。
Cっぽくない構文の言語なら珍しくはない。

ちょっと視野が狭すぎやしないか？
その程度の違いならC言語でいいじゃんと思ってしまう。
参考までに303 ◆pFphp4Ej4wが使えるプログラミング言語は何だい？

GNOME 用の C 言語拡張みたい

Valaについて語りませんか
http://pc11.2ch.net/test/read.cgi/linux/1246771919/

>>344
私が使えるのですか？
ObjectPascal
Java
C言語
C++
D言語は現在勉強中。

>>341
たしかにそこは聞きたいな。C++でなくてもいいけど。
今あるCの後継的な雰囲気の言語のどこがまずいと考えていて、
どう直そうとしているのか。それによって何が良くなるのか。
誰（言語ユーザ、コンパイラ制作者、ライブラリ制作者、IDE、etc）が得するのかなどなど……。

代入演算子変えるなら、もはや「新C言語」じゃないのでは？

>>348
それいっちゃオシマイです…
それと、>>305についていまさらながら調べてみました。
LimbooというのはC言語の作者が設計したPascalライクなC言語のようです。
やはりC言語をつくった人にも思うとこがあったのですかねぇ…

演算子なんてjavascript程度が用意してるので十分だと思うんだよね。
そんなに既存のcやその他追随してる言語に不都合な点があるのかな。

>>350
Perlまで増やせとは言わんが、ECMAScript 3程度じゃ全然足りん。

演算子いらね, 結局 (+ x y) の 2 引数関数じゃん

もっと三項演算子を増やせとな?

宣言以外の文を無くして全部式にしようぜ

>>354
それじゃ関数型言語そっくりに…

どうもわたしは規制に巻き込まれたようです。
何もしてないんだけどな…
こういうもんなんですかね？

そういうもんです。

ぶっちゃけ、既存の言語を超えようとしたり、改善しようとしたりするのが間違ってると思う。
自分が作りたいものを作りたいように作ればいいんじゃないかな。俺はそれで満足する。

>>356
目的が自分が満足するためならそれでいいのだろうけど。

>>356
確かに。それの見本がC++ですね。

>>349
LimbooじゃなくてLimboだよ。w
Limbo は並行計算が目玉と思われ。Erlangよりずっと分かりやすい。
C言語の悪評極まる宣言についてはリッチー先生さすがに反省したようで
Pascal風に直してあるね。
Limboに先行してAlefという言語もある。

>>359
すいません。おっちょこちょいなもんで…

なんか規制解除されてるかわかんないので携帯から書き込みます。

４.基本構文
４.１for構文
for構文とは指定した回数だけその命令を繰り返す構文である。
for構文は次のように定義する。
(とりあえず3回繰り返す場合。)
for((i int)++ < 3){
...
}

>>361
ま、間違えた…
４じゃなくて３だった…

あと、言いそびれてましたが変数は定義したときにその変数の初期値に初期化されます。

指定した回数繰り返すと言うのなら、<演算子を使う必要はないのでは？
<が出て来るということは、今のCのforみたいにwhileのような自由な条件指定を許すように思える。
それなのに、361の文章では、「指定した回数繰り返す」と言い切っている点が気になる。
単に、今のCのforみたいに、主に指定回数の繰り返しに使われるというのなら理解できるけど。

例えば、BasicのFor i = 0 To 2やRubyの3.timesなんかが
比較演算子を使わずに繰り返しの構文を実現している。
（もちろん、どっちもwhileが別にある）

MATLABの構文もそんな感じだったな
for i = 1 : 1 :10
1ずつ増やしながら1〜10まで繰り返すみたいな

fortranっぽい配列使えるようにしてくれ

>>363
ぬわぁ…
すみません。
毎回毎回勉強になるなぁ…
とりあえずここでは「主に指定した回数だけ繰り返される」とします。
これを踏まえて一つ質問を。
ある命令を指定した回数のみ実行するのみの構文は必要でしょうか？

どういう方向性か知らないけど、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の出番なんてぐっと少なくなるし。

逆に何でそれがいるのかが聞きたい

>>346
やはり似たような言語ばっかりだね。
limboがでてたけど、そんな感じの根本的に違う思想の
言語を一度勉強した方が参考になると思うよ。
特に関数プログラミング系は必須といっていいと思う。
listかschemeは当然だし、また実行効率の良さはMLとその派生も勉強になるものが多い。
C言語の拡張でいうとcycloneとかも見てみるといい。
あれはCの実行効率の良さを維持しつつ型安全性を組み入れてる。
そういうのみるとはっきり言って俺for文とかどうでもいい話に思えるよ。
バカにするつもりはないけどもう少し見聞を広げるべき。

・C/C++
・Pascal
・Smalltalk
・Self
・Io
・Lisp, Scheme
・Haskell
・Prolog
・Erlang
・ConcurrentClean
・GHC/KL1
・BrainF*ck, Unlambda
・SKI combinator

これくらい見聞きすれば新しい世界が開けるよ

>>371
その中で一つ選ぶならやっぱり Lisp だね。
常用する気にはなれないけど、学ぶ事は多かった。

やっぱり並列プログラミングが安全で簡潔に書ける言語がほしいね。
単純なスレッドむき出しじゃないやつで。

>>371
D(メタプログラミング・関数乗っ取り対抗策など)とかC#(LINQ)とかCω(スレッド周り)とかECMAScript3/ECMAScript4(プロトタイプ思考)とかJava(命名規則など)とかも必要。
誰か言語の良い所・悪い所をまとめてほしいかも。んで良いとこ取りすればおk。

つーかC言語の後継であるなら、OSが書ける、デバドラが書ける、
とかそういうのが目的の言語であってほしい。
なんでもあり言語はPL/Iみたくなってうまくいかないでしょ。

>>374
自分は、客観的な各言語の評価よりも、
303自身の主観でのCとその後に続く言語（>>346の中ではC++/Java/Dの）の評価を聞きたいな。

>>375
PL/Iが普及しなかった理由はそういうことでは無いけど(MulticsはPL/Iで書かれている)、整理はされてて欲しいね。

>>376
そうですねぇ…
Java
一番最初に使ったオブジェクト指向の言語です。
はっきり言ってしまうとかなりわかりやすく、簡単･便利で初心者に最適な言語だったと思います。
ただ、プログラマのもつ能力に足かせをはかせてるような感じがします。あと、私は結構パフォーマンスを気にするたちなので(ただの貧乏性)VMを使うせいで速度が遅い･メモリを触れないJavaはなんだか性にあいません。
C++
ポインタを理解するまでかなり時間を食いました。(C言語を始める前だった)
Javaだとそこら辺は巧妙にかくされてます。
ただ、C言語のようにプログラマのもつ能力を最大限生かせる点と速度がかなり速い点については最高だと思います。(これでコンパイルが速ければ…)
D言語
まだまだ学んでる途中なので細かいことは言えませんが、C++とJavaを足して2で割ったような言語です。
GCがついている以外に不満な点は特にありません。

つまりまとめちゃうと取りあえず私は、今あるC言語系の構文にこれといった不満をもっていません。
はっきりいうとこれまでだしてきた変数宣言や様々な構文は私が本心から考えているものではありません。ただ初心者に優しいであろうと思うもののみをあげているだけです。
ぶっちゃけJavaみたいに初心者に優しくて、Dみたくコンパイルが速くて、C++みたく柔軟な使い方ができて実行速度が速い言語なら私はそれでいいのです。

とりあえず、「新C言語」という名前をやめてほしい。
こういう名前をつければ、スレッドの客寄せにはいいだろうが、
構想はまったくCと違う方向に進んでいる。

世の中で、C言語の改良版が欲しい人たちは、
Cとまったく違う変な構文なんて望んでいないはずだ。
まったく別の名前でまったく別の理念でやってくれ。

Ｇ言語

新C言語としてOCamlを開発すればよい

>>380
自慰言語ですね。わかります

コンパイル速度まで評価対象になるのなら、実装方法もコミで考えてかないと。
単にこんな機能が欲しい！だけじゃダメだろ。

つーか、Cでのちょっとした不満とか良くないところの改善っていう目的を忘れたらあかん。

コンパイラ屋さんの俺が来ましたよ。
専門は最適化なのでそっちしか興味ないんだけど、簡単なCへのトランスレータくらいだったら作ってみようかな〜

>>384
ってなわけでじゃんじゃかC言語の悪いところを書き出してってください

>>385
ぜひともお願いします(まだ言語仕様さえも決まってませんが･･･)

とりあえず文法を FIX しよう。話はそれからだ。

あと、名称も FIX しないとね。

はじめてきたんだけど
ちょっとここまでの進捗を3行でまとめて

す
す
んでない

>>386
とりあえずただＣをパースしてＣを吐くだけのやつを明日作ってみようか。でそのパーサなり何なりをいじって文法を修正していくと。
言語ががらっと変わるなら仕様を先に練る必要があるけど

進んでないのか
また来るね

ヘッダファイルを編集するだけの簡単なお仕事です

>>391
どうもありがとうございます。よろしくお願いします。
明日は模試があるので顔をだせないかもしれませんが…

Java に乗っけたいね。JSR223 対応させて。
けど 303 にその気が無いようで残念。

Javaにのせたい気持ちがわからない

わかんない？
そいつは残念だ。

それはC言語の役割ではない

むしろJavaScriptで作ってブラウザ上に、というほうがまだ分かる。
それはともかく、やりたい人間が自分で作ればいいじゃないか、JRubyのように。

いや、作る気が無いわけじゃないんだけど、
ポインタをサポートするなら JVM の上にさらに独自の VM 乗せることになって
そこまですることになるなら俺の能力を超えるなぁ、って考えていたところ。

Java じゃなくて、JavaScript でも似たようなことが起きるはず。

Cくらい軽量で低水準な関数型言語が使いたいなー

それなら、とりあえず全変数は読み取り専用、書き換え可能な変数はmutable修飾子を付けるという方向にしよう。

>>400
runtimeなしで関数型言語作るのはかなり難しいだろう。
純粋関数型言語ならある程度可能だが。

どうも。やっと模試が終わりました。死んだ…

>>401
なるほど。
それはprivate,public修飾子を残した上で付け加えるということでよいでしょうか？

この他「これがいやだからこうしてほしい」等要望をなんなりと。

それから、取りあえず「新C言語」の名前を決めたいのですが、なんかありませんか？(時期尚早と言うなら取り下げます。)

「Ｃ」という文字を入れるか入れないか、それが問題だ。
入れなくてもいいなら、「 Zig 」とかをさっきふと思いついたり。

あと、こうしたいああしたいっていう要望聞くのは良いんだけど、
上手く舵取りして取捨選択しないと、汚い言語ができるよ。
ちゃんと設計理念ってものを自分なりに考えていかなきゃねー

>>403
いや、構文的にはCのconst/volatileの位置を考えている。

C言語のautoやregisterはキーワードとして再利用しても大丈夫だろう

const int x = 123;
mutable int x = 123;

みたいな感じか。

ここでふと聞いてみたい。
俺言語を作ろうと思ったことがある奴、実際に作ったことがある奴、どのくらいいるんだ？

ノ

>>406
とりあえずautoはC++0x同様の型推論で決定だな。

言語ってか、ＡＤＶツクールみたいなの作ろうとしたら、
どんどん言語っぽくなっていった。

Cの実行モデル的にmutablは無駄にコードを長くするだけだと思うな…

mutableね タイポ

そんじゃ夜から何か作り始めるよ。
実装言語はバリアントがあるOCamlとかの方が楽だけど誰でも改造しやすいようにJavaとかにしたほうがいいのかな？

>>403
とりあえず名前だけでも決めてくれると嬉しい。

>>413
いや、是非385自身が一番使いたい言語で実装してほしい。そっちに俺は1票を投じるぞ。

新C言語だから・・・

SINCL: SINCL Is New C Language

QINC Is Not C-language.

>>405
なるほど。いいですね。
>>413
よろしくお願いします。私はそっち方面は全くわからないのですごく助かります。
>>415
>>416
GNUですかww
他に名前の候補ありませんか？

開発コードネームはLouiseがいいです

>>418
して、その心は？

だって可愛いらしくて素敵な名前じゃないですか

Lowrise?

省略記法をたくさん作ってくれ
void引数の関数の()を省略できるとか

>>422
関数ポインタとの区別をどうする？
という問題は置いといて、それは何が嬉しくなるの？

省略が多いほうがタイプ楽でええやん

構文糖は、劇的にコード量が変わったり新たな意味が付与されるものでない限り、
あると逆に邪魔になるものが多いよ。

Java の拡張 for とか Haskell の do とかなら存在意義があるけど、
単に省略できるようにしたいだけなら、

　引数 0 個の関数呼び出しでは、() を書いてはいけない

という仕様にしたほうが、まだ収まりが良いよね。

帰宅したので今から作ります。
>>414 に甘えてOCamlで実装することにしました。
名前が決まっていないみたいだから、とりあえず一番早かったSINCLで書いとく。

新Cを作るのなら

以下2点が希望かな
　関数のファーストクラス化
　プリプロセッサの廃止とその代替機能の追加

プラスアルファするとしたら
　名前空間またはモジュール機構
　並列処理の考慮(メモリモデル等)

機能追加は最小限でいい
比較的小さなのがCの良いところ

Cは識別子の管理が激しくめんどい。
誰かに改良案考えてほしいな〜。

識別子の管理ってどこが面倒なんだっけか。

識別子の意味が文脈で変わるんだよ。
ttp://www.syuhitu.org/other/cparse/cparse.html
がとても分かりやすい。
とりあえずここのとおりに実装してる。

typedef 周りか。解決策といったら……

その１：typedef なんて無くせばいいよ！
その２：型名は大文字から始まることにすればいいよ！
その３：AST 作ってから識別子を解析すればいいよ！

くらいじゃないのかな。
文法に注意すれば、それが型名なのか変数名なのかが一意に決まるから、
とりあえず構文木作っちゃえば良いんじゃないかと思う。

>>426
頑張ってください！
>>431
typedefの消滅はちょっと…(私的には。)
だから現実的にはその2かその3が解決策だと思います。

その他ご希望をなんなりと。新C言語の名称も引き続き受け付けます。

識別子が型名か変数名か分からないとASTが作れないのが問題なんじゃないのか？

typedefの問題は構文を修正する事で解決できると思う。
typedefがstaticやexternなどと文法規則が同じだというがややこしい原因のようだ。

>>430を斜め読みもしていなくて済まないけど、
typedefの宣言そのものが面倒のか、それともtypedefされた名前を使うのが面倒なのかどっち？
前者なら、typedefを別文法で実現すればいいはず（C#/C++0xのusingなど）。
後者は、Cっぽい文法を維持する限りどうしようもないよなあ。typedef禁止にしても
C++/Java/C#みたいにclass量産できれば同じような状況になるだろうし。

>>432
ほむ。気分はわかる。

>>433
具体的に reduce/reduce 競合起こすのって、どことどこだっけ。
起こしたらその部分の文法を変えちゃえばいいんじゃないかなーと。

すぐ思いつくのは、
変数宣言int (a);と関数呼び出しf(a);の区別が付かない
キャスト(int)(a)と関数呼び出し(f)(a)の区別が付かない

とりあえずtypedefの問題は「typedefは必ず先頭に付ける」という規則があれば解決できるね。
つまり
typedef int x; などはOK
int typedef x; などはNG
にすればよい。

reduce/reduce 競合起こすところを徹底的に消していけば、
とりあえず AST 作れるから、後はどうにでもなると思う。

>>438
そういう誰も書かないやり方は新言語でも禁止してしまえ。

修飾子の順番は制限しちゃってもよさそうですね。異論あるのかな。

int staticとか禁止。
void inline f(...) { ...}
とかも禁止でいいよね？

typedefやinline -> staticやextern -> intやdouble

という順番ということにして作ります。

typedef は修飾詞なのか……
単に型名の別名を定義する構文にしちゃだめなのかな。

　typedef struct FOO { 〜 } BAR;

みたいなのも禁止で良いんじゃないかなって思う。

　struct FOO { 〜 };
　typedef struct FOO BAR;

だけ使えれば良いんじゃないかと。

というか、型名 "struct FOO" が使える理由ってなんなんだろう。
これも無くしちゃって良いんじゃない？

Javaは規約でこういう順番に書こうってのがあったはずだけど、構文で縛っても構わないと思う。
強いていればC/C++でconst char*派のほか、希にchar const*派がいるくらい。

あと、inlineは要らないと思う。registerみたいにオプティマイザの決めることになりつつある。
持っている言語も珍しいし。

寝ます。明日の午前中くらいには動くものが出来そうです。
>>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.

>　関数のファーストクラス化
意味わかって言ってんのか
>　プリプロセッサの廃止とその代替機能の追加
むしろCPPは互換性ないと困るな
わざわざC言語を選択する理由には資産の活用がある

この手のスレは最終的にLISPに向かう事は判ってるんだから
LISPをどうやってLISPっぽくないよう変形するのかを考えた方が早いぞ

>>444
全然聞かなくてOKですので。

もうさ、Javaにポインタ付けて
ネイティブに対応させればいいんじゃない?

Javaの良さは、javaDocだと思うけどな

>>447
それ何てC#のunsafe？

>>447
何というD言語

>>448
unsafe有ってもvm外せんからネイティブに対応とはならん気ガス

>>449
GCのメモリコンパクションやジェネリックが無いのが残念だな
まぁジェネリックはテンプレートである程度代用はできるが

>>450
単に実装がないだけで、言語仕様ではVMに依存していないよ。
http://www.ecma-international.org/publications/standards/Ecma-334.htm

おはようございます。すいません、今起きました。
午前中までというの取り消し。

>>445
おまえよりはわかっているから大丈夫

互換性は捨てるって言ってるんだから
負の遺産を残す必要性はない

>>451
そうなんですよね。誰かネイティブコンパイラ実装したら面白そうですね。(使いませんけど…)
>>452
急がなくてかまいませんよ。

プリプロセッサで再帰的にマクロディレクティブを解釈できたらいい。
C++テンプレートの型なし縮小版みたいなことね。

Cライクな新しい言語作るよりC++から機能削減した方が現実的じゃないだろうか。
独自警告設定ツールみたいなのを。

何でもいいが、Cに変換できればいい
C++も最初はCへのトランスレータだったし

パーサは完成して動作するようになりました。想像以上にめんどかった。
可変長引数とかビットフィールドとかいろいろ後回しにしてます。
Prettyprintを実装してトランスレータとして使えるようになったらうｐします。どこがいいかな。

現状では文法はCのサブセットになってます。
さてこれをどういじりましょうか。

>>458
激しく乙です。

これからどうしていくかはここでの議論で決まっていくでしょう。

というわけでみなさんアイデアをじゃんじゃかどうぞ。

新言語は今ある全ての言語のスーパーセットにして、こんな感じで言語を切り替えられるようにして欲しい。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にこんな機能有った気がする。

455の言うプリプロセッサ側の強化は言語自体をいじるより有効だと思う。
文脈に関係なくコードをぶった切れるのは力だ。

>>461
IDEにとって邪魔にならない？
C++やDのテンプレートやLispのマクロみたいに言語本体に組み込んだほうがいいと思うのだけど。

>>460
こんなことしたらプログラマのミスがますます増えそうですが･･･

>>461
>>462
たしかにIDEにとっちゃすごく邪魔でしょうね。
これだとすごく「IDEがつかえない」言語になりそうです･･･

>>462
そういやD言語がASTマクロを実装すると言ってたね。
これの45ページ目から。
http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

突然で悪いけど、GCを使わない理由ってなんだろう
基本は手動メモリ管理だけど解放忘れやdangling pointerをコンパイル時に弾く、って言語を考えてるんだが、
調べれば調べるほどGCで良いような気がしてきた

一応、GCの明確な欠点としては「予測不可能なタイミングで長時間実行が止まること」があるんだが、他にはないかな

弱参照やファイナライザに関する問題の洗い出しがむずかしそう

>>465
っ リージョン推論

その欠点だけならインクリメンタルGCやコンカレントGCが明確な解決方法になっちゃいそう。
欠点をもうひとつ言うならば、挙動を静的に解決できないってのが挙げられるかと思う。

>>466-467
ありがとう。結構微妙な話みたいだな
確かに静的な情報は減るけど、malloc/freeだって断片化云々の話なんかになったら静的には挙動が分からないし

ところでリージョン推論って使い物になるの？
極端な例だけど、リージョン推論をする言語でLispのインタプリタを素朴に(GCのある言語で書くのと同じように)書いたとして、
それがリークなしで動作するとは思えない(もしリークなしで動作したら実質的にGCがあるってことだよな？)
リージョン推論をするという触れ込みのJHCというHaskellコンパイラは、少なくとも俺が試した時点では目に余るほどリークしたし
やっぱりmalloc/freeをどこに入れるかはプログラマが考えないとダメなんじゃないかと思うんだが

どっかにFIFOを用意してさ、別のスレッドで解放すればいいんじゃない？

LispみたいなGC入り言語でも、malloc/freeを使わないのと同じように
GCを発生させない静的な区間を作る事はできるよ
言語で保証されてるわけでもなく、実装に詳しくないといけないけど

昨日は作業できなかったですが、今日後でアップします。

>>468
詳しく読んでないですが少なくともCポインタのある言語でリージョン推論は実装できないと思われます。
メモリは基本的に一次元なので、ポインタが一つでもあればメモリ上の
あらゆるデータがアクセスされる可能性があります。

何をうぷしてくれるん？

>>472
すこしはレスを読んでください。

>>471
乙です。

>>465
俺様アプリをつくったとき、実行時のメモリ使用量をバージョンをあげるたびに減らしていくという楽しみが消失するから。

今更だが、
>>253
C++の様な新たな機能が増えても予約語追加でない悲劇を防げる。
どっかで整合性を取る必要はあるけどな。

ようするにschemeみたいにするのね
どんどんLISPに近づくね

美しさを追求していくと、どうしてもＬＩＳＰに近づいてしまうね。
でも、新Ｃ言語ってことは静的型になるわけだから、ＬＩＳＰ風ＭＬになる？

Ｃの場合、弱い静的型付けだけど、これを強くしたらどうなるんだろう。
替わりにパターンマッチを追加して。
でも、Cの利用場面を考えると型付けは弱くないとダメなのかな。

>>474
コードの互換性が最低になる

>>468
Cycloneではポインタの機能を制限してregion-inferenceを実現してるよ。GCあるけど。

JHCに関してはアルゴリズムが調整段階でメモリリーク起すって書いてるから、もしかしたらうまくいくはずなのかもしれない。

GCがあろうとなかろうと、finally的に実行される処理をクラス定義内に書ける仕組み、
——C++デストラクタ、C#のusing/IDisposable、scopeクラスみたいなもの——は必ず欲しい。
GC管理のメモリ以外のリソースのために。

じゃあC++かC#を使えよ
このスレの趣旨はなんだ？

>>479
それって、loan patternで十分じゃない？
クロージャは必須になるが、どっちにしろクロージャは欲しいでしょ。

クロージャすなわちGCだからイラネ

コンスト/デストラクタはあったらいいけど
既存のfinallyみたいな構文は場所が離れ過ぎて読みにくすぎる
変数の前後とかにまとめて書ける形になるといい

{ void *pool = __cons__ { return malloc(1024); } __dest__ { free(pool); };
}
みたいな

これをtypedefできるといいかな
typedef void *pool_t = __cons__ { return malloc(1024); } __dest__(p) { free(p); };

{ pool_t a; // この時点で__cons__実行

} // __dest__実行

ここまで書いて、例外機構が絡むとややこしくなると判る
setjmpも。内部的にデストラクタのチェインが必要になる
強制的に未処理の__dest__部を実行するunwindとか

>>482
C# の using/IDisposable で必要十分なような。

ああLispのwith系と同じやつね

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の実体は？
}

コピーコンストラクタを用意するかはともかく、
初期のC++と同じ轍を踏むことになるね

githubにアカウントを作って現状の物を公開しました。

github.com/385

README読んで下さい。現状はCのコードをパースしてCのコードを吐くだけです。
型チェックなど一切してません。バグバグです。
まぁトイプログラムとして読んで下さい。

Cの文法の汚い部分を綺麗にしようといろいろいじりましたので、コンフリクトが沢山あります。
これらを解消するのは結構無理があるので完全にCの文法にするか、
一から文法を作り直した方がいいかもしれません。

文法をどうにかしたらクラスとか無名関数とか実装してみたいですね。
それが使いものになるかどうかは別にして個人的な興味として。

>>481
ごめん忘れていた。自分の分類では、loan patternはあり。

>>482
__dest__相当のほうは、D言語のscope(exit)が構文的に参考になると思う。

>>483
そこまで書くと、C++のクラス定義の構文糖にしか見えない。

>>489
乙です。

> これらを解消するのは結構無理があるので完全にCの文法にするか、
> 一から文法を作り直した方がいいかもしれません。Cの文法をとる場合
C++やC#のコピーみたくなる。(個人的にはこっちのほうがいい。)
完全にCの文法を捨てる場合
簡単な文法になるかもしれないが、ほかのプログラマが使ってくれることはまずない。

どっちをとりましょうか。

申し訳ない。改行入れ忘れた。

どの道Cのソース流用できないんだろうから、好きにやったほうが良いんじゃないの。

構造化プログラミング推奨ということで
gotoは捨てて
指定数のループを脱出するbreak nを入れるのはどうか

break :LABEL;

nよりbreak ラベルの方がいいな
それってgoto

データ型を即値とオブジェクトへの参照のみにするとか
そうするとGC必要かねえ

言語の可能性を狭めてどうする
gotoは必須
gccのラベル配列相当も入れるべき
アセンブラで書くしかない所を(やや)高級言語でも書けるという事に価値がある

廃止するならむしろcontinueだ
制御の流れを混乱させるだけ
continue ラベルなんてあったらどうよ
糞だろうが

continue -> next

switchのbreakを廃止して、必要なところはgotoで飛ばす・・・いや、
そうすると
case 0: case 1: case 2: case 3: case 4:
break;
みたいな楽ができない
どうせ入れるなら関数型のパータンマッチだろう

だったらループ構文自体を廃止して全部再帰かgotoでいいよ

制御構造の書式を凝っても仕方ない。
条件分岐とジャンプさえあれば極端な話どうでもいいわけだ。
それよりもデータの生存期間の方が重要だ。

case 0, 1, 2, 3, 4:
break;

Cでもスタックにあるデータの生存期間は
{}を使えば制御出来るけどな

gotoでも？

他のブロックへgoto飛ばしたらそいつの責任てことで
その処理系のエキスパートが判っててやる場合もあるから
あとは飛んで終りなのか、コンストラクタとかとも連携さすのか
インテリジェントgotoと名付けよう

gotoを抽象化したものが継続だが、
継続は一旦その場所に行かないと得られない。

ちなみに、C++だと、コンストラクタというか変数宣言を飛び越えるgotoは禁止、コンパイルエラー。
#include <string>
void f()
{
goto l;
std::string s;
l:;
}
ただし、ブロックごと飛び越える場合は問題ない。
void g()
{
goto l;
{
std::string s;
}
l:;
}

>>493
一から作り直すというのは、Cの文法を元に拡張していくのはつらいので、
一からC風文法を作り直すという意味です。
ほとんどJavaとかC#とかの真似になると思いますね。

>>496
まぁ、基本的に条件分岐と例外処理の構文さえ用意してあればgotoっていらないんですけどね…。
>>500
ごもっともです。言語の幅を狭めることはプログラマの「出来ること」をも狭めてしまう傾向にありますからね。

>>512
うにゃ。すいません。
意味を取り違えてたみたいです。

あ、あと、人が結構増えてきたのでこれからはまたsageますね。

>>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 文っぽいものを関数みたいに自分で定義できるとおもしろいかも

1 or 2 or 3 or 4 or 6..9 -> 15

そういや範囲caseってgccの拡張構文にあったな

そういうのはLISPだとすぐ試せる・・・
てか、デジャブをえらく感じるスレだ

string型が欲しい。

>>515
Scalaのパターンマッチが参考になるかもね。
ユーザ定義型を、自由にcaseに書ける。

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

「SINCL」の新しい構文の提案用テンプレ

構文名:
-----------------------
構文例:

-----------------------
メリット:
デメリット:
-----------------------
備考:

>>522
あと、SINCLは仮称ね。
別にこれでいいならいいけど。

303が何をしたいのか判らない
つまり提案しようがない
テンプレつーか一度方針をまとめてくれ

>>524に同意
LL的な構文の工夫より、
まずどんな問題を解決する言語であるのかを決めるべきだと思う。
おれ的にはとりあえず
- あくまでシステム記述言語であること
- 効率的なマルチコアプログラミングが書きやすいこと
であってほしい。

自分が実装できそうな手軽な範囲だと、ヘッダファイルを無くしたいのと、マクロを改良できるならしてみたいです。

まずはCへのトランスレータしか考えてないのでランタイムが必要な機能は無理です。

それから型推論とかですかねー

メール欄と間違えました。すいません。

言語仕様とはあんまり関係ないかもだけど、
マルチスレッドとかそういうのに対応するタイプのＣってできないかね？

>>526
型推論は地雷原だよー

foo(x) {
    return x;
}

ためしに、この関数 foo の型を求めてみい。

>>525
>>303は主に構文に不満があるんだろ
だから構文を真っ先に議論するのは自然

型推論とかいらなくね？
何でそんなのが必要なの？

Haskellっぽくてかっこいいからに決まってるだろ

>>526
関数型言語を作った事があるので分かります。
多相型をサポートしようとしたら確かに悲惨ですね〜。

ディクショナリパッシングとか考えたんですけど、Cではワード長が一定ではないので難しそうですね。
C++のtemplateのように型ごとに関数を展開するなら出来ないということもない気がしますが、ちゃんと考えてません。

>>531
あまり必要だとは思ってません。自分は実装に興味があるだけです。

>>533
へいゆー自分にアンカー付けてるぜよ。

template で多相型をサポートするなら（問題山盛りにせよ）可能だと思います。
ただ template 周りの文法と、コード生成に失敗したときのエラー表示が難点かと。

あら。

>>535
確かにその通りですね。
ただC++のテンプレートは展開しながら，型エラーになったところで初めてエラーメッセージを生成するからあんなことになるんだと思っています。
ちゃんと型検査を事前に行えるような仕様にして，型検査に通ってから展開するようにすれば多少マシにできないでしょうか。

>>529
a'->a'

>>529
C++だと戻り値の型推論は面倒だね (この場合は楽だけど)。
D言語だとこんな感じ。
import std.stdio;

auto foo(T)(T x){
  return x;
}

void main(){
  writeln(foo(10));
  writeln(foo("str"));
}

>>529
高階関数をサポートしないならa->aのみ
さもなければ多相型を含む最小の型は一意にきまるが(a->a)
この関数に適応する多相型は無限にある

型推論が全てのケースで動くなら
関数定義の際、引数と戻り値の型宣言も省略して

f(x){return x;}
g(x,y,z){return x(y(z));}

みたいにできるだろうね
C言語っぽくは見えないが

>>524
お叱りごもっともです。
>>530
フォローありがとうございます。
しかし実際のところ、私は一つか二つ爆弾投下して逃げるつもりでした。その後なんだかズルズルとここまで来てしまったので、SINCL(仮称)の方針を明示する機会がありませんでした。
また、皆さんの「プログラミング言語に求めていること」を取り込んで言語仕様を提案しようと思っていたので、「もっとプログラマの意見を聞くべきではないか」と思っていました。
そのため、方針を示さなかったし、逆に示せなかったのです。それについて不快に思ったのであれば深くお詫びします。
さて、肝心の方針についてですが、385さんとまだコンタクトをとっていないので(すいません。近日中に連絡します。)深いことは決めていません。

>>524
お叱りごもっともです。
>>530
フォローありがとうございます。
しかし実際のところ、私は一つか二つ爆弾投下して逃げるつもりでした。その後なんだかズルズルとここまで来てしまったので、SINCL(仮称)の方針を明示する機会がありませんでした。
また、皆さんの「プログラミング言語に求めていること」を取り込んで言語仕様を提案しようと思っていたので、「もっとプログラマの意見を聞くべきではないか」と思っていました。
そのため、方針を示さなかったし、逆に示せなかったのです。それについて不快に思ったのであれば深くお詫びします。
さて、肝心の方針についてですが、385さんとまだコンタクトをとっていないので(すいません。近日中に連絡します。)深いことは決めていません。
続く

すいません。携帯から二重投稿してしまいました…

ただ、私のプログラミング言語に対する哲学としては「プログラミングは楽しむべき」だし、「やりかたはいくらでもある」べきです。
また、プログラマの能力を最大限サポートするよう柔軟であるべきだと考えています。ですからそのような言語方針が示されることになるでしょう。
…どうも私は木の根っこでなく葉っぱからはじめようとしていたようです。ごめんなさい。
続く

それを踏まえた上で皆さんにお聞きします。
どのようなものをサポートした言語仕様がいいでしょうか。
皆様の意見をお聞かせください。

あんまりＣから逸脱するなら、もう新言語を作ろうスレでいいと思うｗ

周りの意見を聞くのは良い事だけど、そもそも周りは、それぞれが自分の立場で
好き勝手言ってるだけだから、それらをぜんぶ取り入れたら無法地帯になるよね。

極端な話をするなら、C + Ruby + Lisp + Haskell + Java + Smalltalk のスーパーセットを作れば
みんな満足する素晴らしい言語ができると思うよ。素晴らしすぎて誰も使わないだろうけど。


そうじゃなくて、周りの意見を聞いたうえで 「さて何を取り入れようか」 を 303 には考えてもらいたい。
というより今までの流れの中で 「これだけは捨てられない」 ってポイントが、３点くらいはすぐに挙げられると思う。

そのポイントが「方針」だと思う。まずはそれを聞かせて欲しい。

> 好き勝手言ってるだけだから、それらをぜんぶ取り入れたら無法地帯になるよね。

あぁ…それ忘れてた(；´д｀)

> そうじゃなくて、周りの意見を聞いたうえで�「さて何を取り入れようか」�を�303�には考えてもらいたい。
> というより今までの流れの中で�「これだけは捨てられない」�ってポイントが、３点くらいはすぐに挙げられると思う。

そうですねぇ…
１.マルチスレッド周りの強化
２.後方参照の導入
３.ヘッダファイルの廃止
４.クラス、テンプレートの導入
ですね。なんか545さんの意見に便乗するようで悪いのですが、これが標準ということでよろしいですか？

a ? b : c
みたいなのもっとくれ

>>546
まんまD言語じゃん。D言語からGC外すの頑張った方が良くね?

>１.マルチスレッド周りの強化
標準でTLS、推移的なimmutableやsharedあり
>２.後方参照の導入
(前方参照と言うのだがまぁいいとして)これも採用されている。
>３.ヘッダファイルの廃止
ヘッダファイルもない。
>４.クラス、テンプレートの導入
クラスもC++以上のテンプレートもある。

あんなバグ言語参考にするだけ毒

D言語の仕様がバグってるの？
それともまともなコンパイラがないだけなの？

549じゃないけど…
コンパイラのバグはまぁ多いかな。特に想定されてないと思われる組み合わせを使うとバグに遭遇しやすい。
仕様のバグもまぁぼちぼちあるが(配列リテラルのキャストとか)、直していける範囲だと思う。

ただ再実装となるとD言語は複雑過ぎてC言語へのトランスレータですら現実的じゃない気が。
dmdのソース(GPL)を改造するならともかく。

>>546
>>548でも指摘されてるけど向きはパーサ基準だから
画面の下方向が前方になるよ

>>548
そうなんですよね…
いま現在のプログラミングの研究が進んだ社会ではC言語の後継を目指そうとオブジェクト指向を取り入れるとC#かD言語になってしまうのですよねぇ…

いっそのことオブジェクト指向はばっさりと切り捨ててしまいましょうか？

新しいパラダイムを作り出すの？

>>554
訂正

〜オブジェクト指向やその他諸々を取り入れるとC#かD言語になってしまうのですよねぇ…

>>555
新しいパラダイムか。いいねぇ。
イベント駆動のパラダイムを全面に出した言語が欲しいなぁ

>>557
本当は、構造化プログラミングパラダイムであるC言語のパラダイムを受け継ごうという意味だったのだけど、それはいいなぁ…
ちょっと考えてみるね。

smalltalk

入力と出力が複数ある、時間軸を持った言語

インタプリタとしても使えるコンパイラ

そういえば
kコンパイラ使ったわ
ほとんど覚えてないけど

こーやって当初の方針からどんどん反れてガッカリ言語になるんですね。

385さん、githubにアカウント登録してメールをお送りしましたので、お読みください。

C言語の骨格はあまり変えないで欲しい。
ライブラリの話だけど、文字列バッファやファイル、ソケットとかを
一緒くたにできるようにしてほしい。
文字列をFILE *にアサインしてfprintfとかで読み書きでけるとか。
FILE *fp = string_open(buf, size, "r+b");
みたいな。
まあソケットへの適用は微妙だね。ソケットに対してfgets、ungetc
とか使えると便利ではあるけど。
ライブラリ作るのも大変だ。

>>564
メール読みましたが，別にメールで話すようなことでもないのでここに書きますね。

私は主に実装に興味があるので面白ければなんでもいいんですが、客観的に意見をいうと
「イベント駆動のパラダイムを全面に出した言語」というのがそもそもどういったものを
指しているのか良くわかりません。

イベント駆動のプログラムは大体どんな言語でも書けますし、結局のところ
コールバックを登録するだけなのだから、こんな構文があったらうれしいとかいうのも
想像できません。
並列処理のことなども考えるとイベント駆動について考えるのは重要だと思いますが、
言語の中心に据えるようなものなんでしょうか？

>>565
それ、fmemopen。今はPosix止まりだけど、今度のCの規格改定(C1X)で入る予定。
ソケットも、Unix系はfdopen、Windowsは_open_osfhandleして_fdopenでFILE*にできるのが現状。
だから、新言語のライブラリでもそう大変ではないはず。

なんでもファイル読み書きの如く扱えるのが当然という言語は多いけど、
なんだかんだでCでもそうできている。
自分はWindowsの人間なんで使ったこと無いけど、funopenやfopencookieとかも。

>>566
>「イベント駆動のパラダイムを全面に出した言語」
Reactive Programmingのこと言いたかったんじゃね?
似てるし。

だんだん自分が何したいのかわかんなくなってきました…
いったん勉強して、また出直します…

昔、C言語でOSのAPIみたいなのは使わずに、ラウンドロビンか何かで
スタック退避したりしてマルチタスクする、って本があった。
プリエンティブだったかどうか忘れたけど、
タスク切り替えのトリガは何だったかな。

>>570
fiberのこと?

microthreadって言った方がいいか。

打ち止めか・・・
やっぱり登り始めちまったようだな
LISPへの道を
この道は険しいから、相当の覚悟が必要だ

303が居なくなってしまったんで、自分で好き勝手に作って遊びます。
何かできたらここに書くかもしれないし書かないかもしれません。では。

LISPから下りはじめたらどうなる？

Cだけに未完！

綺麗なオチしてるだろ・・・
死んでるんだぜ、スレ

ま、勝つことが目的になってたら、勝てるものも勝てないよな。言語作りは奥が深いよ。

303 の悪いところは、良い所だけを考えて、それ以外の細かい部分を疎かにしていたこと、かな。
最後まで作りこんだ経験があればまた話は違ったのかもしれないけどね。

……批判してばかりもなんだし、劣化コピー前提で色々考えてみるかな。
思い立ったが吉日生活さー

>>510ってどういう事？

>>580
抽象化って言葉がバズワード化してる。

継続を得ると言っているのはおそらく
returnとかbreakとかcontinueのようなオブジェクトを得る
ということ。

You shall never return home.

>>581
バズワード化なんてしてないと思うけど。
単にキミが頭悪いだけじゃないの？
>>510の2行目の表現はちょっと意味不明なところがあるが…

言っとくけど俺は>>510じゃないよ。

みなさんどうもお久しぶりです。303です。とりあえず近況報告のみさせていただきます。

あれから自分の頭を冷やし、他の言語の仕様を調べたり、関数型言語を軽く調べたり、学んだりしていました。
そのかいあってか、私の中ではかなり具体的にSINCLの言語仕様が固まってきました。
おそらく近日中にSINCLの言語仕様案をこのスレのなかで提示することが出来ると思っております。
またSINCLの言語としての方針もそのとき示すことができるでしょう。

とりあえず今日言いたかったことはこれだけです。それでは失礼いたします。おやすみなさい。

楽しみにしてるよー

諸事情ありまして発表が大幅に遅れます。
申し訳ございません。（発表待ってる人いないと思うけどとりあえず。）

えー

みなさん、お久しぶりです。303です。
いま携帯から書き込んでいるので今後のSINCL(仮称)の方針についてお話しするに留めておきます。
当分はC言語へのトランスレーター向けの言語仕様を策定していくつもりです。これがSINCL(仮称) version1となります。
恐らく言語仕様に盛り込まれるのは
テンプレート
名前空間
半端な型推論
となるでしょう。文法はあまりC言語とは変わらなくなると思います。(一部の変態的構文のみ廃止または改訂されます。)
SINCL version2(仮称)はコンパイラ向けの言語仕様になると思います。
SINCL(仮称) version3はオブジェクト指向が盛り込まれると思います。
SINCL(仮称) version4は返り値に関数が指定できるようになると思います。
…これらが今後のSINCL(仮称)について私が抱いている青写真です。
今後このプロジェクトがどのような方向に進むかわかりませんがどうか皆様よろしくお願いします。
それでは、失礼いたします。

頑張れー

SINCLはSuper INdent C Languageの略称です

関数が返せるってのはつまりクロージャ？
どうやって実装するつもり？

クロージャを受けるオブジェクトと参照カウンタで作れる

その作り方はセンスないだろ
あくまで新C言語なんだから。

>>588
何かもうそれだとC++0xっで良くね?

>>591
>>592氏が言っているようなやり方でできると思います。
まぁversion4での話ですから、言語仕様の策定は当分先、早くても2011年頃になると思います。
ですから今から実装の話をするのはちょっと早すぎるような…
そこらへんは385氏と話さないとなんとも言えませんね…

>>594
SINCL(仮称)はオブジェクト指向でないという点が違います。(version2まで)

つまりversion3からはC++0x？

>>596
そういうことになるのかなぁ…

ただ、SINCL(仮称)=C++と言う訳ではないので同じものであるとは言えません。
ま、まだ先の話ですから。

全然目的が見えない。

>>598
目的…それは今のC言語の特徴を残しつつ、それを越えたプログラミング言語(新C言語)を、実装･言語仕様共に皆様に提供することに他ならないと私は考えています。

残したいC言語の特徴って何？

303
お前は何も作る気が無いと言ってるのと同じ
しかもまだ385に頼るつもりでいるのか？
別に誰も期待してないし、もう出てこなくていいよ

>>600
重要度の高いものから順に
1.高い移植性
2.OSさえも(アセンブリ言語を一部使用しなければならないにしても)書けてしまうという高い柔軟性
3.高いパフォーマンス性能

>>602
評論家みたいな抽象論だね。
1.と3.は要するに言語仕様に環境に依存する機能は含めない（環境の違いは
ライブラリで吸収）すること、2.は要するにポインタのことでしょ。

しかし、何もガラガラポンの全とっかえである必要は何もないと思うんだが。
Cのマズい仕様を変更し、不足している機能を補う、それで十分じゃないのか。
発展的継承って理論でもものづくりでも一番オーソドックスな進歩の方法でしょ。

Cへのトランスレータなんだから、全とっかえでは無いのじゃないかな

と、横槍

ガキじゃないんだったら否定するまえにアイデアをだせな。

おれはメモリ空間を超えられる言語がおもしろいと思うな。
OpenCLとかあるけど、仕様が現行GPUの都合で決められてて汚すぎ。
GPU以外にも例えばCell B/EのPPEとSPEがシームレスにプログラミングできるとか、
サーバクライアントのアプリががひとつのソースから作れるとか。
ランタイムをどれだけ最小限に抑えられるかがミソだと思う。

つうかこれ数年前に作り始めて途中で挫折したんだけどさ。

>>603
そういうつもりなんですが、あの文じゃわかんないか(；´д｀)

>>602
C言語へのトランスレータだった時代のC++のサブセットを再発明して、その後C++0xのサブセットを再発明するとしか見えない。
がっかりだ。

何ががっかりだよ。
じゃあお前は何をつくれるんだ？

何故そういう話になるんだか。

上から目線で否定してるのは確かにいらっとする。
建設的な話ができないやつは厨房って自覚した方がいいね。

建設的って。建設的な話題は手前の方で出したよ。
その結果がこれじゃぁね。
#あるコンパイラを弄ったことあるから協力するつもりで居たのに残念という意味合いが強い。まぁ期待しすぎただけだが。

作る本人は良いとして、これができたからと
いって、使い道はあるんだろうかね。

個人的に強力なジェネリックとかあると使ってみたい気はするが。

ネイティブ言語でのジェネリックは俺も興味あるな

>>607
ここでつくられる言語がガッカリなものになるかどうかはここで皆様が下さる助言に少なからず関わってくると思います。

あ、あと、あまり私に過度な期待をかけないほうがいいと思います。
投げ出すつもりはありませんが、所詮はどこにでもいる高校1年生ですし。

どうせ釣るんなら
ちなみに女です
とか気を利かせろよ

>>615
仕様制定のプロセスの問題について言いたいこともあるが、まぁいいや。
まずは既存の実装のソースを弄ることから始めてみるといいよ。そうしないと全体像掴めないだろうしね。C言語コンパイラのtccやD言語コンパイラのdmd辺りを弄るのがお手軽かな。
本当は分かりやすいC++実装があると良いのだけどね。
http://bellard.org/tcc/
http://ftp.digitalmars.com/dmd.2.031.zip (dmd2/src/dmd内)
#llvmのclang(cfe)とかgccとかは試してないので難しさは分からないけどざっと見ややこしそう。
#上の方で紹介されてたcycloneもソースあるようだけどもcyclone自身で書かれているようなので理解には向かない予感。

> >>615
> 仕様制定のプロセスの問題について言いたいこともあるが、まぁいいや。

言いたいことはじゃんじゃか言ってしまって結構ですよ。

とりあえず紹介して下さった実装のソースコードを見てみることにします。

>>618
>言いたいこと
後でいいや。

>ソースコードを見てみることにします
忘れてたけどこれも張っとく。
ソースコードを読むための技術
http://i.loveruby.net/ja/misc/readingcode.html
構造が分かるようになれば面白くなってくるから頑張れ。

いつから初心者が作るコンパイラスレになったんだ
別スレたててやれよ

実装知らんと仕様作れんだろjk

えーっと、とりあえずversion3とversion4については皆さんの反感がかなり強いので、このバージョンの言語仕様の策定･実装の提供は一時的に凍結いたします。

今後皆さんの要望があれば凍結が解除されると思いますが、これじゃそんなことはないだろうな(；´д｀)

>>622
頑張れ。技評の"要求を仕様化する技術・表現する技術"って本読んでおくと良いよ。プロセスの問題が分かるから。

>>623
ちょいと図書館で探して見ます。

今日本屋に行ったら、コンパイラを作るって本が売ってたな。
作例がＣフラットとかいうのｗ

今
日本屋

>>625
そういえば今年はコンパイラ関係の本が次から次へと出版されてますよね。ドラゴンブックとか。

今年はコンパイラ本の当たり年なんですかね。

ネーミング(仮)のSINCLなんだけど
Common Lisp と間違えそう

じゃあ間違えないようにCommonLisp処理系作ればいいよ

>>628
…いいかげん仮称じゃなくて正式名称をきめたいですねぇ…

もう、面倒だから"303c"でいいよ。

>>631
いやいや。ここの人たちのアドバイスがなきゃ私は言語仕様作れませんし。
それじゃ株式会社ジェーンの二の舞に…

どうせ作る気もないんだろ。
303c、TB303みたいでかっこいいじゃん。

CB-303とかパチモン臭強くした方がいい。

さて、Bは何の略にしようか。
↓

Ｃ委員長

名前って結構悩むよね
実務で変数とか関数にhogeとかつけてるとすぐにクレームが＾＾；

スレ主が決めちゃえばいいと思うんだけど「みんなで決めよう」ってことなら
開発用のコードネームをとりあえず決めちゃえばいいんじゃない？
SINCLでもいいと思うよ

仕様が決まり出してから正式名を決めれば？(アンケートとかで)

303好きな人が多いのでリアルタイム特化型にしたら
CR-303とかパチンコみたいな名前になるかも

>>636
そうします。

高校1年生でコンパイラ作れるってすごいな。
C言語のトランスレータだったら最適化フェーズはないんだろうけど。
それでもすごい。
コンパイラ構成論の勉強したの？
名前は美緒さんとかw

>CR-303
ボタン電池みたいだな。
だがそれがいい。

名前は
コンパ イラ

>>639
30mm x 3mmですね。わかります

Cの当時からlambdaが導入されてりゃC++ももっと違う言語になってたろうな。

Bool bool(a==b);
bool.
　True([](){puts("Equal")}).
　False([](){puts("Not Equal")});

こんなSmalltalkライクな構文も書ける訳だし。

生存期間の問題がある

クロージャをコピー不可にすれば大丈夫じゃね？

↑クロージャへの参照(ポインタ)のコピーだった。
関数の引数として渡すのはOK

マルチスレッドですぐ破綻するクロージャなんてない方がまし

そういう使い方ならスタティックやヒープに置けば問題ない。
要するに置き場所を選べるように作ればいい。

>>641
寧ろそれは、3mmΦ*0.3mm厚じゃないのか?
例えばCR-2016は20mmΦ*1.6mm厚だぞ。

あんま関係なさそうな話だけど、

s = hogehoge(s);

みたいなのを、

s *= hogehoge;

とかみたいに書けるってのはどうだろう。記号はともかくとして。
++がアリなら、こういうのもアリな気はする。

他の言語だとどんな文法使うんだろ。こういうのって。

>>649
それ少しも複雑性が減ってるように思えないんだけど・・・
しかも代入演算子の書き方と少しもシンメトリックじゃないってどういうことだ

a = a - b;
a = b - a;
代入演算子を使えるのは前者のみ

>>650
perlの正規表現みたいな感覚でもいいんだけど、
そういうのにふさわしい記号が思いつかない。

むしろ
s.hogehoge
ですな
追加のような単純な処理ではなく、
全体に変更を加えるような意図なら
演算子化は避けるべき

>>649
hogehoge(&s);

興味あるので落ちないように上げとく
自分としては強力なマクロが欲しい
m4ぐらいの…

あまり無理せずにマターリと！

>>655
どうもありがとうございます。自分なりにリファレンス書いたり実装をちょびちょび書いているのですが…もうすぐ学校の文化祭でして（10月）しばらく手がつけられなさそうです。

高校生がC言語ライクなコンパイラ作れるってすげーな。
理論は独学？

高校生なの？凄いな最低でも大学生かと思ってたわ

>>657
いやいやただのトランスレーターですよ。
まぁそのうちコンパイラも…

>>657
いやいや、ただのトランスレーターですよ。
まぁそのうちコンパイラも…
ただ最適化とかいれるとなると私の手におえなくなりますが…

第一こんなアホな発言ばっかりしてるのに大学生と思われてたってのは…何?

だぁっ!
二重投稿してしまった…

>>303 は大学受験に落ちる

これが303の人生で最大の偉業になるかもな

トランスレータでも構文解析の知識はいるだろうに。

その辺もすべて385にやらせようとしてたみたいだが・・・
技術者より経営者に向いてるかもよ！

ソースはどこで見れんの？

俺も以前C言語作ろうとしたんだけど
C言語て記号いろいろ使ってて、作るのめんどくなって途中で投げたんだ
printfと、if,elseまで作った時点でかなりソースが膨らんでてやる気がな････
303がどこまで作れたのか興味深い

>>664
まぁそうですが、最適化と実行ファイル生成とかがないだけ楽です。

>>666
http://github.com/385

で385氏がOCamlで書いたものが見れます…と思ったら無くなってますね…
とりあえずソースは手元にあるのでどこかうｐろだ紹介してくださればそこにあげます。

>>667
C系の言語って他のプログラミング言語より圧倒的に演算子が多いですからね…

あ。h抜き忘れた。

>>668
That page doesn't exist!ってなってる

>>668

>で385氏がOCamlで書いたものが見れます…と思ったら無くなってますね…
>とりあえずソースは手元にあるのでどこかうｐろだ紹介してくださればそこにあげます。

>>668
Wikiを作ってWikisourceみたいな使い方すればリファレンスも書けて一石二鳥

俺はもうこれで良いや。特にクロージャの追加の所。

http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1370.pdf

>>672

っ[Wiki]
http://ja.project-sincl.wikia.com/

ちょwww
ああああふぃぃいぃぃぃ 多いよ^^;

>>674
作ってくださったのですか？ありがとうございます。

atwikiとかのが無難だろ
ああそうか、わざわざ変な道を行くのがこのスレの趣旨でしたね

ウィキペディアがいろいろと普及? したので、
MediaWikiで書きたいという需要が最近増えてるが、
atwikiだとMediaWiki互換機能はかなりあやしい。

>>677
atwikiだとソースコードモードで10000行200000バイトまでしかかけないのでMediaWikiかなと。

どちらかというとpukiwiki系の方が好きだな

Pukiwiki使っているところはページの階層構造が分かりにくいことが多いと自分は感じる。
管理のしっかりしているサイトなら気にならないんだけど。

MediaWikiはカテゴリによって適当にやってもそれなりに階層構造ができているように見えるのがいい。
WikipediaやChakuWikiのような誰でも編集できるところはMediaWikiがあっていると思う。

gccを適当に拡張して本家にマージさせたら楽そうだな
アレ以上何を拡張するんだか知らんが

gccフロントエンドは結構な鬼門のイメージがあるがな

え、何？
LLVM のフロントエンドを作りたいの？

>>625にあった「ふつうのコンパイラをつくろう」を学校のメディアセンター(図書室)に注文しました。
いずれはコンパイラを作ることになるので今のうちに読んでおこうかと。

コンパイラまで作る気あるんだ

よくある、関数で最初に１回だけ実行される部分を何かの書き方にするのはどうか。

static int first = 1;
if(first){ ほげほげ first = 0; }

みたいなのを、

first{
ほげほげ
}

みたいに書けるとか。

じゃあ2回だけ実行されるのも追加しないとな

first よりも once の方が良いかもね。

static int once = 1;
while(once--) { ikkaidake() };

なかなか便利そうですね

int hogehoge() {
何かの処理
once { huga1 }
何かの処理
once { huga2 }
}

みたいに複数書けるとさらにうれしいかも

#define Ikkai \
static int ikkai; \
if( !( ikkai || ikkai++ ) )

defineでやれるだろカス
てかこれ、バグの元になるってのわかってんの？

初心者はそこらじゅうに
static int first = 1;
if(first){ ほげほげ first = 0; }
こんなソース書きまくるが
それはさっさとやめさせてまともな設計を考えさせるべき

まともな設計をするときは、C++でやるお(^q^)

きーてねーよカス

>>687-690の構文は議論の余地があると思うけど、基本的にはあるべきと感じる。
>>691のマクロもマルチスレッド時を考慮していないように見えるのが残念。

Javaの静的初期化ブロック、C#の静的コンストラクタ、VistaのInitOnceExecuteOnceなど、
マルチスレッドプログラムで1度しか実行されない保証というのは需要がある。
だから、そのための構文を作るアイディアは悪くないと思う。
というより、上に例を挙げたように正直に言って珍しくもなんともない。
あとは、どういう構文にするか。

>>689は構文というか、現行のCで使える方法だよ。

>>694
＞マルチスレッド時を考慮していないように見えるのが残念。
は？
この流れでマルチスレッドって発想は無かった

俺はもう一種類この手のマクロを持ってる
それはこのマクロで宣言されるstatic変数のアドレスを保存していって
初期化したくなったら、初期化関数を呼んで、またブロックを1回だけ通るようにするという仕組み
俺はマルチスレッドプログラムは組まないけど
Aスレッドが1個しか走らないプログラムなら
そのスレッドの終了時に初期化させればいいし
Aスレッドが同時にいくつも走るならスレッド作成時に識別子を与えれば普通に判定できるんじゃね

>>691
バグの元になりそうなのでマクロじゃなく構文に入れようとしてるんだろ？

そうなんですか？
じゃあ一つ385、303の書いてるソースもっていたら
static int first = 1;
if(first){ ほげほげ first = 0; }
こういう処理やってる場所を探し出してもらえませんか
ソース何処にあるか知らないけど
コンパイラとか作ってるならソース見なくても普通は無いと確信できる

スレ汚したな
自分の好きなように作ればいいよ
その処理は悪用されると怖いってだけで自分も極まれに使う事はある

なんか言っていることがよく解らないんだが…

トランスレータなりコンパイラなりを作ろうとしているんでバグが発生しやすいような
こういう処理やよく書く処理をこういう風に展開して欲しいとみんな言ってるのだと思う

>>698の意図がよく分からん。彼は何がしたかったんだろうか。

つーか、マルチスレッドはともかく、こんなの超安全な部類だと思うが。
それよりも自称プロがなんかわざわざ難しく見えるコード書いて俺ＳＵＧＥＥしてる方が危険ｗ

トランスレーター系はバグが出たらかなりデバッグしにくい。
トランスレーターの出力をある程度理解している人間じゃないと使えないから
結局統合される運命にある。
だからそのままリリースしておしまいってことにはならない。
もしそうなら開発者のオナニ−でしかいない。
LISPはその辺うまくできている。

Lisp がどうかはさておき、そんな当たり前の話を上から目線で話されてもなあ…

ついでに言えば、CL だろうと Scheme だろうとマクロにバグがあったら
デバッグはそれなりに面倒だと思うけど…

関数で最初に１回だけ実行される
ってのがそもそも設計間違ってる可能性が高いと思うんだが。
関数に状態持たせるなよ。

つまり君は、クロージャを採用している言語は設計間違ってる可能性が高いと思う訳か。
おいそれと JavaScript も書けんな…

新C言語だろ？
クロージャ採用は間違ってる可能性が高いと俺も思う

世の流れに棹さすのも悪くないと思うけど、理由くらい言って行こうや。

>>706
そうだよ。
ただ、インスタンス的に関数を使うやり方なだけだからな。

>>707
はぁ？
クロージャはモデルが違うだろ。
クロージャオブジェクトが関数と環境を持ってるんだよ。
言語スレの住人だったらメタモデルぐらい考えてみような。

>>708
>新C言語だろ？

つうか Blocks 知らんのか…

>>711
君は自分で自分の言ってる事が理解出来てるのかな?

>>713
さぁね。
環境という言い方でわかる人はわかるはずだけどね。

つまり君は『状態』と『環境』の違いを知っていると言う訳だ?

つーか、クロージャの場合はそういう話ではないと思うが。
ジェネレータの話か？

何かこの会話には、暫く前にデザパタが流行った時と同じ空しさを感じるな…

>>716
>>713

そうだね。
>>707の突っ込みが的外れなわけで。
それを認めるのがいやで言葉尻をとらえようと必死になってる。
そういう構図。

さぁ盛り上がって参りましたw

もっと中身の無い口先だけの議論を見たかったのに〜

いいスレですよね〜
スキルの高そうな人たちがそれぞれの信念のもとに突っ込んできますね〜

書き込んでる人全員の意見を考慮し出したら前へ進まないので
作ろうとしている人たちが採用／不採用を決めればいいと思います

自分の意見としては
a:いろんなOS/アーキテクチャで使用できる
b:既存のC/C++のコードを最小限の変更(変更なしが望ましい)で流用できる
が最低限必要かと思います

a,bが満たされないとオナニー言語で終わってしまうかもしれません
逆に満たされると「スーパーコンピュータでも使えます」みたいな〜

C言語へのトランスレータが良いかも(異議は認める)

関数内スコープな関数が有用か否かって問題でそ

なんかとてもめんどくさい流れになってますね…
>>708
クロージャ採用の話は凍結になったはずですが。

>>721
C言語へのトランスレーターである限りではどっちも満たせるんじゃないかと。

303が調子に乗ってる
なんかむかつく！

○既存言語の一部を仕様変更する際に、トランスレータは有効である (>>721)
×トランスレータは、既存言語の一部を仕様変更するために作成される (>>723)

303 の用語の使い方に、揚げ足取り。

wikiに385氏の実装のソースコードあげました。
と言ってもPDFファイルとODTファイルですが…

変更したい症候群の方は一度LISPを使ってみるべき

LISPで下痢が治りました

gelips

まだかなあ

俺的には
ジェネリックとオーバーロードと名前空間を足したCがあれば満足
クラスとかはいらんぽ
あとは型安全性の強化

>>731
オーバーロードの機能をよく吟味すると、C++と同じ型ロジックが必要だとわかるよ
つまりC++使えって事

C++を使うならJavaかDの方がいいな

このスレ的にGC言語はお呼びでないだろ

つまりDでいいと

そもそもC++なんかでいいなら新C言語なんて発想はない訳で…

>>1
現状報告をして下さい

>>731
ジェネリックはテンプレートでどうにかなるかと。
でもC++みたいなテンプレートだと時間かかるんだよなぁ…

>>1は逃げたの？

1は最初からいねーだろｗ

>>739
実現できそうになるのに2年かかるから>>1はいなくなったと考えるのが普通。

っ[age]

>>738
それはC++の実装というか仕様が糞なだけ。

保守あげ。


#年内にリリース出来たらいいなと希望的憶測でものを言ってみる。

tamarimahenna

C++、Java、C#の類は新C言語じゃねーの？シンタックス的に。
てかC99とC++のextern Cってどの程度同居できるの？

extern "C"は通常、名前修飾に関する扱いがCと同じになるというだけだが、
名前修飾がC99とそれ以前と異なる処理系なんて見たことないぞ。

名前修飾？
＠マークつきDLL関数ってCだとLoadLibraly使わないといけないけど
Basicだとそのまんま＠マークつきで関数定義できちゃうよね。

そういう話じゃなくて？

Windows以外も触っとけよ

ほしゅ

C + Smalltalk -> Objective-C
みたいなかんじで
C + CLOS -> 新C を妄想する

どうも。303です。
githubにあった385氏の実装のコード置き場が復活していました。
(落ちる前にわしがフォローしていたから？)

ttp://github.com/303/SINCL

と言うわけで、385氏の実装をビルドする際はgithubからソースを取ってきてビルドすることを強く推奨します。
ではでは。

なんかGoなんてのが出てきたみたいですね…。
利点:
コンパイルが速い
GC付き
並列処理を意識した設計
欠点:
パフォーマンスはCと比べ10%程悪い?(GCを採用しているからか?)
テンプレートがない
GCがある

構文はPascalとCを足して2で割ったような感じですね。D言語のスレで「将来的にDと競合するのでは?」なんて議論されてますが、むしろSINCLと競合するような気がしてなりません。被害妄想だと言われればそれまでですが。(まだ実装さえ出してないし)

Googleは何を目指してるんですかね…

…というわけで何が言いたいのかわからない雑文でした。

ついでにあげます。

Cには似てない
Pascal+Javascriptに見える

GoとかD言語のスレは盛り上がっているのにここは全然盛り上がらない(´;ω;｀)ﾌﾞﾜｯ

速いは正義

動くものが正義だよ。

かわいいは正義

正義すぎる市議

SBのCEOは正義

孫なこと聞いてねーよ

孫に関わると皆損する

ちんぽ切ると皆損する

「コンパイラ・スクリプトエンジン」相談室14
http://pc12.2ch.net/test/read.cgi/tech/1258431145/

このスレで今「俺言語」が話題になってる。
「俺言語」の変換先言語を感がえてみては？

すみません、
typedef struct Hoge{
/* ... */
union piyo{
int foo;
char bar;
}u;
}Hoge;

Hoge hogege;
hogege.u.foo = 3;

って感じで共用体をを使う人ってどれくらいいます？

>>765
unionは普通そういう使い方はしない。
構造体内でバイト列の読み替えをするのに定義することが多い。

union piyo {
int foo;
char bar[4];
short poo[2];
};

といった感じ。

>>766
確かにそういう使い方もありますわな。(完璧に処理系依存で、ほめられた使い方じゃないですが)

…で今回聞きたいのはそういうことではなくて、「構造体の中で共用体を宣言してしまう」人がいるか聞いたのですが…

あ、間違えた。

> 「構造体の中で共用体を宣言してしまう」

じゃなくて
「構造体の中で、共用体の宣言と共用体の変数宣言を同時にやってしまう」でした…

>>767
おいおい。処理系依存じゃないよ。char、short、long intは
それぞれ最低取りうる値の範囲がC言語の規格書で決められているぞ。
（ただし1バイトが8ビットかどうかは処理系定義と明記してあるが）

その意味ではintと書いて4バイトとみなすのは「処理系依存」だが、それならlong intと書けばいい。

せめてJISの規格書くらいは目を通そうな。
http://www.jisc.go.jp/app/pager?id=32303

＞…で今回聞きたいのはそういうことではなくて、「構造体の中で共用体を宣言してしまう」人がいるか聞いたのですが…
Linuxカーネルのソースコード読んでみな。

>>769
> その意味ではintと書いて4バイトとみなすのは「処理系依存」だが、

あ、そういう意味です。申し訳ない。

> Linuxカーネルのソースコード読んでみな。

やっぱ結構いるんですかねぇ…

なんでこんなことを聞いたかと言うと、struct hoge型の宣言と変数宣言を同時に行うことはSINCLでは出来ないので(同様に配列、共用体なども)、
struct Hoge{
/* ... */
};<-この";"(名前忘れたorz)はなくてもいいんでないかと考えたからです。(…typedefはどうしたって？
もうstructとかの名前の扱い方C++と同じでいいと思って…
でも、こうするとこんどはstructの一括代入が不可能なCでは色々とめんどくさいのですがそれはおいといて。)

>>769
って配列関係ないわ。わし頭ダイジョブか？

>>771
しかも指定するレス番号間違えた…orz

セミコロン

？

>>774
?

>>774
！

結局今年も何の成果もなかったな！

#BEGIN
#END
みたいなのを導入してマクロをスコープ付きにしてくれ

>>777

そーっすね。。。申し訳ない。

>>778

#undefのとき便利そう？

#define中に#define書けて再帰定義できるといい

>>780
プリプロセッサがどんどん高機能になっていく…

もういっそプリプロセッサをCの構文完全互換にしたらどうだろう。

>>782
…それしかないかもしれないけど、すごく読みにくそう…

#include <stdio.h>
#define(TEST) => (3){

int main(void){
int i = 10;
i += 2;
#ifdef("debug"){
printf("i..%d\n", i);
#}
i += TEST;
printf("i..%d\n", i);
return 0;
}

#}

こんな感じかな？

10進数のPCを作れば、誤差は無くなる。

速度より精度で勝負してみれば良いんじゃない？

工夫すれば10進数表現できるからいらねぇ

>>783
> 783:303 ◆pFphp4Ej4w (age)
> 2009/12/26(土) 08:05:46
> >>782
> …それしかないかもしれないけど、すごく読みにくそう…
>
> #include <stdio.h>
> #define(TEST) => (3){
>
> int main(void){
> int i = 10;
> i += 2;
> #ifdef("debug"){
> printf("i..%d\n", i);
> #}
> i += TEST;
> printf("i..%d\n", i);
> return 0;
> }
>
> #}
>
> こんな感じかな？

ちょいと訂正。

> #define("TEST") => (3){

のほうがいいな。

むしろ、マクロは縮小・廃止した方がいい。

でも結局マクロ的なものはいるよ
コードの自動生成もマクロの別解みたいなもんだし
いろんな言語にある eval もそうだ

超言語的変形は実際に便利だし
言語の枠内でやるとどんなに頑張っても1000行になるコードが
マクロ使えば50行になることもあるし

言語本体よりもプラットフォーム間で互換性の高い変形手段は必要だ

もう関数型言語にしちゃいなよｗ

メタ言語＝対象言語となると結局Lisp最強。

LISPのマクロは可変引数の各パラメーターを自在に取り出せる。
C言語型のプリプロセッサでこれができると全く違うものになる気がする。
既存の__VAR_ARGS__という可変引数の「かたまり」のままでは無理。
carとcdrみたいに各パラメーターを分解できて個別に処理できないと
LISPのマクロ＝構文と言わしめる芸当はできない。

>>788-792

C言語のマクロは毒にも薬にもなりますからねぇ…

わたし的には現在のマクロに、スコープさえ入ってればいいかなぁと思っています。

>>792
C99の可変長引数マクロなら各引数を取りだせるよ
ttp://chaos-pp.cvs.sourceforge.net/viewvc/chaos-pp/chaos-pp/chaos/preprocessor/tuple/elem.h?revision=1.11&view=markup
とか

function(a,b,c ... d)がS式で(function a b c . d)
function(a,b,c)がS式で(function (',' (',' a b) c))
にそれぞれ対応し、cが可変長引数部に出来るといいのではないかと思います。

話しぶった切って投下。

もしもSINCLにJavaDocみたいなのが入るとしたら、以下のうちのどれがいいですかね。

1)JavaDoc風のコメントでドキュメント生成
2)C#風のコメントでドキュメント生成
3)プリプロセッサと統合する。こんな感じ：

#doc
　#author 　　Hoge
　#summary　メイン関数。
#enddoc

int main(){
　//....
　return 0;
}

そもそも、JavaDocはなぜ今の形なんでしょう？
C#はJavaDocの改良でxmlをコメント内に書くことになった感じ？
プリプロセッサに統合ということはプリプロセッサが関数やらclassを認識するのでしょうか？
それともプリプロセッサの変換結果、別なSINCL構文になるのでしょうか？
SINCLの関数説明用コメント構文とASTがどうなるのかを考えたほうがよさそう？
たとえばXMLとSINCLをE4Xのように統合されていてドキュメントも自然に書けたりするとか。

@doc <function>
　<summary>メイン関数</summery>
　<author>Hoge</author>
　<return>0:正常終了 1:異常終了</return>
</function>
int main() {
XML xml=<b>hello world</b>;
　printf("%XML doc %XML\n", xml, this.doc);
}

あと、ドキュメント生成は自由にカスタマイズできて
<sincle file="hello.c">
　<function type="int" name="main">
　　<author>hoge</author>
　　<summary>メイン関数</summary>
　　<return>0:正常終了 1:異常終了</return>
　</function>
</sincle>
とかいうxmlで取得できるといいかも。

いっそのこと文芸的プログラミングとかどうだろう。

現在規制中により、郵便で送ります。
>>797
> C#はJavaDocの改良でxmlをコメント内に書くことになった感じ？

そういうことなのかなぁ…だれかC#の歴史に精通してるひとっていません？

> プリプロセッサに統合ということはプリプロセッサが関数やらclassを認識するのでしょうか？

Yes.
本音を言ってしまうとxmlっていちいち長ったらしくて(個人的偏見)エディタの支援がないと書くのが面倒かなぁ…と思ったからなのですが、
実際のところどうなのかな…

それと、sf.netにSINCLのプロジェクトページを立ち上げました。(ttp://sourceforge.net/projects/sincl/)
参加したいと言う方はこのスレで参加したい皆を宣言するか、ｓｆ.netの私のアカウントまでメールをお送りください。
注意)メールはめったに確認しないのでスレで宣言するほうがベターです。

なお、wikiのほうは当面の間公式wikiとして使っていきます。

xmlなんてアホだと思う

ActionScriptやScalaがxmlを統合してきているので、コメントにもXMLをいいかなと思ったのですけど。

C言語のプリプロセッサが
#if #endif
のように書くから拡張して
ドキュメントの構文は#doc #enddocという風に書くことにしたんですよね。
JavaやC#等はプリプロセッサを捨てたのでコメントに書いているけど、
SINCLではプリプロセッサありで考えているのでプリプロセッサの役割になると。

プリプロセッサの機能を高機能にしてC言語のプリプロセッサのいろいろな問題を解決できたらいいですね。
#define a 3
ではなくて
#const int a = 3;
等と機能別に細分化して使うようにするとか。
Javaのアノテーションなども取り入れるとか。

いっそのこと、クヌースみたいにドキュメントコード一体の「何か」を作ったら？
HTMLに埋め込んだコードがそのままコンパイラに通るとか

ソースのファイル単位での管理を脱却してRDBで管理できるようにできないかな

g++ "select code from source where src='c' or src='cpp'"
どっかで見覚えがあるな

>>801
なんかすみません…

>>802
本音：パースめんどい。(と言ってもパース処理は全部Boost.Spiritに丸投げしてるのでこんなこと言ったら罰当たりそうですが)

それと、なんか急に外人からメールが来まして、
最初はこんな文で、
subject:wanted to join
mail:can u just elaborate the your ideal my giving simple ex.
そいでSINCLの簡単なサンプルコードぶち込んで送り返したら、
subject:hi
mail:can we fix some time to talk... about Amatory prj..(let me now ur free time).
この場合"Amatory prj"をどう訳すべきですかね。そのまま訳すと「恋愛プロジェクト」になって、まぁ、こんなやつとメールしちゃいけない、と。
でも無理やり意訳すればSINCLプロジェクトのこととも取れますし…

　最近のCPUのアセンブラをそのまま記述出来る、C言語ライクな
ものが欲しいかな・・・とは思っていました。
　でも、もう言語仕様の方向性は決まっちゃったのかな(；´３｀)

これ開発の参考になりそうかな？Ecere SDK :http://www.ecere.com/
MingWの上にeCというC上位互換OO言語(現在はトランスレータとして実装)と統合環境、
各種ライブラリを乗せたマルチプラットホーム言語っぽいね。ライセンスはBSDだそうな。

>>806
JWASMは？ : ttp://www.japheth.de/JWasm.html
あるいはSphnix C--を改造 : ttp://www.dmoz.org/Computers/Programming/Languages/C/C--/

>>806
決まっちゃいましたね…すみません。

そういや言語使用の方向性についてまだ言及してなかったので言及しておくと、当分は

C++、Javaなどがとるオブジェクト志向を避けながらどれだけ高級な書き方ができるかの実験

という名目でやっていくつもりです。
ですからオブジェクト指向を取り入れることは当分ありません。

>>807
ありがとうございます。ちょっと見てきます。

#何でか知らんがsctのコード書いてるとIDEが固まるんだが…これはIDEのバグなのかそれともBoostなんか使ってるからか…

レキサー実装中。。。

querykeyst keyinfo; char view[66];
if (RegQueryInfoKeyStatic(HKEY_CURRENT_USER, keyinfo) == ERROR_SUCCESS) {
　　　　sprintf(view, "HKEY_CURRENT_USERのトップには、%d個のサブキーがあります。", keyinfo.SubKeys);
　　　　MessageBox(NULL, view, "テスト", MB_OK);
}
else {
　　　　MessageBox(NULL, "RegQueryInfoKeyStatic の実行に失敗しました。", "テスト", MB_OK);
}

その昔、方言だったけど2進数を0b0000_1111_0000_1111みたいにアンダースコアで
区切る事を許していた処理系がありました。
おいらこれで入門したものだから、まっとうなGCCで苦労した・・・読みにくくて読みにくくて。

ま、ちょっと考えれば簡単に回避出来たのだけど。
それでも、実装されると嬉しい。

0b0000\
1111\
0000\
1111

>>811
そんなのあるんですね。確かに読みやすいし面白い。
でも実装するとしたら

int i = 0b0001; // OK
int j = 0b0000_0002; // NG

#pragma use_uscore_in_0b

int k = 0b0800_0000; // OK

とかになっちゃいそうですが。

ﾌﾟ

>>303
ところで、D言語は触ってみたことある？

>>815
さらりと触ったことはあります。ただ、verupするたびどこかしらコンパイルが通らなくなるのでやめましたが…

色々違うところがあって一言では語れないが、
強力なtemplateおよびmixin機能が追加されていて、基本的にプリプロセッサが不要になっている。
（というか、無くなっている）
#ifdef/ifndef にあたるのはversionおよびstatic ifに置き換えられている。

プリプロセッサよりもこういった言語に統合された静的な制御機能の方が便利だと思うんだけど、どうだろう。

>>817
#ifdef __GNUG__
// ...
#elseif __VISUALC__
// ...
#endif

なんてするより、

version(__GNUG__) {
// ...
}
version(__VISUALC__) {
// ...
}

としたほうがずっとスマートであることは確かです。
ただ、これをトランスレータ(コンパイラ)に任せるのでは若干実装に手間がかかりますし(めんどくさいだけ)、個人的に"version"というよく使われそうな単語を予約語に含めるのはいかがなものかと思います。
とりあえずstatic_assertは入れてもいいかなとは思っていますが…

原点復帰してA言語つくろうぜ

原点と言えば
＠言語
を連想する

>>817
プリプロセッサはC言語と独立してるとこがメリットでもありデメリットでもあるわけで。
完全な置き換えは無理でしょ。

>>821
であるからこそ、バグの温床であるとしてサポートしないのが今風。

今風ってD言語みたいな思いつきの寄せ集め実装がいいわけ？
センスなさすぎ

>>818
よけーに分かりにくい

>>824
コンパイラがシンボルチェックに責任を持てるところが大きいんだよ。
ぱっと見は戸惑うかもしれないが、
これで連想配列的なversion設定値のチェック、設定、
static if / else / switch 構文相当が記述できるのでなかなかよくできてる。
C言語にも欲しいくらいだな、これは。

スレ再利用してもいい？
作りたいのはC言語派生じゃなくて、もっと小さな計算モデル検証用の言語だけど。

そもそも何人が見ているのかわかんないけど。

コンパイラが1000行ぐらい
VMが500行ぐらい
ならおｋ

まあ、それはそれは。
そもそもコンパイル言語にはならなさそうだけど。

じゃあ他所でやれやぁ
ここは俺のﾁﾗｼの裏にするんじゃぁ

>>829
どうぞどうぞどうぞ

放置スレだしここを再利用すればいいと思うよ

Cをオブジェクト指向化したのがC++、ObjectiveC等々ですよね。
Cを関数型化した言語ってあるんでしょうか。

LISP

オブジェクト指向と関数型は階層が異なる

>>832
元はscheme風だったがC風に改めさせられたJavaScriptさんがいる

これ ； デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど

もしかして「；」これ打ち忘れてコンパイルエラー出すのが楽しいの？
そうか、二度と話かけんなよ
うるさいゴミ

C言語のセミコロンはデリミタでなくターミネータだ

{ foo ; bar ; baz } ← 最後だったら要らないのがデリミタ
{ foo ; bar ; baz ; } ← 最後でも要るのはターミネータ

これ ； デリミタっていうんだけどさ、よく打ち忘れるよね
Rubyだとつけなくてよくなるんだけど
ゴミ量産機

２０１１年、Ruby,Perl,PHP,Pythonって並べたときにさ
ここで、Ruby以外を選ぶ奴ってマジでなんなんだろうな
でもお前はゴミなのにねｗ

>>837
C言語だとブロックの最後は要らなくない？

<複文> :== "{" <文>* "}"
<文> :== ... | <式文> | ...
<式文> :== <式> ";"

なので、いります。

test

ほむまど

だ

ん

ご

3

>>847
兄弟

だいどろねる

新しい朝が来た

が

断る

ど

れ

み

ふぁ

そ

ら

し

ど

ぷりきゅあ

ワイが聞いた情報によると、もうじき中国はバブルがはじけて昔の貧乏な中国に戻るらしい
もう経済は破綻してて、取り戻すのは無理なんだそう


その世界ではごっつい有名な政府関係者筋から聞いた確かな情報や

まあお前ら頭の良い連中には、今さらなくらいのネタや、
お前らからすればもう常識的なくらいの知識や

君らのことだからこの情報ですでに財産は出してるはずだけど