トップページ⇒tech
983コメント296KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/05/07(金) 11:36:35
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

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

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

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

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 4
http://pc12.2ch.net/test/read.cgi/tech/1271980246/
0002デフォルトの名無しさん2010/05/07(金) 11:37:28
◆新言語の要件 v0.1◆

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


◆主な要望◆

・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件）　＞　構文の美しさ(読みやすさ、学習の容易さ)　＞　再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
0003デフォルトの名無しさん2010/05/07(金) 11:40:03
286* 名前：デフォルトの名無しさん [] 投稿日：2010/04/27(火) 19:07:54
Ｃ言語の問題点。
１、コンパイラを軽く書きたいので色々端折ってる
２、軽く書きたいと良いながら、先読みが必要だったりする
３、軽く書けるので膨大な方言が発生し、それの取りまとめで仕様がボロボロ
４、機能の追加が必要最小限に留められているので、色々中途半端

Ｃ++の問題点
１、Ｃ言語との互換性を重視したので、記号が珍妙
２、追加、追加が多すぎて、なにがなんだか状態
３、オブジェクト指向の学識が高まるのと歩調を合わせた結果仕様が複雑
４、Ｃ言語の欠点を引き継いでしまってる

さて、以上の欠点は総て、言語が生まれた当時はまだ分かっていないことや、
当時では無理だったことが、後年解決された事など、色々に理由があって、
単に順調に成長した言語だから発生したとも言える。

そこで、プログラミング言語40年の歴史から学べる知見を総動員して、
Ｃ言語的なプログラミング言語を過去の遺産にとらわれず、今、開発
するとすればどんな仕様になるのだろうか？という事。
0004デフォルトの名無しさん2010/05/07(金) 11:42:16
450 名前：デフォルトの名無しさん [sage] 投稿日：2010/04/30(金) 16:32:34
GC有り言語とGC無し言語ではメモリに関する考え方がまるで違うから、
学習者からすれば一つの言語に混在するのは良くないんじゃないかな。

