新C言語を作ろう - 暇つぶし2ch

新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は何の略にしようか。
↓

次ページ