低レベルならC/C++でいいけど、
何でも有りすぎて「やっちゃいけない」ことが多すぎるから、
できることを減らしていいからミスが少なくなるようなコンパクトな文法がいいな。
標準ライブラリの整理(scanfなんかいらない）や充実も必要に思う。

良い言語の条件は、
・読みやすい・メンテしやすいこと(他人の書いたperlコードなんて読みたくない）
・ライブラリが充実してること(画像読み取りぐらいは標準ライブラリに欲しい)
・熟練者じゃなくてもミスのないプログラムが書けること
なんじゃないかなと思う。
0005デフォルトの名無しさん2010/05/07(金) 11:48:25
◆新言語の位置づけ◆

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

そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
0006デフォルトの名無しさん2010/05/07(金) 11:48:50
えらい早漏さんだな
0007デフォルトの名無しさん2010/05/07(金) 11:49:39
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0008デフォルトの名無しさん2010/05/07(金) 11:50:05
580* 名前：デフォルトの名無しさん [sage] 投稿日：2010/05/02(日) 00:57:35
ミニマリストにとってはマクロは魅力なのよ。下のほうからシームレスに弄れるし。
低水準言語だとForthなんかがそんな感じだよね。

まあ、マクロ無しでもインライン＆引数評価なし関数で十分代用できるけどね。
これでもまだ落とし穴たくさんあるけど。


816* 名前：デフォルトの名無しさん [sage] 投稿日：2010/05/05(水) 01:52:41
最近じゃめっきりアセンブラを使うことは減ったが
アセンブリでやる必要があるのはOSだけじゃないがね。

ちょいスレチな風味だが
直I/Oとか割り込みハンドラなどの低レベルライブラリが
CPU毎に異なってるのが組み込み屋の悩みだな
メーカ提供のライブラリの出来も千差万別だし
言語の話と離れるが、共通化してくれたらいいのにね
0009デフォルトの名無しさん2010/05/07(金) 11:50:40
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0010デフォルトの名無しさん2010/05/07(金) 12:01:59
新しい言語はGoogle GoやDに勝たないとダメだと思う
0011デフォルトの名無しさん2010/05/07(金) 12:04:59
とりあえず新言語名はＩ言語(アイ言語)にしませう
0012デフォルトの名無しさん2010/05/07(金) 12:10:59
Mona OSとかもあるし、
Mona言語とかしぃ++(thi++)言語でいいんじゃね？
0013デフォルトの名無しさん2010/05/07(金) 12:36:48
Monoでも良いぞ
0014デフォルトの名無しさん2010/05/07(金) 12:38:44
i-Mono
0015デフォルトの名無しさん2010/05/07(金) 12:50:23
Programming Language I に決定。
0016デフォルトの名無しさん2010/05/07(金) 13:07:32
>>1
速度にこだわった低級言語といえばアセンブラ
0017デフォルトの名無しさん2010/05/07(金) 13:08:26
>>5
文法はJavaベースで
0018デフォルトの名無しさん2010/05/07(金) 13:10:38
自分がコンピュータ史上の人物として名を残したいのは分るけど
スレタイの事に労力を費やすなら、Dとか有望株を改良したりドキュメントを翻訳したり
積極的に採用して著名なアプリを作るとかしたほうがいいとおもうんだが。
こんな事は5スレ目だから、何度も言われているかな？
0019デフォルトの名無しさん2010/05/07(金) 13:12:53
>>18
何を言っているんだ。このスレッドは雑談スレッドだぞ。
新しい言語を作るという妄想に浸りながら雑談するのが正しいスタイルだ。
新入り君はそこのところ勘違いしないほうがいい。
0020デフォルトの名無しさん2010/05/07(金) 13:13:16
>>18
その発想は無かった
0021デフォルトの名無しさん2010/05/07(金) 13:13:24
1スレの>>1はもういないだろ。
今は、話題に集まった奴が適当なことを言い合ってるだけ。
0022デフォルトの名無しさん2010/05/07(金) 13:15:56
>>18
そんな色気は仕様が固まってから考えれば良いこと。
Ｄで良いと思う人はＤに行けば良い、
Ｃで良いと思う人はＣを使えば良い、
ＬＷＬが好きな人は好きで居続ければ良い、
ＣＯＢＯＬしか分からない人はそれで良い、
0023デフォルトの名無しさん2010/05/07(金) 13:22:55
私見、
Ｄの問題点、ＣのリプレイスではなくてＣ＋＋の置き換えを目指してる、
曰く、Ｃとして読める構文はＣと同じ動きをする事等など。

Ｃの問題点、既出

ＬＷＬの問題点、論外、
JAVAの問題点、論外、
ＣＯＢＯＬの問題点、論外。
これらはランタイムを必要とする。

関数型言語、論外
Ｃの代替を目指す言語にはならない。
0024デフォルトの名無しさん2010/05/07(金) 13:28:50
>>23
COBOLってランタイムいるの？
0025デフォルトの名無しさん2010/05/07(金) 13:29:26
Cにだってcrtというランタイムがあるんだが
0026デフォルトの名無しさん2010/05/07(金) 13:30:32
>>24
主にＩ－Ｏセクションだけどね。
0027デフォルトの名無しさん2010/05/07(金) 13:31:56
・enumがいいかんじにswitch周りで使えるといいな。
・3項演算子はif式がよいんだか、よくないんだか？
・多値があるとよさそう。
・インクルードは自動生成がいい。

っていうかんじですか？
0028デフォルトの名無しさん2010/05/07(金) 13:33:45
・インクルードは不要。自動生成してもいいが必須ではない。
0029デフォルトの名無しさん2010/05/07(金) 13:34:00
>>27
＞・多値があるとよさそう。
おいらはこれに反対なんだけど、議論にならないので放置してる（ｗ
0030デフォルトの名無しさん2010/05/07(金) 13:35:37
・多値の戻り値は、一つのリスト型で行う。リスト型から要素を取り出す暗黙のキャストがあってもいい。
0031デフォルトの名無しさん2010/05/07(金) 13:40:00
多値はリストじゃなくてタプルだろう。
もっというとstructだろう。って言い出すとまた前スレッドを蒸し返せるよ
0032デフォルトの名無しさん2010/05/07(金) 13:46:20
関数に多値を許すことの最大の欠点は、Ｃ言語とバイナリー互換が
取れないこと。文法がＣ言語と違ってもＣ言語と同じ形式のバイナリー
フォーマットを維持できれば、旧来の資産を継承できるんだけどね。

まぁその辺はトレードオフなので、多値戻しが好きな人はそっちで煮詰めて欲しい
と思う。頑張れって思う。良い仕様が出来たら説得されちゃう用意は何時でもある。
だけど今の議論はちょっと、あり得ない、ＬＷＬ作ってるのか？とか思う。（ｗｗｗｗ
0033デフォルトの名無しさん2010/05/07(金) 13:50:22
C側から新言語によるオブジェクトを呼び出させい場合は、単値のみにするとか、ラッパーを作るとか、何かすればいいんじゃないの。

既存の言語の古い制約に引きづられて、新言語の仕様を妥協はしない方がいい。
0034デフォルトの名無しさん2010/05/07(金) 13:54:31
>>33
きみがそのらっぱーなら、どうぞ、どうぞ。
ちぇけらっちょ♪
0035デフォルトの名無しさん2010/05/07(金) 13:59:34
(ﾟ⊿ﾟ)ﾂﾏﾝﾈ
0036デフォルトの名無しさん2010/05/07(金) 14:02:47
俺も多値は要らんけど、Cとのバイナリー互換とかで妥協する必要はないと思うな。
0037デフォルトの名無しさん2010/05/07(金) 14:06:44
structで返却するってインタフェースにすればいいじゃん。
どうせ多値なんだから返却する型の順序は決まっているわけで。
0038デフォルトの名無しさん2010/05/07(金) 14:07:40
>>36
OSから全部作り直しになるけど、頑張ってください。
確かに意欲的な方向で考えるのは悪くはないと思うんですよ。
そこまで見えてやり遂げるつもりなら誰も止めません。
0039デフォルトの名無しさん2010/05/07(金) 14:10:57
structでもリストでもタプルでも呼び名は何でもいいけど、
順序付きの複数の値をまとめられるデータ構造のリテラルがあればいいね。

C++的には「初期化リスト」と呼ぶけど、「リスト」という呼び名が嫌なら別にポチでもミケでも何でもいい。
とにかく、そういうものが欲しい。
0040デフォルトの名無しさん2010/05/07(金) 14:12:50
>>38
その「作り直さなければいけないOS」とやりとりをしたいときだけ、多値を使わなければいいだけじゃん。
多値があるからOSから全部作り直しになるなんてことはないよ。
0041デフォルトの名無しさん2010/05/07(金) 14:13:03
>>39
提案コードを書いてみては？議論はそこからかな？
0042デフォルトの名無しさん2010/05/07(金) 14:17:00
OSはコーリングコンベンションと関係なかんべ
0043デフォルトの名無しさん2010/05/07(金) 14:18:34
>>41
例えば、C風で申し訳ないが、

{int, int} div(int a, int b)
{
　return {a/b, a%b};
}

{int, int} c = div(5, 3);　　　// c[0]に商（1）、c[1]に剰余（2）
int d = div(10, 6);　　　// dに商（1）、剰余は捨てられる

多値内の要素の指定方法は要検討だが。。
0044デフォルトの名無しさん2010/05/07(金) 14:28:47
>>43
無名構造体って感じなんだけど色々突っ込む前に。
てか突っ込めるほど堅くなさそうな気が。

で、一点、剰余だけ欲しい場合は？

こう言うのを一回でＵＰ出来ると、あぁこの人は考えてるなー
って思う。
0045デフォルトの名無しさん2010/05/07(金) 14:34:14
>>44
だから、名前は何でもいいよ無名構造体でもミケでもタマ。

暗黙のキャストはよく使われる要素が出てくればいいと思うよ。
この場合、商の方がよく使う要素だろうから、商が出てくる。

剰余が欲しい場合は、
int e = div(10,6)[1];
とか
{int, int} f, g = div(10,6);
でfを捨てたりするんじゃないの。

構文についてはもう少し考えないとね。
0046デフォルトの名無しさん2010/05/07(金) 14:37:15
＞構文についてはもう少し考えないとね。

考えてから、多値が欲しいって言うべきかな？
この構文ならすっきり出来るし、とか、そこから
議論始めようよ、突っ込まれて考え中とか無しだよ。

もちろん、その考えが駄目かも知れないんだから、
こうやって議論するんだけど、何も考えずに欲しいとか
まだ考えてないけど欲しいってのは、議論じゃねーですよ？
0047デフォルトの名無しさん2010/05/07(金) 14:39:12
>>46
あなたがそうしたいならあなた自身その方針でどうぞ。

欲しい物を欲しいと表明するのは別に問題ないよ。
0048デフォルトの名無しさん2010/05/07(金) 14:40:27
>>43

関数はdiv_tを返すという宣言のまま、初期値リストの逆みたいな構文を許せばいいんじゃない？

div_t Dとしたら

D = { 3, 4}　と出来るけど、逆に

int deno, rem として

{ deno, rem } = D とするSyntax sugarを加えるだけ．そうすれば

div_t div(int a, int b);の宣言のまま

{ deno, rem } = div(10,6)と出来るのでは。　{}　が無名構造体を作るという
流れに一貫して奇麗だと思うんだけど。
0049デフォルトの名無しさん2010/05/07(金) 14:40:28
考えているからある程度の例が出てくるのであって、
突っ込みどころ見つけてケチつけるのは、議論じゃねーですよ？
0050デフォルトの名無しさん2010/05/07(金) 14:45:33
>>48
構造体（のポインタやリファレンス）を返す事と見比べると、
あやふやな点が増えるだけに感じるのだが？

今までどおり構造体返しより得られるメリットは何？
0051デフォルトの名無しさん2010/05/07(金) 14:45:48
>>48
それだと、div_tを宣言しなければいけないのが、ちょっと美しくない感じが。

無名でできるものは無名にしたいよね。

だから、divの戻り値の方も無名にしたいかな。
0052デフォルトの名無しさん2010/05/07(金) 14:58:00
多値のコンテキストと単値のコンテキストはコンパイラには区別出来るわけだしな
v,r = a /% b
v = a / b
r = a % b
みないな感じでいんじゃね

Cの延長ならどうせ無名構造体と型推論はありだろうから
{ int a, int } foo () ... と宣言させておいて
{a, b} = foo()とa,b = foo()は構文糖で同じ意味って感じはどう
多値返しは使い方次第とはいえたいして重くはならないと思う

どうせならちょい違うが積和演算も出来たら面白いなｗ
0053デフォルトの名無しさん2010/05/07(金) 15:00:38
>>52
> v,r = a /% b

これいいな。MISD（Multi Instruction Single Data）だな。

調子にのってこんな構文があってもいいかも。

v, r = div,mod(a, b);
0054デフォルトの名無しさん2010/05/07(金) 15:03:06
MISD？
普通に割り算インストラクションは商と剰余を同じ返す奴が多いから
それをイメージしてるだけだけどｗ
0055デフォルトの名無しさん2010/05/07(金) 15:04:53
ていうか通常の割り算のアルゴリズムでは
商と剰余は同じに求まるんだよなｗ
0056デフォルトの名無しさん2010/05/07(金) 15:06:32
>>55
まあ、割り算は分かりやすいから例として使っているだけだろｗ
0057482010/05/07(金) 15:06:56
>>50
>今までどおり構造体返しより得られるメリットは何？
ない。　遊び遊び．

>>51
ああ、そうか。　{int, int} は div_tの無名記法と考えれば{int, int} div(int a, int b)も
納得できるな。

だったら43と48を合わせて

{int, int} div(int a, int b)
{
　return {a/b, a%b};
}

{deno, rem } = div(5,3)
0058デフォルトの名無しさん2010/05/07(金) 15:09:19
>>53
関数を置けるところに関数のリスト置けてもいいな。

v, r = {div,mod}(a, b);

それをパラに処理してくれると嬉しい。
0059デフォルトの名無しさん2010/05/07(金) 15:10:57
>>50
> 今までどおり構造体返しより得られるメリットは何？

オサレでかっこいい。
0060デフォルトの名無しさん2010/05/07(金) 15:12:47
汚いExceptionを少なくしてちゃんとエラー返すのに
多値があったらいいんよね
Cは本来の値以外に特殊な値を定義したり
変なグローバル変数を使ったりするからイマイチ
golangみたいな ret, ok = foo()記法は慣れると結構わかりよい
0061デフォルトの名無しさん2010/05/07(金) 15:17:59
>>60
それいいな(ﾟＡﾟ;)ｺﾞｸﾘ
0062デフォルトの名無しさん2010/05/07(金) 15:23:04
>>60
例外処理の使い勝手の悪さ問題だよね。
例外処理が使えればエラー値戻しは
必要ないと思うんだが。

多値戻しは鬼門になりそうな気がするんだけどなぁ。
0063デフォルトの名無しさん2010/05/07(金) 15:29:08
そうかな？多値の有り無しは別として
例外処理って本来は大域脱出の延長だから多用すべきではないんだよ
正常な処理としてのエラー処理と例外処理を同列に考えて
構文に入れちまったのが問題だと思うんだよな
無用なオーバーヘッドだってあるしね
0064デフォルトの名無しさん2010/05/07(金) 15:31:15
> 多値戻しは鬼門になりそう

しかし、Python, Ruby, Goとすでに使われてるよね。　他にもあったっけ？
0065デフォルトの名無しさん2010/05/07(金) 15:36:49
Lisp
0066デフォルトの名無しさん2010/05/07(金) 15:39:23
Lispと言ってもいろいろだろｗ

S5R5は多値に対応してるな。
0067デフォルトの名無しさん2010/05/07(金) 15:40:34
Common Lispも多値に対応してるよ。
0068デフォルトの名無しさん2010/05/07(金) 15:42:10
PythonやRubyはタプルみたいな奴で単値返しじゃないか？
構文的には多値風だけど。
0069デフォルトの名無しさん2010/05/07(金) 15:43:07
なんでもいいよ。構文的に多値に見えれば。
0070デフォルトの名無しさん2010/05/07(金) 16:19:54
>>68
こんな感じですね：
def mul():
　　return 5,6

>>> a,b = mul()
>>> a,b
(5, 6)
>>> a = mul()
>>> a
(5, 6)
>>>b,c = a
>>> b,c
(5, 6)


つまり、タプルを複数の変数に代入出来るという機構があるだけという感じですね。
0071デフォルトの名無しさん2010/05/07(金) 16:49:00
>>70
他意のない単なる質問だけど、その「タプル」とLispのリストって機能的な違いってあるの？同じもの？
0072デフォルトの名無しさん2010/05/07(金) 17:18:31
Pythonについていうと似たようなもんだが
タプルは変更付加
ちょい汚いけどC++0xにも導入されてるね
0073デフォルトの名無しさん2010/05/07(金) 17:21:17
ごめｗ不可ねｗ
0074デフォルトの名無しさん2010/05/07(金) 17:23:59
>>72
なるほど。ありがとう。

それなら、今はまだいいけど、
用語をタプル／可変タプルとか、リスト／定数リストのような感じで機能を表すようにして欲しいな。

慣れなのかもしれないけどね。
0075デフォルトの名無しさん2010/05/07(金) 17:30:03
リストがlisp的なリストのことなら通常リスト自体は変更可能なデータ型でしょ
タプルは作ったら変更不可で自身も無名、メンバーも無名なstructって感じと思えばいい
0076デフォルトの名無しさん2010/05/07(金) 17:31:33
>>72
ビックリしたぁ、標準ライブラリじゃん。
0077デフォルトの名無しさん2010/05/07(金) 17:38:12
そそ。C++らしく汚物的に汚いけどねｗ
0078デフォルトの名無しさん2010/05/07(金) 17:43:32
タプルをリストに代入できるが、リストをタプルに代入できるとは限らないってことでおｋ？
0079デフォルトの名無しさん2010/05/07(金) 18:04:43
>>77
言語の話してるときに標準ライブラリの話持ち出さない
程度の、なんかは無いのか？
0080デフォルトの名無しさん2010/05/07(金) 18:05:46
>>18
名を残すなんて用意ではないぞ。
まつもとゆきひろのようになるのも大変かと。
ましてやオブジェクト指向言語を作るとなると
コンパイラコンパイラで作るのもものすごい苦労するのではないかと。
Java言語を作った集団は10年以上もかけて研究してきた研究者だからな。
Javaを超える言語を作るのも至難の業。
0081デフォルトの名無しさん2010/05/07(金) 18:06:51
>>23
C++がOKでJavaが論外というのが矛盾だらけだ。
JavaはJVMなしでネイティブで動かすこともできるのだが。
0082デフォルトの名無しさん2010/05/07(金) 18:09:26
>>27
どうせならJavaのenum以上に高機能であることが望ましいな。
interfaceを実装できてクラスのように扱うことができジェネリックス(テンプレート)も使える。
そして列挙変数にメソッドを持たせることもできる。
JavaのenumはC++やC#のenumとも異なる超高機能列挙型だから
それを超えるenumが欲しい。
includeよりimportとpackage(namespace)のほうがいい。
ディレクトリやファイルパスという方式はヘッダファイル地獄に陥る。
0083デフォルトの名無しさん2010/05/07(金) 18:11:07
>>30-31
リスト型、structというかオブジェクト(class)で返すべき。
C++STLのvector型、JavaのListオブジェクト(型)のように。
そして当然ながらGenerics(template)と併用できる。
0084デフォルトの名無しさん2010/05/07(金) 18:11:21
何回自慢げに同じ話ばかりすれば気がすむんですか？
0085デフォルトの名無しさん2010/05/07(金) 18:12:27
低水準ってキーワードを無視しまくったレスを付けてる奴は頭悪い。
0086デフォルトの名無しさん2010/05/07(金) 18:12:50
>>39
C++STLのvectorやJavaのjava.util.Listオブジェクトの真似をすることの何が不満なんだ
配列で返してもいいし、オブジェクトで返してもいい。
0087デフォルトの名無しさん2010/05/07(金) 18:20:22
>>43
> {int, int} div(int a, int b)
> {
> 　return {a/b, a%b};
> }

なんかMATLABっぽい文法だな。MATLABだとこう書く。
[x, y] = function(a, b);
x = a / b;
y = a % b;
そしてファイル名をdiv.mとして保存してパスを通して
A = div(1,1)
とやると配列になって

A = [1, 0]
と出力される。


そしてJavaやC++だとこうなる。
<T extends Number> List<T> div(T a, T b){
　List<T> result = new ArrayList<T>();
　result.add(a / b);
　result.add(a % b);
　return result;
}

int[] div(int a, int b){
　int[] result = new int[2];
　result[0] = a / b;
　result[1] = a % b;
　return result;
}
0088デフォルトの名無しさん2010/05/07(金) 18:23:02
>>52
> 多値のコンテキストと単値のコンテキストはコンパイラには区別出来るわけだしな
> v,r = a /% b
それを許すと
v= 1, r = a / b;
という記述(C言語のv = 1; r = a / b;と同じ)がかわってしまうが、その点はどう対応する？
途中改行を許さないという文法にでもする？
0089デフォルトの名無しさん2010/05/07(金) 18:24:29
>>60
例外処理に不満があるならC#の真似をしてみては。
あれはあれで問題を起こし、Java方式とC#方式で賛否両論があるが
0090デフォルトの名無しさん2010/05/07(金) 18:25:51
>>85
低水準といっておきながらC++に変わる言語を作れっていう時点で
無理がある

あるていど高級言語にせざるをえないんでは。
しかも例外処理の話までしてる。
0091デフォルトの名無しさん2010/05/07(金) 18:29:29
>>88
, で式をつなげるのは無しにすればいいかな。
0092デフォルトの名無しさん2010/05/07(金) 18:30:58
>>90
低水準に”も”使えればいいんだよ。無理はないよ。
0093デフォルトの名無しさん2010/05/07(金) 18:31:57
スレタイに、C++が入っているのがそもそもの間違い。C++にかわる言語はいくらでもある。
次のスレは、C++をはずそう。
0094デフォルトの名無しさん2010/05/07(金) 18:35:37
>>86
返り値を多値型にキャスト出来れば、別に何を返してもいいよ。

a, b, c, d = func();

で、func()の戻り値の配列なりオブジェクトなりの要素を何らかの法則に従って順序付けて並べたときの1,2,3,4番目の要素を、a,b,c,dに代入できればいい。
0095デフォルトの名無しさん2010/05/07(金) 18:37:58
>>88
ちょっとウザイけど
c = 1, [v,r] = a/b;
とかでもいいかな。
0096デフォルトの名無しさん2010/05/07(金) 19:17:43
>>88
Cのカンマ演算子は中途半端だから廃止でいいんじゃない
複数の式を1つにまとめるのといろんなもんの区切りが同じ,ってのは
いまいちな感じしないかな
forとか考えるといい構文も思いつかないんだけどｗ
0097デフォルトの名無しさん2010/05/07(金) 19:19:25
(v = 1; b = 2)なんて言うのが式として有効ならいいかも
0098デフォルトの名無しさん2010/05/07(金) 19:23:19
>>79
ああ。確かにライブラリだな
でもC++0xそのままは汚いっていうのはそういうのも込みの印象ね
無名、メンバー無名のstruct的なデータ型はFirst Classとして
アリなんじゃないかと思ったからさ
0099デフォルトの名無しさん2010/05/07(金) 19:26:58
前スレ埋めろよ
0100デフォルトの名無しさん2010/05/07(金) 19:27:08
>>98
C++は過去を引きずり過ぎてあんな感じにならざるをえないんだろうね。
そういう意味で、新言語は過去に引きずられて妥協することのないようにしたい。
0101デフォルトの名無しさん2010/05/07(金) 19:28:45
>>100
ぶっちゃけいうと俺はCとgolangでいいとおもってるけど
C++とかいらねｗ
でもスレはネタとして楽しんでるよ
■ このスレッドは過去ログ倉庫に格納されています