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

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

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

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

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

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

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 3
http://pc12.2ch.net/test/read.cgi/tech/1271086841/
2デフォルトの名無しさん:2010/04/23(金) 11:14:39
スレタイからC++を除け
3デフォルトの名無しさん:2010/04/23(金) 13:22:01
4て
盛り上がってたんだな
4デフォルトの名無しさん:2010/04/23(金) 17:04:26
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所
5デフォルトの名無しさん:2010/04/23(金) 22:56:07
422* 名前:デフォルトの名無しさん [sage] 投稿日:2010/03/22(月) 20:49:29
それならCにできないけど低級言語に欲しい機能を挙げてみようぜ。
・Lispなみに弄くれるマクロ
- テンプレート
- 正規化された構文(S式とか)
・Forthなみに弄くれる駆動レコード
- コルーチン
- 強制インライン展開(レコードを新しく作らないルーチン)
- 駆動レコードへのアクセス
・実行制御
- 高度な並列処理(トランザクションとか)
- アトミック操作
- リアルタイム操作

こんなもんかね? 他にどんなの欲しい?
6デフォルトの名無しさん:2010/04/23(金) 22:58:13
正直そこで上がってる項目はぐちゃぐちゃ過ぎて
ネタとしか思えない

S式とかマクロとか言ってる人は
ttp://www.atmarkit.co.jp/news/200909/07/lltv02.html
こういう方向性もあるよ
7デフォルトの名無しさん:2010/04/23(金) 22:58:15
個人的には(構文だけではないけど)
- ブロックを明示しやすくて文でクロージャ作れるし{}がいいと思う
- オフサイドルールはコードはすっきりするけど賢いエディタ前提で深さがわかりにくい
- Cよりシンプルな構文が望ましいが別にC系でいいんでは
- 演算子の再定義はスパゲッティ化しやすいから不要
- マクロもインラインとか定数型などの別な方法で実現可能なので不要
- XMLなんかは外でやればいいんでは
- 勝手にデータを付加しないASN.1とかCの構造体的なメモリイメージと直結したデータ構造
- 動的型付け、GCや動的メモリ管理は明示的に利用を限定出来るならいいかも
- その他のシンタックスシュガーは適度にアリ
8デフォルトの名無しさん:2010/04/23(金) 23:08:10
◆新言語の要件 v0.1◆

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


◆主な要望◆

・デバドラ屋だって、オサレ言語で開発したい!
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性(絶対条件) > 構文の美しさ(読みやすさ、学習の容易さ) > 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
9デフォルトの名無しさん:2010/04/23(金) 23:12:54
>>8
>割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
ここで言う例外はCPU例外だよね。
C言語の代替案を考えるのだから、この言葉で混乱したくないので
以降、CPU例外は、「CPU例外」、プログラミングの例外処理は
「例外処理」と書こうではないか。
10デフォルトの名無しさん:2010/04/23(金) 23:19:54
>>9
> ここで言う例外はCPU例外だよね。

いや、新言語の構文・実装はまだ明確ではないが、既存言語のtry-catchに相当するものだよ。つまり「例外処理」。
「CPU例外」は割込みに含まれる。

それらを統一的に扱うことを考える。チャレンジングな試みだ。

11デフォルトの名無しさん:2010/04/23(金) 23:20:34
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所
12デフォルトの名無しさん:2010/04/23(金) 23:21:25
話が進まんしマイルストーン設置しようぜ
まずPart10までに例外に決着な
13デフォルトの名無しさん:2010/04/23(金) 23:21:40
>>4 >>11
京都大学霊長類研究所 必死過ぎるww
14デフォルトの名無しさん:2010/04/23(金) 23:29:25
全部決まるのいつになんの
15デフォルトの名無しさん:2010/04/23(金) 23:33:07
じゃあPart10からPart15までは「全部とは何か」を決めるからな
16デフォルトの名無しさん:2010/04/24(土) 00:11:17
SC言語は,Common Lispで実装された,S式の(Scheme風の)構文を持つC言語です.
http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index.html
17デフォルトの名無しさん:2010/04/24(土) 00:56:05
> (def (sum ar n) (fn long (ptr long) int)

仮引数と仮引数の型が隣接しないってどんだけクソ言語だよw
18デフォルトの名無しさん:2010/04/24(土) 02:38:19
デストラクタ欲しいなぁ。

自動変数がスコープから外れるときに発動する仕掛けが欲しい。
19デフォルトの名無しさん:2010/04/24(土) 02:43:54

もう、C/C++ でいいじゃん
20デフォルトの名無しさん:2010/04/24(土) 02:47:49
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
21デフォルトの名無しさん:2010/04/24(土) 03:03:59
もう、D でいいじゃん
22デフォルトの名無しさん:2010/04/24(土) 09:29:18
>>20
rubyもそんな感じじゃなかったっけ
23デフォルトの名無しさん:2010/04/24(土) 09:30:28
>>20
それを、オナニーと呼ぶんだよ
24デフォルトの名無しさん:2010/04/24(土) 11:30:12
「ぼくのかんがえたさいきょうのげんごしよう」を妄想するスレ
25デフォルトの名無しさん:2010/04/24(土) 11:36:57
>>5
> ・Lispなみに弄くれるマクロ
> - テンプレート
> - 正規化された構文(S式とか)

先ず、これが欲しい。
26デフォルトの名無しさん:2010/04/24(土) 12:11:03
僕の考えた最強の言語しよう
27デフォルトの名無しさん:2010/04/24(土) 12:15:49
GAME言語があるじゃん。
28デフォルトの名無しさん:2010/04/24(土) 12:16:16
JavaのようにIDE前提で、
とことんリファクタリング機能とかで楽できる言語がいいよ。
29デフォルトの名無しさん:2010/04/24(土) 12:47:52
JavaがIDE前提???
30デフォルトの名無しさん:2010/04/24(土) 13:05:32
実質そうだろ。
エディタ(Emacs含む)で書く奴がいるが、そいつらは変態なだけだ。

Cやらはマクロでトークンの置換とかヘタにできちゃうから、
リファクタリングツールを作成しづらい。
31デフォルトの名無しさん:2010/04/24(土) 13:21:10
自分と違う人を片っ端から変態扱いするのはどうかと思うよ
32デフォルトの名無しさん:2010/04/24(土) 13:26:27
IDEのサポートが無いととても書けない糞言語っていう意味だろ、合ってるよ。
33デフォルトの名無しさん:2010/04/24(土) 13:31:05
長ったらしい命名基準や秩序が有るのか疑わしいライブラリ枝の膨張がIDE必須にしてるよね。
34デフォルトの名無しさん:2010/04/24(土) 13:31:42
IDEも活用できない糞人間
35デフォルトの名無しさん:2010/04/24(土) 13:33:31
windowsのメモ帳で書く俺は神
36デフォルトの名無しさん:2010/04/24(土) 13:37:36
EmacsまごうことなきIDEですが。
37デフォルトの名無しさん:2010/04/24(土) 13:38:35
windowsならサjyラエディタ
38デフォルトの名無しさん:2010/04/24(土) 13:38:42
Emacs上でコーディング・デバッギング・コンパイル・パッケージングすべてできますね。
これを統合開発環境と言わずして何をそういうのでしょう。
39デフォルトの名無しさん:2010/04/24(土) 13:39:16
クがjyになってでござる
40デフォルトの名無しさん:2010/04/24(土) 13:44:12
41デフォルトの名無しさん:2010/04/24(土) 13:53:59
>>38
じゃあ、Checkstyleやらリファクタリングやらはどうなんだろう。
クラスの階層を出せるだろうか、JARの中もきちんと検索できるだろうか。

もはやJava開発って↑みたいな機能ぜーんぶ前提で
動いているよなあ。(少なくとも業務系は)
42デフォルトの名無しさん:2010/04/24(土) 15:44:56
IDEなしでも気楽に書けて、IDEの支援があればますます書きやすくなる。
新言語はそんな言語にしたいです。
43デフォルトの名無しさん:2010/04/24(土) 15:45:46
LLですね
44デフォルトの名無しさん:2010/04/24(土) 15:48:27
>>41
emacsではelispが動いているんだぜ。
できないことなんかないだろ。
45デフォルトの名無しさん:2010/04/24(土) 15:49:19
秀丸では秀丸マクロが動いているが?
46デフォルトの名無しさん:2010/04/24(土) 15:57:16
>>45
emacsのマネしてるだけ。
47デフォルトの名無しさん:2010/04/24(土) 16:04:40
参照のせいでC++の関数呼び出しは可読性が著しく低下した。

Cでは、引数がポインタ型でなければ関数からの出力にはなり得なかった。
C++では、参照型の仮引数があるため、ポインタ型ではない引数であっても関数からの出力にはなってしまう。

下手に機能を増やすと使いにくくなる典型的な例だ。
48デフォルトの名無しさん:2010/04/24(土) 16:06:24
>>47
実用とか互換性とかにばかり気をとられていると、
すぐにそういう問題を無視しちゃうんだよね。
だから教育用低級言語として開発した方がすっきりした物が作れるんじゃないかな。
49デフォルトの名無しさん:2010/04/24(土) 16:08:20
あれだろあれ、なでしこ
50デフォルトの名無しさん:2010/04/24(土) 16:11:19
>>49
それは低級言語じゃなくて低脳言語
51デフォルトの名無しさん:2010/04/24(土) 16:14:32
>>47
その代わり、参照なら出力がNULLでないことを保証できるんだけどね
NULLを脱参照するような真似をしなければ
52デフォルトの名無しさん:2010/04/24(土) 17:05:37
>>47
const参照だけ使えばいいよ
53デフォルトの名無しさん:2010/04/24(土) 17:09:51
>>52
じゃあ、全プログラマーに周知徹底してくれ。

使える機能であれば、必ず使う人間が出てくるものだ。
そういう機能があるということがそもそも問題なんだ。
54デフォルトの名無しさん:2010/04/24(土) 17:12:11
ポインタ使ったらNULLチェックが必要になって
それをさぼってバグが入り込んだり
そもそもNULLが渡された際の挙動が定義しづらかったりで
別の所でバグの温床になるだけだろ
55デフォルトの名無しさん:2010/04/24(土) 17:15:18
ポインタ以外でも値域のチェックはするだろ?
56デフォルトの名無しさん:2010/04/24(土) 17:16:24
自由だけど不安定か、不自由だけど安定かの問題だよ
後者が良さそうに見えるけど、ユーザーの不満は増える。その例がTeX
57デフォルトの名無しさん:2010/04/24(土) 17:19:03
TeXのどこが不自由なんだ
58デフォルトの名無しさん:2010/04/24(土) 17:21:31
とりあえずC++をリファクタリングしろww
59デフォルトの名無しさん:2010/04/24(土) 17:22:01
もうTeXじゃなくてオフィスの数式エディタで良いやって人が増えるくらい不自由
60デフォルトの名無しさん:2010/04/24(土) 17:41:10
数式書きたいだけの低脳の話かwwwww
61デフォルトの名無しさん:2010/04/24(土) 17:44:39
問題はそこじゃないだろ
治安でも同じことが言える、単なる一般論
一般人を低能と切って捨てるのに新しい言語を作りたいって?
そんなのお前以外誰も使わないだろうな
62デフォルトの名無しさん:2010/04/24(土) 17:47:40
>>61は誰と戦ってるんだ?
63デフォルトの名無しさん:2010/04/24(土) 17:48:30
>>62
文脈読めないの?
64デフォルトの名無しさん:2010/04/24(土) 17:49:02
無い文脈は読めない。
65デフォルトの名無しさん:2010/04/24(土) 17:50:41
じゃあ一つだけ言うけど、数式書きたいだけの低脳の話ではない
66デフォルトの名無しさん:2010/04/24(土) 17:51:11
「一般人を低能」とか言ってるの>>61だけだしな
67デフォルトの名無しさん:2010/04/24(土) 17:53:19
話を戻すけど、>>53辺りの流れに対して
自由だけど不安定か、不自由だけど安定かの問題だよ
後者が良さそうに見えるけど、ユーザーの不満は増える。その例がTeX
68デフォルトの名無しさん:2010/04/24(土) 17:56:26
TeXのどこが不自由なんだ
69デフォルトの名無しさん:2010/04/24(土) 17:58:01
TeXへの批判も知らない低能が新言語なんて作れるわけないじゃん
70デフォルトの名無しさん:2010/04/24(土) 18:06:27
>>25
この辺って、低級手続き型高水準言語のCと相性悪い、
と思うんだけど、もう少し詳しく説明して欲しい。
あんまり知らないんだよね、S式のメリットとか、
プログラミングパラダイスじゃなくて、パラダイムが
まるで違って、テレコテレコになりそうな気もするんだけど、
S式のメリット、Lisp並のマクロとかは、別レイヤーの
話のような気もするんだけどどうだろうか?

あれば便利なのは疑いようが無いんだけど、rubyとか
やっぱり、そういうレベルの言語の話ではないのだろうか?
と思うのですが。
71デフォルトの名無しさん:2010/04/24(土) 18:06:45
それじゃあ、TeXへの批判を議論するところから初めてみようか。
72デフォルトの名無しさん:2010/04/24(土) 18:08:55
>>70
> この辺って、低級手続き型高水準言語のCと相性悪い、
> と思うんだけど、もう少し詳しく説明して欲しい。

別にCを作るわけじゃないんだけど、Cとの相性の悪さを説明する意味あるの?
73デフォルトの名無しさん:2010/04/24(土) 18:11:17
>>71
お前、何が問題なのか常に見えてないんだな
74デフォルトの名無しさん:2010/04/24(土) 18:12:25
何が問題なんだ?
75デフォルトの名無しさん:2010/04/24(土) 18:13:42
>>47
だよね、const参照をデフォルトにして、書き換えの場合、
variableキーワードを追加って言うのが、理想だったよね。
CとC++にそういうのが多すぎると思う。

必要最小限の拡張というポリシーが破綻してきてるので>>1
なんだと思う。
76デフォルトの名無しさん:2010/04/24(土) 18:14:27
自由度
77デフォルトの名無しさん:2010/04/24(土) 18:16:55
わざとか知らんが全角は確かに低能に見えるな
78デフォルトの名無しさん:2010/04/24(土) 18:20:22
>>70
Cのマクロは貧弱すぎるってことじゃないの。

確かに、実行時の処理を抽象的にし過ぎると低級手続きの記述がしづらくなるかもれないけど
もう少しコンパイル時に処理はいろいろ便利に記述できてもいいと思う。
79デフォルトの名無しさん:2010/04/24(土) 18:21:12
>>72
C的な言語との相性の悪さに同意いただいて何より、
であるとするならば、アセンブラとの相性の悪さ、
と言うか、Lisp言語の一行が、アセンブラで数百行にも
数千行にも展開されていくとなると、これはもう、
低級高水準言語じゃなくて、高級高水準言語だと思うので、
CやC++に代わる、という当初の目的よりは逸脱してると
考えるのです。

もろちん、もちろん、そんなことはない、マシンコードをよりよく
扱うためにこそ、S式なのだ、という見解もあるでしょう、ただ
私は勉強不足なのでおよそそのようには考えられないので、質問してる
訳です。質問の意図を汲んでいただき、お答え願えればと思います。
80デフォルトの名無しさん:2010/04/24(土) 18:22:28
Lispのマクロは子供の木を生成するだけになってしまっているから
親の木も書き換えられたらどうだろう
81デフォルトの名無しさん:2010/04/24(土) 18:23:24
>>78
それは言語では無くて、リファクタリングツールの設計ですな。。。
Cのマクロがリファクタリングツールなのか、という議論は不毛だと
思うのでご遠慮させていただきますが。
82デフォルトの名無しさん:2010/04/24(土) 18:37:15
>>70, >>79

俺は>>25じゃないから、もともと書いた奴が
どういう意図で書いたかは分からんが、
マジレスすると、>>25には「構文」「マクロ」
つまり、コンパイル時の問題について書いてあるだけで、
「実行時に」S式のような、GC必須の動的なリストや木構造を扱いたいとは
一言も書いてないだろ
コンパイル時の問題なんだから、コンパイラが吐くプログラムが
低級か高級かといった問題とは全然関係ないぞ
83デフォルトの名無しさん:2010/04/24(土) 18:39:32
その上で、実例としては>>6>>16でも見ればいい
84デフォルトの名無しさん:2010/04/24(土) 18:42:00
>>75
C++は踏み台だったのだよ・・・
後続言語では out が導入されたが、
当時はそういう発想はなかったんだろう
85デフォルトの名無しさん:2010/04/24(土) 18:43:00
outも汚い
CのようなN-in 1-outな言語とインタフェースするときにはあったほうがいいが
多値リターンがあれば本来out引数なんて要らない
86デフォルトの名無しさん:2010/04/24(土) 18:45:25
関数単位の例外処理もキレイに書けるシナー
87デフォルトの名無しさん:2010/04/24(土) 18:47:42
>>83
どうも日本語が通じないようで・・・
だからS式導入の低水準高級言語としてのメリットを聞いてるんですよ。
>>6は高水準高級言語は素晴らしい、そのうえ定式化されてるので素晴らしい。
と読めるのですが?
88デフォルトの名無しさん:2010/04/24(土) 18:48:24
>>87
・パースしやすい
・Lispの強力なマクロが使える
こんなものだろ
89デフォルトの名無しさん:2010/04/24(土) 18:50:42
あ、こんだけ言われても
まだ「高水準言語」とか言ってるってことは全然理解して無いんだな

馬鹿だろ
リンク先読んでも理解できないんだからな

構文はS式だけど、構文がS式なだけでCと同じobjを吐けるんだよ
90デフォルトの名無しさん:2010/04/24(土) 18:51:24
最初からS式で表されていると
たとえば、for文とかがどういう木を持っているか、
とかで悩まなくて済むんだよね
91デフォルトの名無しさん:2010/04/24(土) 18:51:45
>>88
だ==========か============ら
>>79なので、ルビーが使いやすい、Lispが好きとか
言われても、議論にならないんですよ。
特に>>6はキチガイの戯言で、C++、と、テンプレートの
無い世界の話ですね。今の環境でC++とテンプレートが
存在しないことを前提にC言語の拡張を書いても訴えても
無意味なんですよ。2000年以降、こういう頓珍漢な話をする
文系が増えて無茶苦茶ですよ。
92デフォルトの名無しさん:2010/04/24(土) 18:52:37
全角って馬鹿だな、まで読んだ
93デフォルトの名無しさん:2010/04/24(土) 18:52:38
>>85
多値リターンと引数からのリターンには差があって、
多値リターンは常に何らかの値を返す必要があり、
引数からのリターンは(エラー時など)場合によって値を返さなくても良い
全て参照型ならとりあえずnull返しゃいいだろうけど
値型(特に構造体とか)があるならこの差はパフォーマンスに影響する
94デフォルトの名無しさん:2010/04/24(土) 18:54:06
全角叩きしかしてない奴はなんなんだよw
95デフォルトの名無しさん:2010/04/24(土) 18:54:25
>>89
だから、それはS式言語で、C及びC++に代わる。
じゃないでしょって言ってるんだけど?
96デフォルトの名無しさん:2010/04/24(土) 18:55:20
最大の特徴は読みにくいってこった
マクロスパゲティは食いたくない
97デフォルトの名無しさん:2010/04/24(土) 18:58:20
>>93
スタックマシーン勉強しなよ
98デフォルトの名無しさん:2010/04/24(土) 19:01:12
LINQみたいなクエリ言語用意しようぜ
99デフォルトの名無しさん:2010/04/24(土) 19:03:38
>>93
多値の複雑な型は返す場所に直返せるから
効率も稼げるよ
最近ならレジスタ数多いから数個の単純型もあんま問題ないしね
100デフォルトの名無しさん:2010/04/24(土) 19:04:22
マクロも本体と同じ構文を採用すればいい
_PRE_hoge{}みたいにプリプロセスであることを明示できればいい
101デフォルトの名無しさん:2010/04/24(土) 19:07:08
>>99
C++ベースで考えると戻り値最適化は初期化でしか使えない
代入だと既にあるオブジェクトを破棄する必要があるから
102デフォルトの名無しさん:2010/04/24(土) 19:09:02
>>100
マクロは捨てたいと思う。リファクタリングツールとして、
別添えで考えたい。

マジでマジで、今のC言語の問題の多くは
マクロが存在してることに有ると思う。

ヘッダーファイルの読み込みは、必要だけど、それ以上のことは
やってくれるな、とか思う。
103デフォルトの名無しさん:2010/04/24(土) 19:10:36
ヘッダも必要ないよ
104デフォルトの名無しさん:2010/04/24(土) 19:14:57
>>101
俺の目線はc++はダメダメ
低級言語ならその場に明示されてない動作はしないのが望ましい
コンストラクタ、デストラクタはもっと高級な言語でやるべき
105デフォルトの名無しさん:2010/04/24(土) 19:17:13
>>103
JAVAの人とよく喧嘩するんだけど、ヘッダーファイルは
実装を見せない、良い仕組みだと思うんだけど・・・

ただ、嫌う人の言い分もよく分かる気がするし。

実装を見せないと言いながら、クラス定義でprotectedな
メンバーも、ちゃっかり見せちゃうし。その辺整理すると、
記述があっちゃこっちゃしてウザイし、もうヘッダファイルいらね
と言うのもよく分かるのだが・・・

Javaみたいに無くても大丈夫、見せたくないときは別添えで、
ってのもありっちゃ有りなんだけど。
106デフォルトの名無しさん:2010/04/24(土) 19:17:17
C/C++に代わるって言ってんだし
コンストラクタ、デストラクタ、代入演算子とか
考えてしかるべきじゃないのか・・・
107デフォルトの名無しさん:2010/04/24(土) 19:18:06
>>105
ヘッダみたいなものはコンパイラが自動で出力すべき
108デフォルトの名無しさん:2010/04/24(土) 19:21:39
>>102
リファクタリングはOOPが前提
アセンブラやCレベルでは不可能
マクロがなければ必然的にポータビリティが失われる
お前の言ってる仮想言語はCの代替にはなりえない
109デフォルトの名無しさん:2010/04/24(土) 19:21:41
>>105
基本的に1度書けば情報量として十分なものを
2度以上のインクルードにも耐えられるように、
かつ、なんども書かされる作業は苦行なだけ。
110デフォルトの名無しさん:2010/04/24(土) 19:21:56
>>106に賛成。
後、戻り値に関しては、参照渡しの不透明さ(何されるのか分からない)

って問題を文法で解決するべきという話だと思う。
111デフォルトの名無しさん:2010/04/24(土) 19:25:14
>>107
それは良いかもね、foo.cをコンパイルしたときにfoo.hが出力されて、
foo関数を使う人は、foo.hをインクルードするって言う事にすれば
良いかも知れない。foo.hはコンパイラ以外書き換え不可と言うことに
すれば、とても幸せになれるように気がした。
112デフォルトの名無しさん:2010/04/24(土) 19:28:00
>>108
ポータビリティに関してはDのversionを参考にするといいよ
113デフォルトの名無しさん:2010/04/24(土) 19:33:19
>>110
構造体は代入演算子を定義できず、
代入は単純コピーのみとする、
という風にクラスと差別化すれば・・・
って、C/C++だとクラスも値型だよな
114デフォルトの名無しさん:2010/04/24(土) 19:35:46
継続できるようにしてくれ。
115デフォルトの名無しさん:2010/04/24(土) 19:37:19
イテレータいやっほーい
116デフォルトの名無しさん:2010/04/24(土) 19:39:17
値型にもnullを作ればいいんじゃない
nullの代入は、何も代入しない事と同じ扱いになる、とか
117デフォルトの名無しさん:2010/04/24(土) 19:40:01
ただし、単純型は除く
構造体とクラスのみ
118デフォルトの名無しさん:2010/04/24(土) 19:42:49
エラー処理を考えると
戻り値は正否を表す値1つの方が便利なので
引数から値を返す方法はどうしても必要だな
全部例外に置き換えるとパフォーマンスに影響するし
119デフォルトの名無しさん:2010/04/24(土) 19:43:54
スレ的にはちょっとズレた話になるけど
null大嫌い
nullableであることが必要でない場合も参照型にはnullを突っ込めてしまうので
型安全性にとっては有害以外の何者でもない

関数型のMaybeやOptionが正解
120デフォルトの名無しさん:2010/04/24(土) 19:44:07
4値論理を導入しようか
121デフォルトの名無しさん:2010/04/24(土) 19:44:40
C/C++ベースだとクラスも値型だから問題ない
122デフォルトの名無しさん:2010/04/24(土) 19:50:50
オープンソースだから実装を見せないなんて論外
123デフォルトの名無しさん:2010/04/24(土) 19:51:34
ついでにこの言語で実装されたアプリはGPL適用されるっていう事にすればいいんじゃね
124デフォルトの名無しさん:2010/04/24(土) 19:52:50
>>123
じゃあコンパイルしたら
License.txtが自動的に出てくるっていうことにしよう
125デフォルトの名無しさん:2010/04/24(土) 19:52:52
マジで作る奴なんかいないだろうからどうでもいいが
2chのライセンスはGPLのようなライセンスとは非互換だからねと
一応言っておく
126デフォルトの名無しさん:2010/04/24(土) 19:52:54
そんなことしたらバイオハザードマークつくわ
127デフォルトの名無しさん:2010/04/24(土) 19:56:01
GPLとかいうゴミなんか気にしなくて良いよ
128デフォルトの名無しさん:2010/04/24(土) 19:59:00
>>81
「リファクタリングツール」が何のことかよくわからないが、
コンパイル時に処理するC++のテンプレートはリファクタリングツールなの?

そうであるなら、別に言語に「リファクタリングツール」という機能が入っていてもいいんじゃないの。
129デフォルトの名無しさん:2010/04/24(土) 20:01:54
例えば、文字列をEUC_JPから、UTF−8に変換する関数だと

convert Parameter("EUC_JP","UTF-8") Source(euc_buf) Result(utf_8_buf);

とか、

>>125
言語の仕様は、著作権保護の対象外。言語仕様の記述は著作権保護されるけども。
130デフォルトの名無しさん:2010/04/24(土) 20:07:47
2chのライセンスと称するものが法的に有効だという言質をどっかで取ってからまた来てね
131デフォルトの名無しさん:2010/04/24(土) 20:13:04
>>130
ん?
2chの投稿規約に同意しないと書きこめないだろ
その時点で法的に規約に同意した、契約が成立したと認められるはずだ

現実に、基本的に2ch本の印税はひろゆきに行くだろ?
勿論その部分は書き込んだ奴にも流れるようだけれども
132デフォルトの名無しさん:2010/04/24(土) 20:44:53
ところでこの言語は何で実装されるの?
133デフォルトの名無しさん:2010/04/24(土) 20:47:04
開発者の情熱
134デフォルトの名無しさん:2010/04/24(土) 21:59:07
実装の話は言語仕様ができてからでいい。
135デフォルトの名無しさん:2010/04/24(土) 22:13:14
>>120
ウンモ星人乙
136デフォルトの名無しさん:2010/04/24(土) 22:18:55
多値返しの場合、デフォルトアクセス方法は欲しいよな。
cの配列みたいに先頭のデータと配列の先頭を同一視するみたいな。

>102
マクロは必須だろ。cのマクロは捨てだけど。
マクロはむしろユーザーカスタム可能なコンパイラとして考えるべき。LispとかForthとかそんな感じだよな。
137デフォルトの名無しさん:2010/04/24(土) 22:24:45
if (return, a, b = foo()) {
 a.hoge(b);
}

あゝ、邪悪
138デフォルトの名無しさん:2010/04/24(土) 23:29:18
多出力だと、その関数の型を決められないから、1出力にしたい。
それに合わせて、入力も1入力にしたい。
さらにプログラムの流れは基本的に左から右にしたい。

以上を総合して、こんな感じにしたい。{}はタプル型。
func({in1, in2}) -> {out1, out2, out3};

タプル型の型チェックはなんかうまくやる。
139デフォルトの名無しさん:2010/04/24(土) 23:36:45
低レベル言語のスレだよな
頭がLLなヤツらばっか
140デフォルトの名無しさん:2010/04/24(土) 23:46:08
低レベル言語でもオサレな機能を使いたいんだからしょうがないだろ
141デフォルトの名無しさん:2010/04/25(日) 00:02:06
関数型言語やlispマクロとか
タプルとかが美しいか?
美意識の違いだな
142デフォルトの名無しさん:2010/04/25(日) 00:05:57
隣の芝生なので
143デフォルトの名無しさん:2010/04/25(日) 01:12:58
LL(笑)
144デフォルトの名無しさん:2010/04/25(日) 01:16:32
変に意識して(笑)とか言って使えないより、道具として軽く使えたほうが便利だと思うけどね。
145デフォルトの名無しさん:2010/04/25(日) 01:20:31
LLなんて適当に使い分ければいい話
粗大ゴミのC++を置き換えれる言語を考えようや
Cは神言語だから無理
146デフォルトの名無しさん:2010/04/25(日) 01:41:23
おまえらにVSでサポートされるような言語を作れるのかな
147デフォルトの名無しさん:2010/04/25(日) 01:42:03
作れるよ。
148デフォルトの名無しさん:2010/04/25(日) 01:54:04
VSてなに
149デフォルトの名無しさん:2010/04/25(日) 01:54:10
じゃあ、明日の朝までによろしく
150デフォルトの名無しさん:2010/04/25(日) 01:55:01
Vitual Studioに決まってんだろど素人が
151デフォルトの名無しさん:2010/04/25(日) 01:58:22
ゴミクズか
152デフォルトの名無しさん:2010/04/25(日) 01:59:10
なんかGoogleが言語作ってなかったっけ?
153デフォルトの名無しさん:2010/04/25(日) 02:04:15
>>151
使ってる低能がな
154デフォルトの名無しさん:2010/04/25(日) 02:10:46
変に意識して(笑)とか言って使えないより、道具として軽く使えた方が便利だと思うけどね。
155デフォルトの名無しさん:2010/04/25(日) 02:21:33
変に意識して(笑)とか言って使えないより、道具として軽く使えた方が便利だと思うけどね。
156デフォルトの名無しさん:2010/04/25(日) 02:27:26
>>153
おやおや自己紹介ですか?
いくら低能でも、己がそうであるという事実を主張することはできるようですね。
あ、言葉が難しすぎて理解できませんか。低能ですからね。
では低能であるあなたにも分かるように言わんとすることを言わんとば、あなはた馬鹿だと言うことです、
、か。早く仕事が見つかるといいですね。
157デフォルトの名無しさん:2010/04/25(日) 02:39:00
>>156
すまん。痛いとこだよな
やっぱ恥ずかしいもんな
158デフォルトの名無しさん:2010/04/25(日) 02:41:54
>>108
お前の知ってる設計技術がオブジェクト指向しか無いからそういうんだろう。
159デフォルトの名無しさん:2010/04/25(日) 02:43:51
はぁ、基本を勉強したことが無い土方叩き上げの連中は知識の幅が狭くて困る。
学生でも土方みたいな考え方の奴がたまにいるから困る。
そういうヤツに限って自分はプログラミングスキルが高いと勘違いしているから困る。
160デフォルトの名無しさん:2010/04/25(日) 02:45:14
今日は自己紹介が多いな
161デフォルトの名無しさん:2010/04/25(日) 02:45:35
せめて何か新しいことを提案するなら大学院の博士課程を卒業してからにして欲しいものだ。
それ以外の奴でもたまに広い見識を持った奴はいるけど、ほとんどがそうでないのだから、
言われた通り手を動かすだけにして欲しい。
162デフォルトの名無しさん:2010/04/25(日) 02:46:22
163デフォルトの名無しさん:2010/04/25(日) 02:47:50
自分に足りないものを見つける能力がないと>>161みたいになってしまう
164デフォルトの名無しさん:2010/04/25(日) 04:26:09
とりあえずD厨とVS脳とIDE厨と電波がいないと始まらない
165デフォルトの名無しさん:2010/04/25(日) 04:56:19
IDE要否はライブラリの善し悪しだから言語の式記述能力とは別問題。

IDE使用前提のシーケンス言語でもいいけど
166デフォルトの名無しさん:2010/04/25(日) 05:04:51
LISPでCのマクロを書けるのはいい。
だけどS式でCのプログラムは書きたくない。
で、どーしたらいいんだろう?
167デフォルトの名無しさん:2010/04/25(日) 05:23:28
ファイルの拡張死は何がいい?
168デフォルトの名無しさん:2010/04/25(日) 05:24:32
複雑なマクロはオナニー
lispだからこそ生きるもんだ
Cでもinlineとconst enumで大半が不要だろ
169デフォルトの名無しさん:2010/04/25(日) 06:44:20
マクロ低機能化でよければ
代入だけでもC形式にすればだいぶ小奇麗になると思うよ
170デフォルトの名無しさん:2010/04/25(日) 12:19:38
>>168
ある意味正しいけど
一人ないし少数精鋭で使うならオナニーでも結構使いでがあるんじゃないの

構文木が弄れるLispマクロなら、例えばCのswitchがいやなら
自分で構文を作れるし
fp = fopen(name, "r");
if (fp == NULL) エラー処理
else ...
みたいな決まりきった手続きを抽象化した構文を自分で作れる
171デフォルトの名無しさん:2010/04/25(日) 12:23:16
>>170
やっぱり、ない方がいいな。
172デフォルトの名無しさん:2010/04/25(日) 12:27:54
演算子オーバーロードの弊害が言われる中でそんな自由度追加しようだなんて
173デフォルトの名無しさん:2010/04/25(日) 12:31:23
もしかしてLispのマクロが「そういうもんだ」と知らずに議論してたのかw
174デフォルトの名無しさん:2010/04/25(日) 12:37:40
隣の芝生なので
175デフォルトの名無しさん:2010/04/25(日) 12:55:28
JavaだってLispで言うようなマクロがないわけじゃあない。
ただ言語仕様に組み込まれているだけ。
たとえば、文字列の連結や、Enumによるswitch。
7だとStringによるswitch。こいつらはコンパイル時に別のソースコードに置き換わる。

ある文法構造をもっと平易な文法構造に書き直すようなことはよくあること。
ユーザが勝手にマクロ作るのも許すが、
基本的には言語のライブラリとしていくつか構文を用意して
それを使わせればいいんだろう。
176デフォルトの名無しさん:2010/04/25(日) 13:01:04
#define BEGIN {
#define END }
#define FOREVER for (;;) BEGIN

ああ、すばらしい
177デフォルトの名無しさん:2010/04/25(日) 13:02:15
Cのマクロはトークンの解釈しかしないから
その程度が限界
178デフォルトの名無しさん:2010/04/25(日) 13:02:26
自由度を無造作に増やすと可読性が落ちることがなんでもっと問題視されないんだろうね。
179デフォルトの名無しさん:2010/04/25(日) 13:05:41
>>178
それが嫌なら
Effective (これから作る言語名)
でもすぐに出版してマクロの使い方を啓蒙するしかないな
180デフォルトの名無しさん:2010/04/25(日) 13:10:13
啓蒙なんて時間がかかるものは無駄。
言語仕様でシステムとして制限するほうが即効性高い。
181デフォルトの名無しさん:2010/04/25(日) 13:13:15
あのね、庶民はバカがデフォだから啓蒙なんて意味がないんだよ。
だからバカでもチョンでも使える物じゃないとだめなんだよw
182デフォルトの名無しさん:2010/04/25(日) 13:14:24
>>178
可読性は関係ない
不要なものをわざわざ作るのは無駄だが、既に作った後なら特に問題視されない
183デフォルトの名無しさん:2010/04/25(日) 13:16:11
今のCで言えばコンパイラやCPUの互換性向上のために使う位か
後は定数のdefineをasmとCで共用できるのは便利
175みたいにコンパイラに組み込んでしまうのは全く別な議論だし
入れる際に相当揉むのに、安易に構文いじったりするためのマクロなんて全く不要
184デフォルトの名無しさん:2010/04/25(日) 13:16:56
JavaもC++から学習要素を排除して受けた面があるな。
185デフォルトの名無しさん:2010/04/25(日) 13:17:37
>>182
こういうやつがC++でオナニーしてるんだな
186デフォルトの名無しさん:2010/04/25(日) 13:17:51
バカでもチョンでも使えて
バカやチョンが書いたコードはバカやチョンが強引にプロジェクトマージしてきても深い深いpackage-nameの奥へ自動的に追い遣られる言語がイイね

言語機能かどうか知らんけど
187デフォルトの名無しさん:2010/04/25(日) 13:19:59
名前の衝突が困る人間なんてそうはいないのになんであんなに重要視されるのか不思議で仕方ない。
188デフォルトの名無しさん:2010/04/25(日) 13:20:20
カメラで顔チェックしてデブサやバカやチョンが書いたコードは自動で排除
かわいい女の子が書いてたら俺んとこにメールするようなコンパイラが欲しいね
189デフォルトの名無しさん:2010/04/25(日) 13:22:48
今のCマクロでいうと#define中で#ifXXで条件コンパイルしたい使いたいときはあるな
190デフォルトの名無しさん:2010/04/25(日) 13:29:09
Javaを仕事で使ったことないんだが、リリース版とデバッグコードどう共存させてるの?
191デフォルトの名無しさん:2010/04/25(日) 13:35:30
>>185
オブジェクト指向でオナニーしてると言えばいいのに
OOを擁護しつつC++だけ廃止するのは無理だよ
192デフォルトの名無しさん:2010/04/25(日) 13:36:45
Cプログラマーは関数を特別のものと見做さない
Lispプログラマーは構文を特別のものと見做さない
それだけの話だ
193デフォルトの名無しさん:2010/04/25(日) 13:40:48
>>190
基本同居。実行時も同居。
if(LOG.isDebugEnabled()){

}

ただし、finalなboolean定数にtrueかfalseを持たせて
if(IS_DEBUG){

}
なんてやれば、if自体はその定数にしたがって消滅したりするようにできたりする。
あとは設定ファイルでデバッグ用のコードをAOPさせたりとかかな。
194デフォルトの名無しさん:2010/04/25(日) 13:48:16
だけとつけただけで強くなれた気がした15の夜
195デフォルトの名無しさん:2010/04/25(日) 13:48:57
言語仕様で消えるほうが安心感あるな。バグも生むけどw。
196デフォルトの名無しさん:2010/04/25(日) 13:50:02
>>192
lispに構文らしい構文なんてないからな
197デフォルトの名無しさん:2010/04/25(日) 13:50:28
Cプログラマが構文を特別なものと見做さないとどうなります?
C言語を1次元のトークン配列から1パスで構文木を作るとパーサが大きくなる。
Lispはトークン配列を一度リストとして読み込みマクロ展開したあと
構文木を構築するというように2パスになっている。
トークンはリードマクロで変更可能だ。
通常のマクロはリストを操作するプログラムで読み込み時にS式のフィルタとして働く。
198デフォルトの名無しさん:2010/04/25(日) 13:59:34
>>193
ひでえ
それじゃデバッグ用に大きなライブラリをリンクするようなケースには対応できないじゃん
まあjavaごときで速度だのサイズだのを気にするのが間違いなのか
199デフォルトの名無しさん:2010/04/25(日) 14:01:02
人は両極端を好む
マクロを全く使いたくないか、使うとしたら最強のマクロを使いたくなる
200デフォルトの名無しさん:2010/04/25(日) 14:07:28
>>198
Javaだとクラス単位でロードするから
ライブラリのファイルサイズはともかく、メモリ単位では関係無し。
クラスローダーが文句言わない範囲のリンクをすればいい。
201デフォルトの名無しさん:2010/04/25(日) 14:10:27
>>198
だからeclipseはあれほど重い
202デフォルトの名無しさん:2010/04/25(日) 14:14:30
>>201
Eclipseはあんだけ機能持ってれば重くて当然かな。
ほかの言語で実装しても正直重さは五十歩百歩になりうる。
ある種、富豪的プログラミングっちゃ富豪的。

このスレだと低級言語だから富豪的なのは禁止かな。
VM前提の方がいろいろとやりやすい事が多いんだけど、
たぶん近代的なOSで走るアセンブラに落とす前提だろうから。
203デフォルトの名無しさん:2010/04/25(日) 14:15:45
> たぶん近代的なOSで走るアセンブラに落とす前提だろうから。

別にCトランスレータでもいいんじゃないの
「ソフトウェア作法」のratfor的な
204デフォルトの名無しさん:2010/04/25(日) 14:16:54
分かった。アセンブラなのにC#みたいにGUIアプリが作り易い。これな
205デフォルトの名無しさん:2010/04/25(日) 14:18:03
>>203
Cトランスレータ…
まるでC++の再誕を見ているようだ。
206デフォルトの名無しさん:2010/04/25(日) 14:18:35
>>202
>ほかの言語で実装しても正直重さは五十歩百歩になりうる
そんな絶対に証明不可能なことを言い切られても
207デフォルトの名無しさん:2010/04/25(日) 14:21:43
GC系の言語でかかれたアプリは、基本的にWindows XPとは相性最悪
貧乏性のXPは何かとワーキングセットを最小化しようとするが
一方でGCは非局所的にヒープを舐めたがるので、
GCのためだけにページが出たり入ったり
ウンザリするような事態が引き起こされる
208デフォルトの名無しさん:2010/04/25(日) 14:23:24
>>198
そこでeppの登場ですよ。
eppを使えば、javaをS式として扱ってプリプロセッサを書ける。
これ最強。
209デフォルトの名無しさん:2010/04/25(日) 14:27:52
結局S式が出てくんのはさー
ごくシンプルなルールで、木を簡単に記述できるからなんだよな
そんだけの話

XMLは冗長だしね
210デフォルトの名無しさん:2010/04/25(日) 14:29:04
>>207
他のOSはどうなの?
使われないけど参照は残ってるものはswap行きだけどswapからの参照だけはメモリ上にもある
ようなOSってあるのかしら?
211デフォルトの名無しさん:2010/04/25(日) 14:30:27
>>210
ある程度は似たような問題はあると思う
XPが特に酷いのは、ウィンドウを最小化しただけで
ワーキングセットを最小化するような仕様だからだよ
212デフォルトの名無しさん:2010/04/25(日) 14:40:40
windows 7 とかなら実は、.netに対応して世代別GCに対応したMRUが搭載されてたりして

213デフォルトの名無しさん:2010/04/25(日) 17:32:11
>>205
Objective Cもだな
C++が出始めた時勉強のために
プリプロセッサ作ったりしたが懐かしい
214デフォルトの名無しさん:2010/04/25(日) 18:41:58
>>129
がガン無視されて寂しいんだけど、関数の引数を別けて定義するのは
良くないかな?
関数定義

int convert Parameter(char* source_code="EUC_JP",char*) ←Parameterはデフォルトを定義出来る
      Source(char*)
      Result(char*)
{

}

使う方。
convert Parameter("EUC_JP","UTF-8") Source(euc_buf) Result(utf_8_buf);
215デフォルトの名無しさん:2010/04/25(日) 18:43:02
>>214
新しく作る言語からは糞長い名前付けをする文化を捨て去りたい。
216デフォルトの名無しさん:2010/04/25(日) 18:43:43
source_codeとか長いからsrcとかsとかにしろよ
217デフォルトの名無しさん:2010/04/25(日) 18:43:47
C系の悪習を更に悪化させた感じだな
218デフォルトの名無しさん:2010/04/25(日) 18:48:10
functionを関数と訳すなよな
今更だが

ファンクションで良かったんじゃね?
219デフォルトの名無しさん:2010/04/25(日) 18:51:54
>>214
名前付き引数で、「Parameter」だけは予約語ってこと?
220デフォルトの名無しさん:2010/04/25(日) 18:57:56
>>219
やっとまともな人が来てくれた。
「Parameter」「Source」「Result」が予約語。
オブジェクト指向の多態の時にコンパイラが分かりやすくて良いんじゃないか
と思うんだ。Source以外は、省略可能と言うことで。
221デフォルトの名無しさん:2010/04/25(日) 18:59:12
その程度の機能のために予約語3つww
222デフォルトの名無しさん:2010/04/25(日) 19:05:06
>>221
いやいや、大切なことなんだよ、大域最適化の障害になってるから。
この引数はなんの目的があって、関数に渡されているのか分からないから
触れない。ってコンパイラの負担になってる。

Result以外は、その関数で変更がないって事はとても重要。

見た目にも読みやすいし、最近のGUI系のあの、山のような引数
どれがなんなのか、分からないし。一々関数のリファレンスに当らなくても、
ソース読んでるだけある程度その関数の動きが読める方が良いと思うし。

可読性と、コンパイラの最適化に有効なので、記述時のタイプ量が増える事は
払えるコストだと思うのです。
223デフォルトの名無しさん:2010/04/25(日) 19:09:47
>>222
それなら、各パラメータにユーザー定義の任意の属性を付けられて、
各属性にコンパイラに対する情報を載せられるようにしたい。

さすがにその3つを予約後にするのは下品だし、オサレじゃない。
224デフォルトの名無しさん:2010/04/25(日) 19:11:31
前スレでCPU固有言語にこだわってたヤツか?
225デフォルトの名無しさん:2010/04/25(日) 19:12:12
この下品さは、そうだろうね。。
226デフォルトの名無しさん:2010/04/25(日) 19:14:08
>>224
そうそう。俺それ。

>>223
そう言う反論は宗教論争なので、もう少し違った感じで。
例えば、ParameterとSourceの関係が問題になるとか、
そっちの頭の良い異論が欲しい。
227デフォルトの名無しさん:2010/04/25(日) 19:18:36
低レベルプログラミングからも
コンパイラ作成からも遠そうだし
オサレ系でもないし
内容からして高校生位。。か?
228デフォルトの名無しさん:2010/04/25(日) 19:20:19
>>224
お前のエスパー能力がうらやましい
229デフォルトの名無しさん:2010/04/25(日) 19:24:05
>>226
定義もされていない「俺予約語」について頭の良い議論ができるわけ無いだろ
230デフォルトの名無しさん:2010/04/25(日) 19:24:34
>>214
このコードが何を意味してるのかわからないんだが
戻り値はchar*なの?intなの?
231デフォルトの名無しさん:2010/04/25(日) 19:28:03
>>214
仮引数の名前がないし、何が何だかわからん。
232デフォルトの名無しさん:2010/04/25(日) 19:28:52
>>227
こう言うのは意外におっさんだったりする。
233デフォルトの名無しさん:2010/04/25(日) 19:31:13
いっそ関数名には.exeをつけて
オプションには/をつけて結果には>でいんじゃね
234デフォルトの名無しさん:2010/04/25(日) 19:32:08
>>232
俺のエスパー能力もこれまでか
235デフォルトの名無しさん:2010/04/25(日) 19:36:40
Resultは多値を使って返したらすっきりすると思う。
パラメータとソースはうーん。たとえば、オブジェクト指向ならオブジェクトがソースで
パラメータは関数の引数にしたらいいのかなと。ソースが複数ある場合はコンビネーションメソッドみたいなのがあって
このオブジェクトとこのオブジェクトにメッセージをこのパラメータで送って渡すみたいにするとか。

char* (char* src_charset,char* dst_charset)::encode(char* src_string) {
return translate(src);
}
文字コードオブジェクト2つにエンコードメッセージをsrc_stringで渡すという具合に。
使い方は
char *rc = ("euc-jp","utf-8").encode("eucmojiretu");
という具合
236デフォルトの名無しさん:2010/04/25(日) 19:44:21
全く意味不明
237デフォルトの名無しさん:2010/04/25(日) 19:44:52
.演算子が泣いてるぜ
238デフォルトの名無しさん:2010/04/25(日) 19:49:43
>>222
ParameterとSourceの違いは?
239デフォルトの名無しさん:2010/04/25(日) 19:58:49
まずカリー化とかとは違うのかな
240デフォルトの名無しさん:2010/04/25(日) 20:00:19
カリー化をしってる奴があんなトンチキなことを書くとは思えん
241デフォルトの名無しさん:2010/04/25(日) 20:03:25
ネタ振ってくれるなーw
でもちょっとユンユンし過ぎじゃね
彼にカリーさんは辛口過ぎるし
242デフォルトの名無しさん:2010/04/25(日) 20:06:20
新しい言語の前にちゃんとC系をマスターして、
lispとhaskellとsmalltalkあたりを勉強してはどうだろう
243デフォルトの名無しさん:2010/04/25(日) 20:06:47
>>239
カリー化と違うんじゃなくて、カリー化しやすくするってことに
つながる訳ですよ。カリー化しやすくなってると、大域最適化に
強くなると。
244デフォルトの名無しさん:2010/04/25(日) 20:16:06
後悔関数
245デフォルトの名無しさん:2010/04/25(日) 20:48:56
カリー化で大域最適化に強くなるなんてどこの宗教だよ
246デフォルトの名無しさん:2010/04/25(日) 21:00:43
カレー板でやれ
247デフォルトの名無しさん:2010/04/25(日) 21:01:07
>>245
例えば、文字コンバートで言えば、ソースコードの全域にしたがって、
EUC_JP→UTF-8の変換しかやっていなければ、それ以外の文字コード変換を
さっくり削除して、それに必要な変換テーブルもさっくり削除出来てで、
もっと言えば、その他の文字コードで必要な呼び出しとかスタック積み上げ
とかも全面的に削除して、そもそもEUC_JPという引数も、定数に変更して。

と言うことが可能になっていくんだよ。
248デフォルトの名無しさん:2010/04/25(日) 21:04:06
で、カリー化は?
249デフォルトの名無しさん:2010/04/25(日) 21:04:26
>>220
ParameterとSourceの違いは?って聞いてるんだけど。
250デフォルトの名無しさん:2010/04/25(日) 21:08:20
>>249
>>226で自分でちゃんと書いてるので、それに
そういうべたな質問かぶせてくる馬鹿に答えるメリットはないんだよね。
251デフォルトの名無しさん:2010/04/25(日) 21:16:20
>>250
いや、引数をParameterとSourceで分けて主張した意味が全く理解不能だったので、
何か深い哲学的な意味があるのかと思って気になったから聞いたんだけど。
252デフォルトの名無しさん:2010/04/25(日) 21:18:27
>>250
バカアホ言う前に、自分がちゃんとした文章書いているのかを一度見直したほうがいいよ
253デフォルトの名無しさん:2010/04/25(日) 21:19:41
>>252
馬鹿に伝わらないように書いてるので。
まぁ馬鹿がタカルんだけど(w
254デフォルトの名無しさん:2010/04/25(日) 21:26:53
×伝わらない
○伝えられない
255デフォルトの名無しさん:2010/04/25(日) 22:46:04
すげーなこのすれw
256デフォルトの名無しさん:2010/04/25(日) 23:04:48
Cの不満点を解消しただけのalternative Cで十分なんじゃないの?
レガシーフリーのごとく過去のしがらみを捨てられればそれでいいよ。
257デフォルトの名無しさん:2010/04/25(日) 23:10:50
こういう言語どう?
男=1 女=0 という変換するだけでコンパイルが完了する言語
258デフォルトの名無しさん:2010/04/25(日) 23:12:13
>>257
女が0?
とんでもない性差別ですね
259デフォルトの名無しさん:2010/04/25(日) 23:13:20
>>258
性器の形を模しているので差別ではありません
260デフォルトの名無しさん:2010/04/26(月) 00:08:20
>>251
CPU固有言語だぞ。哲学とか。。
主張?につっこみどころ多すぎて
観戦させてもらうわ
261デフォルトの名無しさん:2010/04/26(月) 00:09:16
>>260
関数が、固有命令?w
262デフォルトの名無しさん:2010/04/26(月) 00:17:25
>>261
読めるなら前スレ読みな
263デフォルトの名無しさん:2010/04/26(月) 00:27:23
>>262
1から全部読んでるけど何の関連性も見つかりません
264デフォルトの名無しさん:2010/04/26(月) 00:45:31
自分の特殊な表現が他人に常に理解されるとは思わない方がいいよ。

人と話をするなら出来るだけ一般的な表現をした方が誤解を招かずにスムーズなコミュニケーションが出来て自分も気分がイイはず。
265デフォルトの名無しさん:2010/04/26(月) 01:05:52
id欲しいな
266デフォルトの名無しさん:2010/04/26(月) 01:18:38
>>264
ダネ
彼はたぶん自分が言っていることすら
どういう意味があるのか理解していないんだと思う。
脳内に言いたいことがはっきり論理的に出来上がっているなら、
それを書くのに何の抵抗も無いはずなんだけどな。
267デフォルトの名無しさん:2010/04/26(月) 05:13:42
開発したいであって、開発するじゃないのはなぜ?
268デフォルトの名無しさん:2010/04/26(月) 06:06:45
開発しないから
269デフォルトの名無しさん:2010/04/26(月) 10:50:48
ではやはりあげておくべきですね。
270デフォルトの名無しさん:2010/04/26(月) 19:37:16
id?
Objective Cのか?
271デフォルトの名無しさん:2010/04/26(月) 20:52:54
さすがにそのクソ言語に学ぶ所は無い
272デフォルトの名無しさん:2010/04/26(月) 21:09:18
こういう糞言語を作ってはいかん、という点が学べるのでは
273デフォルトの名無しさん:2010/04/26(月) 21:22:16
たしかに。
既にCがあるんだからそれをベースにちょっといじってオブジェクト指向を載せてみようなんて事をすると、こういう糞になるという見本だな。
やはり新言語は1からしっかりと考えるべきだな。
274デフォルトの名無しさん:2010/04/26(月) 22:23:42
じゃあまずObjective Cの悪かった点を纏めて行こうか
275デフォルトの名無しさん:2010/04/26(月) 22:33:37
文法がキモい
276デフォルトの名無しさん:2010/04/26(月) 22:43:21
C++とObjective Cは、同時期に世間で認知されだしたが、後者はジョブズしか使わなかった。
277デフォルトの名無しさん:2010/04/26(月) 23:28:47
でもObjective Cのシェアがここに来て急上昇
結局モバイルで使える言語が今後の覇権を握る
その点についても考慮しなければならんぞ
278デフォルトの名無しさん:2010/04/26(月) 23:38:32
>>277
C#だな。ジョブズはFlashよりも.NETが怖かったんだとおもう。
279sage:2010/04/27(火) 00:13:40
Objective C の悪い点は[]で メッセージ という拡張が中途半端すぎるという点。
その点を改善してるのがたとえば Vala なんじゃないか。
go もそんなかんじだけどGCが必須なんだっけ?
Objective C のよい点はGCを使わなくてもよいところにある。

280デフォルトの名無しさん:2010/04/27(火) 00:14:57
まちがった
281デフォルトの名無しさん:2010/04/27(火) 00:17:49
heap管理の遅さとそれを管理しきれなかったから、GCが出来たんじゃ
282デフォルトの名無しさん:2010/04/27(火) 00:25:46
// 式
function Exp(l,op,r){this.l=l;this.op=op;this.r=r}
Exp.prototype.toString = function() {
 return "["+this.l+",\""+this.op+"\","+this.r+"]"
}
var powers = {}// 戦闘力表

// 読み込み処理
function read(str) {
 var arr = str.split(/\s+/) // 文字列を配列にする
 // 戦闘処理
 function battle(power) {
  var result = arr.shift()// とりあえずの結果を取得
  while (powers[arr[0]] > power) {// きごうの力が強ければ勝ち抜く
   var name = arr.shift()// 名前取出し
   var nextpower = powers[name] // 次の戦いで使う力取得
   var nextresult = battle(nextpower) // 次の戦いを行う
   result = new Exp(result, name, nextresult)// 式作成
  }
  return result
 }
 return battle(0)// 力0で戦闘開始
}
// 戦闘力登録
powers["+"] = 10
powers["*"] = 20
alert(read("1 + 2 * 3 + 2 * 3"))
283デフォルトの名無しさん:2010/04/27(火) 00:27:37
簡単な下降型の演算子順位法のパーサを書いたので参考にしてください。
これをいろいろ拡張してCっぽくすればマクロも作れるようにできるよっと。
284デフォルトの名無しさん:2010/04/27(火) 04:03:14
>>279
2.0からGC使えるようになったね
ObjCはCと思うからいかんのよね
アレはSmalltalkにCのふりかけかけたもんだし
goはどっちかいうと(C+python)/2風味でGC有り。gccgoはまだ未実装

まあObjCに限らず今後はUIを含むような
Webやデスクトップのアプリ作る言語はGC有りでいいんじゃね
組み込みや制御系やOSなんかはCみたいな住み分けで。
285デフォルトの名無しさん:2010/04/27(火) 16:28:57
このスレはCみたいなのを目指してんだろ
286デフォルトの名無しさん:2010/04/27(火) 19:07:54
C言語の問題点。
1、コンパイラを軽く書きたいので色々端折ってる
2、軽く書きたいと良いながら、先読みが必要だったりする
3、軽く書けるので膨大な方言が発生し、それの取りまとめで仕様がボロボロ
4、機能の追加が必要最小限に留められているので、色々中途半端

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

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

そこで、プログラミング言語40年の歴史から学べる知見を総動員して、
C言語的なプログラミング言語を過去の遺産にとらわれず、今、開発
するとすればどんな仕様になるのだろうか?という事。

287デフォルトの名無しさん:2010/04/27(火) 19:14:20
でもお前らプログラミング言語40年の歴史から学べる知見なんて持ってねぇだろ?どうすんの?
288デフォルトの名無しさん:2010/04/27(火) 19:32:24
せきねさんに頼もう
289デフォルトの名無しさん:2010/04/27(火) 19:52:15
そうやって作ってるのがDじゃないのか
290デフォルトの名無しさん:2010/04/27(火) 20:00:12
if(A){B}
のAの部分に副作用を伴う式が書けてしまうのは混乱の原因にならないカナ
291デフォルトの名無しさん:2010/04/27(火) 20:06:22
別にならない
292デフォルトの名無しさん:2010/04/27(火) 20:06:44
>>289
DはC言語の部分は守るって言ってるから、系統としてC++を再デザイン。
293デフォルトの名無しさん:2010/04/27(火) 20:09:43
いや、全然守ってないし
294デフォルトの名無しさん:2010/04/27(火) 22:15:03
よく低水準言語の話で、自分でメモリ管理もできないヤツがどうのこうの、って言うけどさ
必ずメモリ管理するなら最初からあったほうがいいんじゃないの?
メモリ管理しないほうがいいケースって具体的にどんなの?
295デフォルトの名無しさん:2010/04/27(火) 22:20:44
何が、あった方が良いって?
296デフォルトの名無しさん:2010/04/27(火) 22:21:00
メモリマネージャだのガーベージコレクタを「作る側」なのが低水準言語だから
297デフォルトの名無しさん:2010/04/27(火) 22:26:37
過去のメモリマネージャの欠点にとらわれず、知見を総動員してメモリ管理する。
298デフォルトの名無しさん:2010/04/27(火) 22:34:43
バッファオーバーフローを考慮しない標準ライブラリの話な
299デフォルトの名無しさん:2010/04/27(火) 22:35:36
>>294
メモリー管理機能は当然あったほうがいいよ。

もちろんメモリマネージャだのガーベージコレクタを作るときには、その機能を使わずに作るだろうけど
低水準言語では常にどんな場合でもフル機能が使えるわけじゃないからね。

作ってしまえば、それ以外の機能を作るときに十分役に立つ。
300デフォルトの名無しさん:2010/04/27(火) 22:40:49
>>286
Cの仕様のどこがはしょられていて、どこがぼろぼろなのかね。
かなり昔は方言もいろいろあったけど、今では ANSI C の部分は共通だし、独自仕様を使っているところはもともと独自でないといけないところ。

C++の記号が珍妙ってなんだろな。
ライブラリが肥大化しすぎているだけで、言語仕様自体はそんなに複雑ではない。(パースはしにくい)
301デフォルトの名無しさん:2010/04/27(火) 22:46:40
C/C++ は enum とか完全に終わってるだろww

過去のしがらみで修正不能だしwwwwww
302デフォルトの名無しさん:2010/04/27(火) 22:52:58
自動化すると修正不能だが手動でやれば融通がきく点が低級言語のメリットだな
303デフォルトの名無しさん:2010/04/27(火) 22:54:16
Cのenum便利じゃん
304デフォルトの名無しさん:2010/04/27(火) 22:57:23
歴史のしがらみ==自動化のしがらみ
305デフォルトの名無しさん:2010/04/27(火) 22:59:06
「自動化」って何だ?
306デフォルトの名無しさん:2010/04/27(火) 23:01:16
enumは0xで型付きにできる
307デフォルトの名無しさん:2010/04/27(火) 23:05:31
enum は便利な #define としてあとからわざわざ導入したもの。
308デフォルトの名無しさん:2010/04/27(火) 23:05:35
>>305
configure; makeとかuse strict;を使うこと
309デフォルトの名無しさん:2010/04/27(火) 23:07:53
310デフォルトの名無しさん:2010/04/27(火) 23:33:57
型付って何?
いまでもワーニングでてた気がするが
311デフォルトの名無しさん:2010/04/27(火) 23:38:52
enum定数に型をつけられる
charとかshortとか
312デフォルトの名無しさん:2010/04/27(火) 23:40:57
あまりいらないな。
intだけでもいい。あっても邪魔じゃないが。
313デフォルトの名無しさん:2010/04/27(火) 23:44:07
バイナリで保存したい時にサイズが分からないってんじゃ困るっしょ
314デフォルトの名無しさん:2010/04/27(火) 23:44:52
何の話?
315デフォルトの名無しさん:2010/04/27(火) 23:45:02
sizeof
316デフォルトの名無しさん:2010/04/27(火) 23:46:39
>>315>>313へのレス?>>314へのレス?
317デフォルトの名無しさん:2010/04/27(火) 23:46:54
まるでcharやshortがヘッダやsizeofなしにサイズが分かるような口ぶりだな
318デフォルトの名無しさん:2010/04/27(火) 23:48:30
そのためのstdint.hだろ
319デフォルトの名無しさん:2010/04/27(火) 23:51:44
んなわけない
320デフォルトの名無しさん:2010/04/28(水) 00:01:51
D言語はC言語のプリプロセッサは無くしてC++のようなテンプレートを導入し、
mixinでソース文字列をコンパイル時に生成したり、
さらに構文木までいじれるようにするとか何とか言ってたりしてます。
ただ、構文解析を楽にするための文法の変更とかはしてないJava,C#と同系統な発展になってますね。
javascript,ActionScript,haXe,Scala等は構文解析が楽なデザインになっているのではないかと。

それをもっと分かりやすくってことを考えると式を演算子で結ぶ式言語ですべて表せるものがいいのではないか?
という主張をオレはしてるのですけど、手法がよく知られていないのか、まだないのか分からないですが、
分からないので手探りな状態で開発したいけどすぐには出来ないでいます。
B言語は動的な性質を持ってたように思うので、C言語を作る前にB言語を作る手法を考えるのがよいのかなと。
でB言語をjavascriptにするのか、javascriptをマクロを扱えるように式ベースにした言語を使うのか、
式ベースなpythonにするのかで、出来上がる言語の性質が違ってきますよ。
一度変えたら次のチャンスはまた40年後ですよってなると俺は生きてないかもしれない。
LispのマクロはCのプリプロセッサより強力でDSLはソースを短く分かりやすくする。
ということは知見の1つでしょう。
優先順位付きの演算子がないと一般には受け入れられないのも間違いなさそうですし。

ifの条件はbool以外はワーニングがいいでしょうね。
321デフォルトの名無しさん:2010/04/28(水) 00:05:20
最後の行でいきなり細かい話でワラタ
322デフォルトの名無しさん:2010/04/28(水) 00:20:47
式言語はろくなもんじゃない
myはきたない文でletはきれいな式だとか馬鹿馬鹿しい
323デフォルトの名無しさん:2010/04/28(水) 00:25:47
式言語って何?
324デフォルトの名無しさん:2010/04/28(水) 00:45:24
式言語の人々
○lambdaさん
○CPSさん
○IOモナドさん
○letさん
325デフォルトの名無しさん:2010/04/28(水) 00:46:55
letはlambdaの構文糖じゃなかったか
326デフォルトの名無しさん:2010/04/28(水) 00:48:23
式言語の定義は?
327デフォルトの名無しさん:2010/04/28(水) 00:50:50
関数型言語と何が違うんだろう
328デフォルトの名無しさん:2010/04/28(水) 00:54:31
メリットが良く解らんね
329デフォルトの名無しさん:2010/04/28(水) 01:02:04
>>326
ちょっと「式言語」って言ってみたかっただけ。ゴメンナサイ
330デフォルトの名無しさん:2010/04/28(水) 01:10:35
ぐぐるとJSPのELばっか出てくるのな
331デフォルトの名無しさん:2010/04/28(水) 01:12:28
式神の城
332デフォルトの名無しさん:2010/04/28(水) 01:14:16
式言語→四季言語→季語
ということでよろしいか
333デフォルトの名無しさん:2010/04/28(水) 01:52:54
Dは問題外
EかFしか興奮しねえな
334デフォルトの名無しさん:2010/04/28(水) 05:13:05
>>322
たしかに、式言語といえば、JSPですね。
ここで言った式言語ってるのは言語を作るための言語のこと。
XML関連の研究とかだと正規生垣言語というものなのかな?
理論的に正規生垣言語となるかはわからないのですけど。
HTMLに対するSGML、
LISPに対するS式、
Dylanに対するD式で
新しいC言語を作るための言語です。

オレはこの言語にC式って名前をつけたんだけど、
それが本当にふさわしいのかわからないので、式言語とだけ書きました。

新しいC言語は正規木文法で定義されたらいいのではと思うのだけど、
それだと、ユーザー定義の演算子を定義できるかどうかもわからないところです。

メリットとデメリットはHTMLとXHTMLの違いを考えれば分かりやすくて、
HTMLはxmlに囚われることなく定義できるけど、その分パーサは作りにくいのが、
XHTMLはXMLのパーサを使えばいいので楽。XMLのパーサ自体もHTMLのパーサを作るより楽だ。
そして、XHTMLはXMLValidなので美しいと感じるかどうかは人によるけど、一定の基準になります。
ただ、文書を書くにはXMLのほうが、長くなる。エラー復帰はすばらしいHTMLのパーサに劣る。
といったことになるかもしれないと。
335デフォルトの名無しさん:2010/04/28(水) 05:15:51
関数型言語との違いは、まず目指す見た目です。
関数型言語は基本的に論文とかで使う数学の形式的な言語に近いと思います。
ここで考えているのは見た目がC言語に近いものです。
あと、関数型言語は処理系も含みますが、
C言語風の式言語の定義には処理系は含みません。
式をベースとしているからといって、関数指向のプログラミングを行う目的だけに
特化しようとも考えていません。今は高級アセンブラ用として考えているのですよね。
ScalaはC言語風の関数型言語ですが、式をベースとしていません。
DylanやNemerleも関数型言語で式をベースとしていますが、優先順位についてよくわかりませんし、
LISPのリーダマクロ的な手法のようなので自分が作ってみたかんじでは難しと感じます。
CyanはC言語風の式言語も採用しているプロトタイプベースのオブジェクト指向言語で理想に限りなく近いものです。
ただ、オフサイドルールはいらないだろ?っていうのが持論です。
なぜなら、S式にオフサイドルールは余計だから。
最小のルールでC言語風の表現ができればいいのです。
オフサイドルールは過剰なスペックだと思うのです。
336デフォルトの名無しさん:2010/04/28(水) 07:09:01
文脈自由文法が自由すぎて生きるのが辛い?
337デフォルトの名無しさん:2010/04/28(水) 07:10:04
CPU固有言語君か?
コンパイラの本とか読んだことある?
中田さんとかWirthとかAhoとか。
338デフォルトの名無しさん:2010/04/28(水) 07:20:25
Cの系譜は何をするにも新しい文法を用意してるから
一般化は無理なんじゃないか
339デフォルトの名無しさん:2010/04/28(水) 07:23:22
文法的にいうとC/C++はあんまシンプルじゃないよな
340デフォルトの名無しさん:2010/04/28(水) 09:10:49
で、お前ら的にF#はどうよ?
341デフォルトの名無しさん:2010/04/28(水) 09:17:53
Cの文法のどこが複雑なのだろう。C++もたいしたことないけどな。
342デフォルトの名無しさん:2010/04/28(水) 09:30:25
世界初の実用に耐える関数型言語
F#
343デフォルトの名無しさん:2010/04/28(水) 09:57:26
.NETベース大勝利
式ベースとは一体なんだったのか
344デフォルトの名無しさん:2010/04/28(水) 13:06:46
おまえらが欲しがっているものがすべて D にあってわろたwww
345デフォルトの名無しさん:2010/04/28(水) 13:09:00
>>344
無いよ
346デフォルトの名無しさん:2010/04/28(水) 14:14:03
ツンデレすぎてわろたwww
347デフォルトの名無しさん:2010/04/28(水) 14:18:47
>>344
んじゃ、俺らが欲しい機能とDの具体的な機能名を対照表で書いてください
348デフォルトの名無しさん:2010/04/28(水) 16:45:16
>>341
recursiveループがあるような言語をみてみたいよ
349デフォルトの名無しさん:2010/04/28(水) 19:13:54
>>347
まずお前らが欲しい機能って何?簡潔に纏めろ
350デフォルトの名無しさん:2010/04/28(水) 19:39:55
>>349
え?そっちはとっくに把握してるのだと思っていました。
だって俺らが欲しがってる機能が全部Dにあると>>344で書いてあったから・・・
351デフォルトの名無しさん:2010/04/28(水) 19:55:31
機能はあるんだよ
機能は
あとは仕様とコンパイラが安定してくれれば・・・
352デフォルトの名無しさん:2010/04/29(木) 00:31:57
オレは自称CPU固有言語クンではないぞ。
ま、固有がいやだっていうならば、CPU定義さえあれば、うまくいくぜ。
GCCだぜ、COINSだぜ、LLVMだぜーって感じになるでしょうね。
でも、出来るならLLVMとかと同じことをやりたい人もいるのかなと、
思うので、x86で構造作ってしまえたらいいな思ってるんです。
LLVMがいいんなら、そうするけど、それだと、
最適化とか作る楽しみがなくなったりしないのかな?と
わからんけど。

353デフォルトの名無しさん:2010/04/29(木) 00:34:01
中田先生の最適化の本とか読んでます。
そこにも下降型の演算子順位法が結構古くから使われているってなことが書いてあったと思うし、
論文も読んでないけど出してたように思います。
ドラゴンブックも目は通したよ。
ボトムアップ型のパーサのLRLAとかなると正直分からない。
最適化はこういうものがあるんだ。ふーんってレベルならわかってるつもりだけど、
実装してみたりはしてないので怪しいもんです。

http://www.hpcs.cs.tsukuba.ac.jp/~msato/lecture-note/comp-lecture/note10.html
このページ見てコンパイラも作ってみました。わかりやすかった。

美しい日本のコンパイラのソースは綺麗だし、インライン展開やら、SSA的なこともやってて面白いし
関数型言語系統のα変換とかβ変換とかいう用語が出て来てためになります。
型推論も結局Unifyするってことなんだなぁと。
CoinsのCPU固有の定義のところだけ取り出したいんだけどうまくいってません。

WirthとかAhoは知りません。
ググレばわかるんだろうけど。
Ahoがドラゴンブックの人で、Wirthはパスカルの人か。ふむふむ。
PaskalはLL(1)という点ですばらしいですよね。
でも、Paskalは構造化されたマクロはつかえないでしょ。
ドラゴンブックにLispのコンパイルの話はないだろうし。
基本がBNFになってるから、Lispのマクロは無理。AlgolにLispのマクロは無理。
っていうことになってしまう。
354デフォルトの名無しさん:2010/04/29(木) 00:35:14
実際はそんなことなくて、正規木文法は文脈自由文法のサブセットなので、正規木文法で表される
文法は文脈自由文法として扱うことが可能ですから、普通に文脈自由文法として扱えば
いいのは分かってますよ。
ただ、そうじゃないもっと綺麗にできないかなぁってなるとドラゴンブックレベルじゃ無理。

Cは文法の拡張しまくってるってほどでもないのでは?
RubyとかPerlに比べたらそれほど機能ないでしょ。
class、アクセス、ネームスペース、try & catchとsynchronized,テンプレート、pragmaくらいじゃないの?
foreachとか、javascriptだとwithとか、正規表現リテラルとかか。
その辺の拡張する文だって大体似たような形をしてるのでそのへんを表すことが可能な演算子を用意すればいいだけです。
それがいいか悪いかは2通りの見方があるので、好きなほうを選択すればいいのではないかと思います。

Cのどこがっていうのは、HTMLの文法のどこが複雑なんだろうっていうのと同じだってば。
Cと、C++のパーサを空で2日くらいで書けるか?と。オレは無理。
でも、演算子順位法使って、特殊な演算子を定義すれば、
演算子順位の調整を除けば書ける。

.NETベース大勝利とかわけわからん。戦っている層が違うだろ。
.netベースでどうやって高級アセンブラを作るんだ?
Nemerleとか知らんで書いてるだろ。
F#はML系だから、C系統の言語から移行するのはいろんな意味で辛いぞ。
だったら、Scalaのほうがずっといいと思う。
MLの仕事がいかんというわけではなくて、F#を周りのプログラマが理解して
お客がそれを納得してくれるならいいけど、それは現状は難しいかなぁっと。
長文すんませーん。(w
355デフォルトの名無しさん:2010/04/29(木) 01:45:13
・論点を絞る
・論旨を明確にする
・適度に箇条書きを利用する
・一般的ではない用語を使用するときは予め説明する
・論旨に影響の少ない固有名詞を無意味に使わない
・接続詞を使う
356デフォルトの名無しさん:2010/04/29(木) 02:02:03
長文すぎてウザがられてることに気付かないんだろうな
プログラム言語の前に日本語勉強しろっていう
357デフォルトの名無しさん:2010/04/29(木) 02:04:45
説得力無いって自分でも分かってるから長文になるんでしょ。読まないよそんなの
358デフォルトの名無しさん:2010/04/29(木) 03:18:09
まあツッコミ所は多々あるけど
意気込みはわかった
Cのパーザは手書きすると意外にめんどいよな
取り合えず言語仕様考えてbisonとか
javaccみたいなんで遊んでみたら?
俺言語をcにトランスレートでもいいかも
359デフォルトの名無しさん:2010/04/29(木) 05:34:32
>>355
ありがとうございます。なるほど。参考になります。
>>356
うざかったですか。すいません。国語苦手なんですよね。

>>357
説得力ないですか。
まずは355の実践からなのでしょうけど。
>>358
ではCへのトランスレータを書いてみます。

いろいろとご意見、ありがとうございます。
360デフォルトの名無しさん:2010/04/29(木) 14:19:45
function CExp(l,op,r){this.l=l;this.op=op;this.r=r}
CExp.prototype.toString = function() {return "["+this.l+",\""+this.op+"\","+this.r+"]"}
// 戦闘力表
CExp.lpowers={".":200,"->":200,"*":190,"/":190,"%":190,
"+":180,"-":180,"<<":170,">>":170,"<":160,"<=":160,">":160,">=":160,
"==":150,"!=":150,"&":140,"^":130,"|":120,"&&":110,"||":100,",":80}
// 読み込み処理
CExp.read = function(str) {
var arr = str.split(/[\b\s]+/) // 文字列を配列にする
function battle(power) {
var result = arr.shift()
while (CExp.lpowers[arr[0]] > power) {// 演算子の力が強ければ結合
var operator = arr.shift() // 名前取出し
var nextresult = battle(CExp.lpowers[operator]) // 次の戦いを行う
result = new CExp(result, operator, nextresult) // 式作成
}
return result
}
return battle(0)// 力0で戦闘開始
}
alert(CExp.to_c(CExp.read("a == b | c >> 2 > 5 , b , c >> 2")))// 読み込み
</script>
結果<br/><textarea>
((((a==b)|((c>>2)>5)),b),(c>>2))
</textarea>
361デフォルトの名無しさん:2010/04/29(木) 14:22:06
とりあえず、中置演算子のトランスレータを作りました。
ここでバリデータを作ってみます。


362デフォルトの名無しさん:2010/04/29(木) 14:27:25
コードもいいけど、先ずはその部分のBNFが欲しいな。
363デフォルトの名無しさん:2010/04/29(木) 14:36:24
自分で作れよ
364デフォルトの名無しさん:2010/04/29(木) 14:47:54
>>363
だから、>>360のコードで行う処理のBNFを>>360自身に作ってほしいと言ってるんだろ。
365デフォルトの名無しさん:2010/04/29(木) 14:52:52
なんだよコードで行う処理のBNFってw
366デフォルトの名無しさん:2010/04/29(木) 14:54:29
「中置演算子のトランスレータ」として、どういう入力を受理するかを定義するBNF
367デフォルトの名無しさん:2010/04/29(木) 15:03:59
言いたかっただけちゃうんかとw
368デフォルトの名無しさん:2010/04/29(木) 15:09:10
普通、BNFは最初に書くんじゃないの
369デフォルトの名無しさん:2010/04/29(木) 15:09:13
まあ、そうかもしれないけど、せっかくコード貼るなら、貼った意図を皆で理解できた方がいろいろ議論しやすいでしょ。

コードだけよりBNFがあった方がその意図を理解しやすいから。
370デフォルトの名無しさん:2010/04/29(木) 15:11:39
>>368
何も考えず適当にコーディングしちゃったんだろうな
371デフォルトの名無しさん:2010/04/29(木) 15:14:44
このスレ的には、文法よりコードが先行しても構わないよ。面白いアイデアなら
372デフォルトの名無しさん:2010/04/29(木) 15:17:17
こういうコーディングができればいいなぁ、というアイデアを仮想の言語で書いてみるって言うのもありだけどね。
ブレインストーミングの時には。
373デフォルトの名無しさん:2010/04/29(木) 15:18:46
>>371
面白いかどうかを判断するためにも、コードだけではなく、何をするのか説明されていた方がいい。
その説明する手段の一つがBNF。

コードだけでは分かりにくい。(バグっているかもしれないし。)
374デフォルトの名無しさん:2010/04/29(木) 15:20:31
>>372
そうそう。
実現したいコードの例を書くのはいいけど、
それを実現するための既存言語(あるいは疑似言語)によるパーサーのコードを書いても意味無いだろってことだよな。
375デフォルトの名無しさん:2010/04/29(木) 15:22:27
既存言語のBNFと変わらないように見えるのに要求する意味がワカンネ
376デフォルトの名無しさん:2010/04/29(木) 15:27:04
既存言語もたくさんあるし、>>360の意図が実際にそうであるのかを確認するためにもBNFは有った方が分かりやすいよ。
単にコードを貼りたいだけで、それ以上議論したくないなら、BNFも説明もなくてもいいけど。
377デフォルトの名無しさん:2010/04/29(木) 15:30:28
確認とか分かり易いとか、なんなんだよ。コードを見て おっ? と思うならBNFを見たくもなるけど
明らかにC系だしBNFに拘っても仕方ないだろ。>>360は単にコードを貼りたいだけだろ
お前はどこに説明を欲しいわけ?
378デフォルトの名無しさん:2010/04/29(木) 15:31:09
単なるオナニーコーディングだし。出して気持ち良ければそれで満足。それ以上何かしたいわけじゃないんだろ。
379デフォルトの名無しさん:2010/04/29(木) 15:31:54
>>360に何か可能性でも見出したのかなw
380デフォルトの名無しさん:2010/04/29(木) 15:32:26
じゃあいいや。
>>360は見る価値の無いどうでもいいコードってことだな。
381デフォルトの名無しさん:2010/04/29(木) 15:33:38
>>380
なにヤケになってんだよw
お前が食いついてただけだろ。むしろ食い付いた理由を知りたいわ
382デフォルトの名無しさん:2010/04/29(木) 15:35:20
>「中置演算子のトランスレータ」として、どういう入力を受理するかを定義するBNF

結局、コレ言いたいだけちゃうんかと!最近BNF勉強しただけちゃうんかと!
383デフォルトの名無しさん:2010/04/29(木) 15:40:33
「だけちゃうんかと」と言いたいだけだということはわかった。
384デフォルトの名無しさん:2010/04/29(木) 15:41:34
>>381
「コード貼るなら、説明しろ」というのが真意
385デフォルトの名無しさん:2010/04/29(木) 15:51:45
>>382
誰もそんなこと言ってないのにそう思うってことは、あなたに当てはまることだから?
386デフォルトの名無しさん:2010/04/29(木) 15:53:07
BNFに固執してるから
387デフォルトの名無しさん:2010/04/29(木) 15:55:16
BNFを書かないとyaccれないじゃん
388デフォルトの名無しさん:2010/04/29(木) 15:56:32
いつその段階まで話が進んだんだよ。このスレにはまだ具体性の一つもねえよ
389デフォルトの名無しさん:2010/04/29(木) 16:59:10
if then else節をどうにかしてほしいね
シーケンス上で分岐条件が整ったら即分岐を推奨
template機能でも駆使して成否混在したコードを一括記述できるとか
390デフォルトの名無しさん:2010/04/29(木) 17:34:01
always @(posedge event)
begin
 some_action();
end
391デフォルトの名無しさん:2010/04/29(木) 17:39:45
>>386
BNFは説明の手段の一つ。
BNFに固執しているというよりは、BNFでも何でもいいから説明があった方がいいと言っている。

せっかくコードを書いたなら、その意図を読み手に誤解なく受け取ってもらった方が、書いた方も読む方も幸せでしょ?
コードを貼りたいだけなら別にそれ以上何も望まないけど。
392デフォルトの名無しさん:2010/04/29(木) 17:47:10
だからコードを貼りたいだけってことだよ言わせんな恥ずかしい

説明が欲しいなら該当箇所を質問しろよ
393デフォルトの名無しさん:2010/04/29(木) 17:50:56
>>392
だから、「CExpのパラメータの意味を教えてください」って質問だろ。
で、結局、その回答はBNFで書くのが一番楽だろう。
394デフォルトの名無しさん:2010/04/29(木) 17:53:42
>>392
コードを貼りたいだけなら別に質問はないわ。コード自体に興味はないし。
395デフォルトの名無しさん:2010/04/29(木) 17:55:06
BNFには興味があるのかw
396デフォルトの名無しさん:2010/04/29(木) 17:57:19
>>395
コードが実現する機能には興味があった。
機能を説明することもできない貼りたいだけの捨てコードなら別にもうどうでもいいけど。
397デフォルトの名無しさん:2010/04/29(木) 18:00:44
矛盾してるよ
398デフォルトの名無しさん:2010/04/29(木) 18:03:21
>>390
こういう非同期をキャッチする仕組みいいね。
399デフォルトの名無しさん:2010/04/29(木) 18:10:46
verilogもC以上に糞構文だけどな。

並列の記述には優れているよね。
400デフォルトの名無しさん:2010/04/29(木) 18:20:53
つか、ハードウエアは基本並列だからなw
401デフォルトの名無しさん:2010/04/29(木) 18:22:44
論理合成のためだけではなく、ソフトウェアの並列記述にも役に立つってこと。
402デフォルトの名無しさん:2010/04/29(木) 18:24:49
CPUは原理的にはシリアルだよ?
403デフォルトの名無しさん:2010/04/29(木) 18:30:33
だから機械語直接記述は最小限にしたい
404デフォルトの名無しさん:2010/04/29(木) 20:04:07
>>402
直列に連なったステージが並列に動作するのがパイプライン
405デフォルトの名無しさん:2010/04/29(木) 20:13:00
並列というならパイプラインよりスーパースケーラだな
>>402
当たり前だがチューリングマシンは基本直列だからねえ

つか、並列動作はやっぱ人間にとってわかりにくいから難しい
406デフォルトの名無しさん:2010/04/29(木) 20:29:38
アセンブラ使わなくてパイプライン充填率高められる言語作ってくれよ
そしたら使ってやるよ
407デフォルトの名無しさん:2010/04/29(木) 20:52:15
>>406
それは言語仕様じゃなくてコンパイラの範疇では
408デフォルトの名無しさん:2010/04/29(木) 20:55:28
コンパイラじゃ限界あるだろ
409デフォルトの名無しさん:2010/04/29(木) 21:39:56
それならそれが限界ということ。
CPUアーキテクチャを有効に活かすのはコンパイラの仕事。それを最もうまく行うのがコンパイラ。
410デフォルトの名無しさん:2010/04/29(木) 21:48:34
それならアーキテクチャを変更すれば良いということ。
411デフォルトの名無しさん:2010/04/29(木) 21:51:18
つまり、パンがないならお菓子を食べればいいじゃない。ということだな。
412デフォルトの名無しさん:2010/04/29(木) 22:02:56
>>406
初代Pentiumのころはコンパイラがそれをやってたけど、今はCPUがそれやってくれるんだよね。
413デフォルトの名無しさん:2010/04/29(木) 22:04:34
つまりマリー・アントワネット的転回ということだな
414デフォルトの名無しさん:2010/04/29(木) 22:46:54
あとキャッシュ効率を自動で高められる言語がいいな
ブロッキングとかメンドイのなくしたい
415デフォルトの名無しさん:2010/04/29(木) 22:48:45
>>414
JAVAのGCがそれをやってくれるってふれこみだったけど・・・・
416デフォルトの名無しさん:2010/04/29(木) 22:55:05
Dにはあるが、ただのaliasではないtrue typedefが欲しい
Cだとdata abstructionの目的でopaque pointerを用いることは
よくあるが、true typedefがあれば、それを型安全に出来る
417デフォルトの名無しさん:2010/04/29(木) 22:59:59
DからGCを省いたD♭を作って欲しいな。
418デフォルトの名無しさん:2010/04/29(木) 23:02:47
data abstractionだな
Cなんて使ってると、どうもstructと書いてしまう
419デフォルトの名無しさん:2010/04/29(木) 23:10:38
>>412
cpuはそんなことしてくんねーだろ
420デフォルトの名無しさん:2010/04/29(木) 23:11:53
true typedefって何?
421デフォルトの名無しさん:2010/04/29(木) 23:12:51
投機実行はやるけどちょっと違うな
422デフォルトの名無しさん:2010/04/29(木) 23:13:45
>>419
最近のインテルプロセッサならx86をデコードしてuopsを実行するときにやってくれるよ。
423デフォルトの名無しさん:2010/04/29(木) 23:15:13
パイプラインがわかってないんだろ
simdとかやってりゃ分かってくると思うんだが

いかにRSとかROBに処理をためないで計算実行するかをね
424デフォルトの名無しさん:2010/04/29(木) 23:16:08
>>422
それじゃ依存チェンの解決されんだろが
425デフォルトの名無しさん:2010/04/29(木) 23:16:55
>>423
何の話?
426デフォルトの名無しさん:2010/04/29(木) 23:17:20
>>422
インテルのCPUは下品だからな

今でもパイプライン埋めるなんて静的な最適化は事前にやるのが効率いい
427デフォルトの名無しさん:2010/04/29(木) 23:18:23
>>424
依存チェンって何?
428デフォルトの名無しさん:2010/04/29(木) 23:19:29
>>427
ちょっと打鍵ミスったけど知らないなら教えてあげない
団子にでも聞け
429デフォルトの名無しさん:2010/04/29(木) 23:20:56
>>428
じゃあ別にいいわ。
>>424はバグ入りの無意味な文章ってことね。
430デフォルトの名無しさん:2010/04/29(木) 23:21:28
いやパイプライン充填率を高める超重要なこと
431デフォルトの名無しさん:2010/04/29(木) 23:22:19
424を理解できないと高速プログラミングは実質不可だよ
432デフォルトの名無しさん:2010/04/29(木) 23:23:31
誤字なら訂正すればいいのに。何意地になってるんだろうね。
433デフォルトの名無しさん:2010/04/29(木) 23:23:39
ま、超高速をうたったスレなんで書いたけど
超高速が不要なら無視してもいいよ
434デフォルトの名無しさん:2010/04/29(木) 23:24:21
煽るだけで中身がないのが2ちゃん
435デフォルトの名無しさん:2010/04/29(木) 23:27:20
これ隅々まで読めばわかるよ
http://download.intel.com/jp/developer/jpdoc/248966-017JA.pdf
436デフォルトの名無しさん:2010/04/29(木) 23:27:33
それでもたまに煽りの中に発見があったりするからね。それを拾っていこう。
437デフォルトの名無しさん:2010/04/29(木) 23:33:03
ひまなんだなw
438デフォルトの名無しさん:2010/04/29(木) 23:34:55
フルの仕様ではGC(かそれに相当する機能)が有りだけど、GCを使わないようにも出来て
GCを使わない場合でもGCがある場合とそれほど違和感ないようにできないだろうか。
439デフォルトの名無しさん:2010/04/29(木) 23:39:10
C++でnewオーバーロードでGCライブラリ呼び出しにすればいいだけじゃないか?
deleteのあつかいは難しいが単純にメモリ解放だけしないということで
440デフォルトの名無しさん:2010/04/29(木) 23:42:07
普段はGCを使っているプログラマが、GCなし環境で開発をしなければならなくなったときに、勘違いして致命的なバグを作りこまないようにしたい。
バグがあってもそれをコンパイラで検出できればいい。

newでGCするようにしてそれを達成できるかな。
441デフォルトの名無しさん:2010/04/29(木) 23:46:03
いろいろやりようはあるよ。
でも実行時検知だけじゃなくコンパイラでって話ならかなり厳しい。
かなり文法や構文にルール導入すればできるだろうけど
442デフォルトの名無しさん:2010/04/30(金) 00:20:36
C++/CLIのgcnewは、>>438で有用だから採用したい。
443デフォルトの名無しさん:2010/04/30(金) 00:23:57
gcnewとnewを使い分けるのが美しくないよね。でも仕方無いか。
444デフォルトの名無しさん:2010/04/30(金) 00:42:23
>>443
newとgcnewのポインタ間に代入互換性が無いんだぜ。仕方ないで済ませられないほど困る。
445デフォルトの名無しさん:2010/04/30(金) 02:06:38
GCとか普通にいらんだろ
446デフォルトの名無しさん:2010/04/30(金) 02:10:26
このスレで話題にしたいような低レベル言語にはいらんな
中〜高レベルには必須だな
447デフォルトの名無しさん:2010/04/30(金) 05:59:45
そろそろ己の馬鹿自慢合戦は止めようぜ
折角GWに入ったんだから有意義に行こう
448デフォルトの名無しさん:2010/04/30(金) 07:46:41
Garbage Week
449デフォルトの名無しさん:2010/04/30(金) 12:42:21
GC が要らないレベルなら C/C++ で十分だな。
450デフォルトの名無しさん:2010/04/30(金) 16:32:34
GC有り言語とGC無し言語ではメモリに関する考え方がまるで違うから、
学習者からすれば一つの言語に混在するのは良くないんじゃないかな。

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

良い言語の条件は、
・読みやすい・メンテしやすいこと(他人の書いたperlコードなんて読みたくない)
・ライブラリが充実してること(画像読み取りぐらいは標準ライブラリに欲しい)
・熟練者じゃなくてもミスのないプログラムが書けること
なんじゃないかなと思う。
451デフォルトの名無しさん:2010/04/30(金) 16:36:26
見た目は何もかわらないんだけど、
宣言の時に処理を埋め込むことができるような指示子を持つ言語にすればGC言語にも変身できるんじゃないの?
452デフォルトの名無しさん:2010/04/30(金) 16:45:00
>>451
Managed C++ とか?
453デフォルトの名無しさん:2010/04/30(金) 17:15:12
このスレ、全般的に超高速にあまり触れていないのは何故?
分かる人いないの?
454デフォルトの名無しさん:2010/04/30(金) 17:34:59
高速を要求される言語にGCは向かないとは思うよ。

あと、変数には型がある方がいいな。z=x+yと書かれても、
実行時までx,yがintかdoubleか文字列かわからない言語は高速にはならんだろ。
455デフォルトの名無しさん:2010/04/30(金) 18:27:23
Part1の>>1の書き込みからするに、C並みに速い程度で十分だと思われ。
スレタイに囚われて、Cより速い言語とか考えるから、CPU固有言語君とか出てくる。
456デフォルトの名無しさん:2010/04/30(金) 20:46:54
◆新言語の位置づけ◆

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

そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
457デフォルトの名無しさん:2010/04/30(金) 20:53:09
>>456
Cのどこが悪いかを述べよ
458デフォルトの名無しさん:2010/04/30(金) 20:55:13
>>457
デストラクタが無い。
459デフォルトの名無しさん:2010/04/30(金) 21:41:09
>>458
クラスとヒープがないと意味ないだろ。
460デフォルトの名無しさん:2010/04/30(金) 22:09:21
>>459
じゃあ、それも
461デフォルトの名無しさん:2010/04/30(金) 22:12:56
>>460
初期のC++じゃない
462デフォルトの名無しさん:2010/04/30(金) 22:18:11
>>459
そんなことはない。
自動変数の寿命が尽きる時に呼び出されるだけでも意味がある。
463デフォルトの名無しさん:2010/04/30(金) 22:21:57
>>462
ヒープに確保した場合は呼ばれないのか。
それに意味があるとは思えないな。
464デフォルトの名無しさん:2010/04/30(金) 22:34:34
Cの場合、
ヒープならmalloc-freeの組が必ずあるからfreeをフックすれば、後始末ができるが
スタックはそれができない。

スタックの後始末をするためにデストラクタに相当する機能が欲しい。
465デフォルトの名無しさん:2010/04/30(金) 22:36:12
ヒープ使うのに抵抗ないならスタック使わなければ問題ない
466デフォルトの名無しさん:2010/04/30(金) 22:38:04
Java系はそもそもスタックにインスタンスを生成できないな
467デフォルトの名無しさん:2010/04/30(金) 22:38:07
ヒープ使うのに抵抗がある。
468デフォルトの名無しさん:2010/04/30(金) 22:39:10
スタックサイズも意識してね
469デフォルトの名無しさん:2010/04/30(金) 22:39:53
そうだね。
ということで、デストラクタは必要。
470デフォルトの名無しさん:2010/04/30(金) 22:41:23
いらねーよ。スタックでしか自動化のメリットない。
ヒープは自前で呼び出す必要性がある。対象性なさ杉。
471デフォルトの名無しさん:2010/04/30(金) 22:42:16
>>464
ヒープとスタックで別の動作をするものが役に立つとは思えないし、分かりにくくなるだけだと思うが、実装は簡単だな。
472デフォルトの名無しさん:2010/04/30(金) 22:54:32
>>456
D
473デフォルトの名無しさん:2010/04/30(金) 22:55:59
>>471
同じ動作でいいじゃん
474デフォルトの名無しさん:2010/04/30(金) 22:57:55
こいつ自分の言ってる事がわかってない
475デフォルトの名無しさん:2010/04/30(金) 22:59:38
オブジェクトの破壊ではなくスコープの変化をフックすると考えればいい
無限エクステントを実装するのに使えそうだし
476デフォルトの名無しさん:2010/04/30(金) 23:02:24
C++と同じように、寿命が尽きた時に呼び出される関数が欲しいって言ってるだけでしょ
ヒープとスタックで別の動作とか、そんな話どこから出てきたんだか
477デフォルトの名無しさん:2010/04/30(金) 23:04:58
こいつ自分の言ってる事がわかってない
478デフォルトの名無しさん:2010/04/30(金) 23:11:55
Javaには君が望むようなデストラクタはないな
479デフォルトの名無しさん:2010/04/30(金) 23:14:04
Javaは目指さなくていい
480デフォルトの名無しさん:2010/04/30(金) 23:14:34
ようは理解できないと
481デフォルトの名無しさん:2010/04/30(金) 23:15:24
C#のusingは有用だから採用したい。
482デフォルトの名無しさん:2010/04/30(金) 23:16:25
Cにお前らの望むもの追加したら、C++になったでござる
483デフォルトの名無しさん:2010/04/30(金) 23:17:09
C++の機能を今風の構文で実現できるならそれでもいいけどな
484デフォルトの名無しさん:2010/04/30(金) 23:18:10
>>481
それを実現したいなら、先に例外だな。
485デフォルトの名無しさん:2010/04/30(金) 23:19:21
例外はもう少しエレガントにならんのかな
try-catchはカッコ悪い
486デフォルトの名無しさん:2010/04/30(金) 23:21:57
次ぎに何時規制になるか、分からないので書きたいことを書いておく。
1、言語の設計とコンパイラの設計は違うぞ。
2、BNF出して議論するのは良いと思うけど、もう少し煮詰まってからだと思う。
3、デストラクタの議論は何かよく分からん。後、スタックというのは、C言語で
  採用されたメモリーの使用方法で、コボルにはスタックという概念が無かったし。
  非スタックというアプローチが有効だとは思わないが、それも一考の価値は
  有ると思う
4、C言語の悪いところは、プリプロセッサとか色々。
487デフォルトの名無しさん:2010/04/30(金) 23:23:21
以下、構文の美しさの議論から始まって、Lisp厨やらJava厨やらLL厨やら割り込んで
最後にはCPU固有言語君が湧いてくるいつもの無限ループが始まります。

488デフォルトの名無しさん:2010/04/30(金) 23:28:43
Cがスタックを採用したのは確かにその通りだが、Cが存在する以前からスタックはあったし
PUSH,POPはCPUの基本的な命令だから、スタックはサポートしたいだろう。
489デフォルトの名無しさん:2010/04/30(金) 23:30:01
>>484
例外って、sjljの敷居を下げてモラルハザードを起こすだけの存在だよね
490デフォルトの名無しさん:2010/04/30(金) 23:30:47
sjljって何?
491デフォルトの名無しさん:2010/04/30(金) 23:34:45
>>482
まぁ、結局のところそうなんだけど、C++は少し読みにくいので、
機能的にはC++から多重継承やフレンドを取り除いて、C++で出来る事は
全部出来るけど、読みやすく、書きやすく、
その上システムレベルのプログラミングもやりやすい、
ってのがお年頃だと思う。

そうそうそう言えば、
二進数 0b00001111
八進数 Oc0017
10進数 0d15
16進数 0xF

または

二進数 Bi00000001111
八進数 Oc017
10進数 De015
16進数 Hx0F
492デフォルトの名無しさん:2010/04/30(金) 23:41:28
任意のN進数の整数リテラルがあってもいいかな。
493デフォルトの名無しさん:2010/04/30(金) 23:47:06
>>486
> 1、言語の設計とコンパイラの設計は違うぞ。

確かに。
このスレッドは前者、「言語の設計」をするスレッドである、ということを明確にしておきたいね。
494デフォルトの名無しさん:2010/04/30(金) 23:47:58
>>490
setjmp-longjmp 綴りあってたっけ?
495デフォルトの名無しさん:2010/04/30(金) 23:49:17
>>494
おお、それをそう略すのか。初めて知った。thx
496デフォルトの名無しさん:2010/04/30(金) 23:52:30
C と C++ の差は絶妙なバランスをとっているよ。
497デフォルトの名無しさん:2010/05/01(土) 00:01:28
素人が紛れててお話にならないな。
498デフォルトの名無しさん:2010/05/01(土) 00:01:58
交通整理も出来ないくせに
499デフォルトの名無しさん:2010/05/01(土) 00:11:48
勇気を出して仲間に入れてって言えばいいのに^^

教室の後ろでブツブツ言ってても気持ち悪がられるだけだよ^^
500デフォルトの名無しさん:2010/05/01(土) 00:13:25
>>496
C++は汚くなりすぎた。
501デフォルトの名無しさん:2010/05/01(土) 00:18:16
0xにはワクワクしないでもないけど、過去のしがらみがちょっとね。
502デフォルトの名無しさん:2010/05/01(土) 01:34:39
デストラクタみたいな勝手に走る奴は低レベルにはそぐわんでしょ
後x86しかしらんやつは今の主流のRISCをちょい勉強したらどうだろ
今でも引数や戻り番地をスタックに積むしかないと思ってそうだ
けど、スタックはメモリの局所性が高くてキャッシュとの相性が抜群だからいいんよ
503デフォルトの名無しさん:2010/05/01(土) 01:38:41
話少し変わるけども、C++で継承元クラスのデストラクタは
仮想関数にしなさいってのは、どうかと思うんだけど、あれって
コンパイラが自動的に出来ない物なのか?

常に仮想関数を定義しなきゃ駄目なら、コンパイラがそう解釈すれば
良いのに、何故にあんな仕様になってるのか、理解できないんだけど、
何が理由で、あれはあんな風になってるんだ?

暗黙のコピーコンストラクタとか、色々、やらなくても良いことまで
やってる癖に、なぜデストラクタという一番厄介な部分で、常に手書き
せよと言う、変な仕様になってるのか理解できないんだが。
504デフォルトの名無しさん:2010/05/01(土) 01:41:44
>>502
スタックを模したレジスタ
505デフォルトの名無しさん:2010/05/01(土) 01:43:37
>>503
ゼロオーバーヘッド原則
意訳「勝手にやるんじゃねえ糞野郎」
506デフォルトの名無しさん:2010/05/01(土) 01:50:39
>>505
その割に、暗黙の型変換とかね、CとC++はそう言うのが悪いと思う。
そもそも、継承したクラスか、継承元なのかは、静的に解析出来るわけだし、
アップキャストしても、それは同じように分かるはず、というか分かるから、
仮想関数にしておけば、デストラクタが呼び出されるわけだし。

なんかそう言ういい加減さが、C++の欠点なんだと思うんだ。
継承したクラスで、デストラクタが呼び出されなくて嬉しい、という
場合は無いでしょ、あっちゃならねーよ。なんのための継承か
わからねーよ。

と言うことで、新言語ではデストラクタがちゃんと呼ばれることにしよう。
507デフォルトの名無しさん:2010/05/01(土) 01:51:20
V-Tableくらいデフォルトにすればいいのにな。
使いたくない時だけno-virtual指定するとか。
508デフォルトの名無しさん:2010/05/01(土) 01:52:44
>>506
仮想関数は重い。C++はそのコストを無視できないんだよ。
509デフォルトの名無しさん:2010/05/01(土) 01:53:49
言わせてもらうとC++はいらね
あの仕様見てたらオブジェクト指向は低級言語に合わねえってのの
実証実験じゃねえのかと思うよ
510デフォルトの名無しさん:2010/05/01(土) 01:55:07
仮想デストラクタを持った基底クラスを作っておいて、それをはせいさせれば良いんじゃね?
511デフォルトの名無しさん:2010/05/01(土) 01:55:36
C++がいらないのは確かだが、オブジェクト指向は低級言語に合わないわけではない。
512デフォルトの名無しさん:2010/05/01(土) 01:56:06
>>509
別にあんたのために作ったんじゃないんだからねっ
513デフォルトの名無しさん:2010/05/01(土) 02:03:16
素直にJava使ってろ
514デフォルトの名無しさん:2010/05/01(土) 02:03:56
>>508
いやいや、意味が分からね。静的に解析出来るじゃん。
基底クラスは自分のデストラクタ使えば良いし、派生クラスは自分と
基底クラスのデストラクタ双方が必要ってのは絶対なんだから。

基底クラスが派生クラスのデストラクタを必要とすること無いんだし。
515デフォルトの名無しさん:2010/05/01(土) 02:06:31
素直にJava使ってろ
516デフォルトの名無しさん:2010/05/01(土) 02:07:21
最低2回は繰り返す
517デフォルトの名無しさん:2010/05/01(土) 02:24:00
>>514
静的に解析って……アホか
基底へのポインタが、基底型オブジェクトを指してるのか派生型オブジェクトを
指しているかは実行時の問題であって、静的に解析できんだろが
だからvtblとか使ってポリモーフィズムさせてるんだぞC++は

基底へのポインタをdeleteしたときに、それが指している実行時型に応じた
デストラクタが起動されるためには、デストラクタが仮想関数でなければならない
そして常にデストラクタを仮想にしないのは、zero overhead principleのため
それがC++の流儀だ
518デフォルトの名無しさん:2010/05/01(土) 03:24:51
>>517
言ってることがよく分からない。
継承されるかどうか分からないから、ヴァーチャル付けとけで、
zero overhead principleが守られてるのか?
519デフォルトの名無しさん:2010/05/01(土) 03:28:02
当初の設計思想と、その後実際使った経験則に則ったEffective C++的な作法との間で整合が取れなくなっているんだよな。

だから、ダメなんだよC++は。
520CPU固有言語君:2010/05/01(土) 04:54:51
笑えるので名前にしてみた。
うおー!
とりあえず、Cの文法読んでるぞ。ウォー!ワー!
http://www.quut.com/c/ANSI-C-grammar-y.html
521CPU固有言語君:2010/05/01(土) 05:12:15
なんか、勝手にオレの分身がむかつき度をアップしている。
おかげさまで、BNFと同等のものが必要ということが分かりました。
ホント、馬鹿でした。(汗
522CPU固有言語君:2010/05/01(土) 05:34:32
360のコードのBNFは演算子はあとからも登録できるので、こんな感じですか
C式0 : C式1 ( 演算子1 C式1 )+
C式1 : C式2 ( 演算子2 C式2 )+
C式2 : C式3 ( 演算子3 C式3 )+
C式3 : C式4 ( 演算子4 C式4 )+
C式4 : C式5 ( 演算子5 C式5 )+
C式5 : C式6 ( 演算子6 C式6 )+
:
:
C式∞: 字句
523デフォルトの名無しさん:2010/05/01(土) 05:35:51
+じゃなくて、*だろ
524デフォルトの名無しさん:2010/05/01(土) 05:36:31
と、自作自演風訂正をしたけど、バレバレだな。
525デフォルトの名無しさん:2010/05/01(土) 11:54:54
>>522
それなら、こんな↓感じじゃない?

C式 : C式 ( 演算子 C式 )*
演算子 : <<ここが未定義>>
526デフォルトの名無しさん:2010/05/01(土) 12:44:17
>>522
525それだと演算子の優先順位がつかないので、
定義されている演算子も含めてこんな感じでしょうか?

C式 : C式∞
C式∞ : C式(∞-1) ( 演算子(∞-1) C式(∞-1) )*
:
:
C式1 : C式0 ( 演算子1 C式0 )*
C式0 : トークン ( 演算子0 トークン )*
トークン: [^\s]
演算子200: '.' | '->' | <<未定義>>
演算子190: '*' | '/' | '%'| <<未定義>>
演算子180: '+' | '-'| <<未定義>>
演算子170: '<<'| '>>'| <<未定義>>
演算子160: '<' | '<=' | '>' | '>='| <<未定義>>
演算子150: '=='| '!='| <<未定義>>
演算子140: '&'| <<未定義>>
演算子130: '^'| <<未定義>>
演算子120: '|'| <<未定義>>
演算子110: '&&'| <<未定義>>
演算子100: '||'| <<未定義>>
演算子80: ','| <<未定義>>
演算子n:<<未定義>>
527デフォルトの名無しさん:2010/05/01(土) 13:00:36
生成規則と優先順位の定義は分けた方がいいのでは。
528デフォルトの名無しさん:2010/05/01(土) 13:08:32
C式 : C式 ( 演算子 C式 )* | トークン ( 演算子 トークン )*
トークン: [^\s]
演算子: 演算子200 | 演算子190 | 演算子180 | 演算子170 | 演算子160 | 演算子150 | 演算子140 | 演算子130 | 演算子120 | 演算子110 | 演算子100 | 演算子80 | 演算子n
演算子200: '.' | '->' | <<未定義>>
演算子190: '*' | '/' | '%'| <<未定義>>
演算子180: '+' | '-'| <<未定義>>
演算子170: '<<'| '>>'| <<未定義>>
演算子160: '<' | '<=' | '>' | '>='| <<未定義>>
演算子150: '=='| '!='| <<未定義>>
演算子140: '&'| <<未定義>>
演算子130: '^'| <<未定義>>
演算子120: '|'| <<未定義>>
演算子110: '&&'| <<未定義>>
演算子100: '||'| <<未定義>>
演算子80: ','| <<未定義>>
演算子n:<<未定義>>
529デフォルトの名無しさん:2010/05/01(土) 13:10:02
>>527
こんなかんじ?
left: ',' | <<未定義>>
left: '||'| <<未定義>>
left: '&&'| <<未定義>>
left: '|'| <<未定義>>
left: '^'| <<未定義>>
left: '&'| <<未定義>>
left: '=='| '!='| <<未定義>>
left: '<' | '<=' | '>' | '>='| <<未定義>>
left: '<<'| '>>'| <<未定義>>
left: '+' | '-'| <<未定義>>
left: '*' | '/' | '%'| <<未定義>>
left: '.' | '->' | <<未定義>>
C式 : C式 ( 演算子 C式 )*
| トークン
演算子 : <<ここが未定義>>
530デフォルトの名無しさん:2010/05/01(土) 13:11:40
leftが多重定義に見えるけど。
531デフォルトの名無しさん:2010/05/01(土) 13:14:11
<<未定義>>はわざわざ書かなくてもいいんじゃないの。
532デフォルトの名無しさん:2010/05/01(土) 13:14:50
単項演算子と括弧がねえぞ
533デフォルトの名無しさん:2010/05/01(土) 13:16:35
>>532
欲しいなら自分で定義に追加すればいいよ。
534デフォルトの名無しさん:2010/05/01(土) 13:23:31
| '_>' |
535デフォルトの名無しさん:2010/05/01(土) 13:36:25
<<未定義>>ってなんだよ
536デフォルトの名無しさん:2010/05/01(土) 13:44:48
言語は後で設計するとして、先にコンパイラを設計しようってことだろ
537デフォルトの名無しさん:2010/05/01(土) 14:04:26
つかBNFのお勉強かよ
まじめにやるとCは結構でかいぞ
後書き方は::=か=が一般的かね。
式 = 項 { 演算子 項 }
みたいなかんじ。
PEGもいいぜ
538デフォルトの名無しさん:2010/05/01(土) 14:05:46
>>536
そうなんだが、BNF中に未定義とかあったらあかんだろw
空(ε)と未定義は違う
539デフォルトの名無しさん:2010/05/01(土) 15:06:59
構文の定義は当業者が理解できる範囲で合理的な記述であれば厳密である必要はないよ。
それこそBNFのお勉強じゃないんだからね。BNF自体方言があるわけだし。

未定義は好意的に受け取れば「みなさん追加してください」って意味なんだろうけど
わざわざ明記する必要はないね。
540デフォルトの名無しさん:2010/05/01(土) 18:21:18
BNFに方言があるのは確かだが
共通な話題にしたいなら
仕様書や教科書を読めとは言わんが
少し書き方を覚えても損はないよ。
区切り文字や左と右に何を書くのか、
繰り返しや選択は?位ね
俺には未定義とかleftとか意味わからんかった
541デフォルトの名無しさん:2010/05/01(土) 18:28:18
makefileも楽々記述できるようになるしな
542デフォルトの名無しさん:2010/05/01(土) 20:48:37
まだ構文以前の話だろ。
駆動とかルーチンとかの基本的な話をしようぜ。

構文にこだわるなら安全なマクロの仕組みとか。
マクロ自体をPEGとかBNFとかで組めるようにする手もあるけどな。
543デフォルトの名無しさん:2010/05/01(土) 21:09:39
駆動って何の駆動?
544デフォルトの名無しさん:2010/05/01(土) 21:13:03
コンパイラの勉強なら別スレがあるじゃん。
BNFとかだらだら書かれたら迷惑。
書いてるのC言語だし。
545デフォルトの名無しさん:2010/05/01(土) 21:16:21
欲しい構文があるならBNFで明快に書かれた方が議論しやすいだろ。
>>352-354みたいな文章をだらだら書かれたら困るw
546デフォルトの名無しさん:2010/05/01(土) 21:18:20
BNFで書くのはコンパイラのためじゃないよ。
共通言語として読み手が理解しやすいからだよ。
547デフォルトの名無しさん:2010/05/01(土) 21:22:13
このスレでアホアホフィルター掛けちゃったら


何も残らないじゃないか
548デフォルトの名無しさん:2010/05/01(土) 21:31:58
で、ネタふりなんだけど、
if文は、現状のままで良い?

if(条件){
}else{
}
と、中括弧を必須にするのはどう?

549デフォルトの名無しさん:2010/05/01(土) 21:34:33
>>546
そうだけどさ、BNFの勉強会始められたらビックリだよ。
コンパイラ関係のスレは沢山あるし、まだまだそこまで
議論煮詰まってる訳じゃないし、BNFで書きにくいから
なんて言うのは、今、考える事じゃないし。
550デフォルトの名無しさん:2010/05/01(土) 21:39:53
何でコンパイラ関連のスレが出てくるのかよくわからないけど、
別にBNFの意味を確認しあうぐらいはいいんじゃないの。言葉の認識を合わせるためなんだから。
そもそも勉強会なんて始めてないし。ビックリするなら始まってからビックリすればいい。別に大したビックリでもないし。
551デフォルトの名無しさん:2010/05/01(土) 21:50:05
>>550
BNF位、読めて書ける人が、気合い入れないで、
あの文法めんどくせーよ、よめねぇーよ、と
気楽に書いてるのがこのスレなんだよ。
だから、稚拙なBNF書いてUPされるとすげー
迷惑なんだよね。

例えて言うと、言語学者が「ら抜き言葉」は文法上の必然か
どうか議論してるところに、「ままぁ、ひらがなかけたよ」と
子供が練習帳持ってきて、ちゃんと書けてるか、みてみて
と言ってきてるような違和感があるんだよ。その違和感というか
迷惑に気がつけないで、BNFかいて何が悪いという、その感性に
ビックリなんだよ。
552デフォルトの名無しさん:2010/05/01(土) 21:55:15
俺はBNFの方が曖昧性の少ない議論をしやすいから好み。
お前は稚拙なBNFにビックリするから嫌い。

好みの問題は歩み寄るのは難しいから、まあ各人が好きなように書けばいいんじゃないの。
もっとも、個人的には「俺がビックリするから止めろ」という姿勢には賛同できないけどね。
553デフォルトの名無しさん:2010/05/01(土) 21:58:09
>>552
稚拙なBNFをUPするな、BNFの書き方すら怪しいレベルで
UPするなって事もちゃんと書いてるので、日本語すら怪しい
お前がどれだけ迷惑なのか・・・

でも>>552を平気で書いてるところを見ると、お前はそう言う人間
なんだろと思う。
554デフォルトの名無しさん:2010/05/01(土) 21:59:51
構文を、斬新なのでなく、ありふれたのにするなら、最後にしたらいいこと。
555デフォルトの名無しさん:2010/05/01(土) 22:00:46
>>554
同意
556デフォルトの名無しさん:2010/05/01(土) 23:18:38
新しい言語には、EVALUATE文が是非欲しいんだけど、
変わりにswitch文を削除しても良いよね。

http://www16.plala.or.jp/hiyokogumi/dic/a_evaluate.html
557デフォルトの名無しさん:2010/05/01(土) 23:19:43
>>553
すいません。オレがBNFをちゃんとかけなかったばっかりに、、、。
たしかに文法を書くならどの記法で書くと明記した上でその文法に則って書けば
突込みが入ることもないですよね。

そこで質問です。
<<未定義>>と書いたのは演算子を後から定義できることを表す為でした。
しかし実行時に文法が変わることを記述可能な文法の記法を私は知りません。
もしご存知でしたら文法が後で変わる記法を教えてください。
またご存知なければどのように書けば違和感がなく伝えることが出来るか教えてください。

>>532
前置演算子がないのは書いたプログラムに前置演算子がないからです。
558デフォルトの名無しさん:2010/05/01(土) 23:24:24
>>556
switchを無くしてEVALUATE文にする理由は?
559デフォルトの名無しさん:2010/05/01(土) 23:24:55
>>556
確かにswitch-case文よりこっちの方がいいな。これがあればif文も要らんかも。
560デフォルトの名無しさん:2010/05/01(土) 23:27:02
>>559
使える型が制限されるけど、SIMDでも威力を発揮しそうなんだよね。
>>558
switchに関するお約束やノウハウが多すぎるので、この際、switchを
破棄した方が、Cから流れてきた人に混乱が少ないと思う。
561デフォルトの名無しさん:2010/05/01(土) 23:28:53
if(A() == B()){
}else if(A() == C()){
}else if(A() == D()){
}else if(A() == E()){
}else{
}

これのswitch風構文糖が欲しいな。
evalutateってそういうの?
562デフォルトの名無しさん:2010/05/01(土) 23:31:20
>>561
もっと強烈に強力。それが出来るのは当然として。
563デフォルトの名無しさん:2010/05/01(土) 23:32:02
それはいい。採用。
564デフォルトの名無しさん:2010/05/01(土) 23:39:41
>>542
>駆動とかルーチンとかの基本的な話をしようぜ。
>
>構文にこだわるなら安全なマクロの仕組みとか。
>マクロ自体をPEGとかBNFとかで組めるようにする手もあるけどな。

この話はすごく興味があります。
なにかお考えがあればお聞かせください。
565デフォルトの名無しさん:2010/05/01(土) 23:47:12
>>563
即決だな
566デフォルトの名無しさん:2010/05/02(日) 00:03:29
switch文を置き換えるなら、強力なマッチング構文にしたいですね。
新しいswitch文に欲しい機能一覧

・1つのケースについて条件を複数組み合わせて記述できる。
・型チェックを簡潔に記述できる。
・型内の値に名前を付けて取り出すことが出来る。
・何かしらのチェック項目をすべて網羅されていることをチェックできる。

足りなければ追加してください。
567デフォルトの名無しさん:2010/05/02(日) 00:03:46
提案しておいてなんだけども、
EVALUATE文の導入には、もの凄く大きな問題が有って。
>>561
EVALUATE TRUE
  WHEN   A()=B()
  WHEN   A()=C()
  WHEN   A()=D()
  WHEN   A()=E()
END−EVALUATE.
と、

EVALUATE A()
  WHEN   B()
  WHEN   C()
  WHEN   D()
  WHEN   E()
END−EVALUATE.
では、

A()が呼び出される度に違った結果を返す関数の場合、
結果が異なる場合があり得るんだよね。

強力な甘さがあるので、そんな物だと言うことでOKだろうと思うのだけど、
その辺このコンパイラならこうなるああなるってのは避けたいと思う。

後、評価順を、1行1列、2列、3列、とするとか、一行1列、2行2列として
行くか、キーワードを追加して選べるようにするかとか。
568デフォルトの名無しさん:2010/05/02(日) 00:07:20
evaluateは知らないけど、
これ↓
if(A() == B()){
}else if(A() == C()){
}else if(A() == D()){
}else if(A() == E()){
}else{
}

と、これ↓
auto V = A();
if(V == B()){
}else if(V == C()){
}else if(V == D()){
}else if(V == E()){
}else{
}

は使い分けられるようにしたいな。
基本的には後者だけあれば十分だけど。
569デフォルトの名無しさん:2010/05/02(日) 00:08:20
正直そう書きゃいいだけの話だな
570デフォルトの名無しさん:2010/05/02(日) 00:08:44
>>568
>>567で説明したのに、それは・・・
571デフォルトの名無しさん:2010/05/02(日) 00:14:35
>>570
それなら、evaluateで問題無いわ。
書いた回数しかA()を評価されないなら誤解しなそうだし。

ただ、比較演算子がオーバーロードされる場合はちょっと怖いかな。
比較演算子の右辺と左辺を個別に処理できない場合は困るね。
572デフォルトの名無しさん:2010/05/02(日) 00:19:52
前も書いたけど、駆動だったらまずは駆動レコードをどうするかがポイントになると思う。
簡単にはC風のフラットなスタックにしちまえば良いんだけど、その場合でもインラインやマクロみたいな
別の駆動レコードに寄生する関数をOKにしたいなぁ。

またルーチンだと、引数の処理をどうするのかが一つのポイントかね。
評価後に渡すのか遅延評価&メモ化するのかでずいぶん挙動が違うし(遅延評価はバグの温床になりそうだけど)。

また、C風のサブルーチンオンリーじゃなくて、高級なコルーチンとか継続OKのルーチンとか……
……・は要らないか。

マクロは名前解決がポイントかね。cだと健全かどうかはあまり気にしなくて良さそうだけど、名前空間を汚染するか
どうかはけっこう重要にならない?
どう解決するかはあんまりアイディア無いけど。簡単には関数と同じ扱いにするのかな?


ちなみに
>マクロ自体をPEGとかBNFとかで組めるようにする手もあるけどな。
は、コンパイラのパーサをパース中に差し替えることができるようにすれば可能だよ。
573デフォルトの名無しさん:2010/05/02(日) 00:20:23
いつからかコボラーが紛れ込んでるな…
574デフォルトの名無しさん:2010/05/02(日) 00:25:05
駆動って何なの?
ググった感じ、下の記述と、このスレくらいしか出てこないんだけど、継続ともまた違うんだよね?

>【駆動レコード(フレーム)】
>
>関数呼び出しによる駆動レコードは、関数が生成する局所環境、大域環境へのポインタ、
>引数の受け渡し、戻り番地に関する情報を記録する。
>駆動レコードは、関数が呼び出されたときにスタック上に生成され、
>関数内でリターン命令が実行されたときにスタックからポップアップされて消滅する。(H17 137文字)
575デフォルトの名無しさん:2010/05/02(日) 00:26:16
>>573
COBOLは知ってる人しか知らない失われた古代文明だから、現代人にとっては学ぶべきところがある。
576デフォルトの名無しさん:2010/05/02(日) 00:26:44
>>573
前スレのENVIRONMENT DIVISION辺りから。
577デフォルトの名無しさん:2010/05/02(日) 00:43:10
>574
ごめんごめん、駆動レコードのこと。スタックフレームかアクティベーション・レコードというのが一般的かね。
まあ、スタックフレームを動かす時の動作全般のことにしといて。
578デフォルトの名無しさん:2010/05/02(日) 00:45:54
>>557
BNFで未定義があっちゃだめ。
アレはオートマトンを人間に読めるように書いたもんだと思ってくれ
字句的に未定義がダメなら変数とかの宣言どうすんの?
字句解析と構文解析とセマンティックスはそれぞれ別に考えなきゃダメ
つまりif (cond) {}とか書いてあっても動作はかいてないでしょ?てこと

switchはgo風のがいいよ。C的なswitch(xx) { case XX: }と
switch { 条件式: }って使える。
変な構文ならシンプルにif-elseの砂糖でいんじゃね

>>572
突っ込ませてもらうと、駆動レコードとか言わずにスタックフレームとか言えばいいのに。
インラインは別にフレームなんて持たなくていいし、マクロは実行時には関係ないし。
遅延評価やメモをやるなら関数型だろ。低レベル言語でやるのか?カリー化とかも?

継続とかコルーチンとかコンテキストの動的生成が必要だから
ランタイムが重くなるかもしれんが比較的軽く実装もできるし
クロージャもだが仕様にあってもおもしろいかもね

マクロが好きな人が多いみたいだが
algol系言語のmacroは黒魔術になりがちだから敬遠すべきと思うぜ
どうせやるなら変数定義とlamdaと構文的なブロックとifとgotoだけの言語作って
後は全部マクロでやったらどうさ

演算子とか構文をいじれるような言語はまったく実用的じゃないってことを
考えて見てくれ
579デフォルトの名無しさん:2010/05/02(日) 00:57:26
>>557
<<未定義>>は未定義ですってコメントとして書けばいいよ。
580デフォルトの名無しさん:2010/05/02(日) 00:57:35
ミニマリストにとってはマクロは魅力なのよ。下のほうからシームレスに弄れるし。
低水準言語だとForthなんかがそんな感じだよね。

まあ、マクロ無しでもインライン&引数評価なし関数で十分代用できるけどね。
これでもまだ落とし穴たくさんあるけど。
581デフォルトの名無しさん:2010/05/02(日) 00:59:59
ついでに書くと
スタックフレームを抽象化しようというのは
かなりアーキテクチャ依存な話だし
そんなのは意識はしつつももっと後に考えていい話。

むしろレジスタ数の多いCPUでグローバル最適化を賢く作ったら
ほとんどスタック使わないようにコンパイルできるかもしれんでしょ

スタックはあんま使わずにすべてヒープ確保何て言う方向性だってあるし
スタックをリストとか別な構造で作ったらどうよなんて
おもしろいかもしれんが低レベルから離れていく
582デフォルトの名無しさん:2010/05/02(日) 01:02:06
>>580
forthはlispと同じく永遠のマイナーだからな
583デフォルトの名無しさん:2010/05/02(日) 01:03:14
>>577
「スタックフレーム」も知らないけど、スタックを直接操作できるってこと?
どう使うんだろ。良くわからないけど、相当邪悪なことができそうだね。
584デフォルトの名無しさん:2010/05/02(日) 02:19:40
goはこれですね。
http://golang.org/doc/go_spec.html#Switch_statements
PHP もこんな感じで書けるので COBOL のEVALUATEに似てるかも
switch (true) {
case A == B:
case C != D: 処理1(); break;
default: 処理2(); break;
}
haXeはenumをswitchで使うとenumの全パターンをチェックする機能があります。
関数型言語のmatchに一段近くなるけどマッチング能力に不満も残ります。
http://haxe.org/ref/enums
Scalaになるとmatch構文とsealed case classがとても強力で値のバインディングと
チェックが出来たりifによる条件もつけたりと強力ですがclassが必要になってしまいます。
新しいC言語はclassいらないので
union UNI {
struct A (char* a);
struct B (static int b,imutable int c);
}
UNI uni = B(3,4);
switch (uni) {
case A(str): 処理1(str); break;
case B(a,b) if(hoge): 処理2(str); break;
}
というかんじがいいのかもしれません。
585デフォルトの名無しさん:2010/05/02(日) 03:18:29
EVALUATEって、MISD(Multi Instructions Single Dataっていうのか?)的なことができるのかな。

MIMDを統一的に扱える構文があるといいね。
586デフォルトの名無しさん:2010/05/02(日) 06:01:48
駅前にいけばいいじゃない
587デフォルトの名無しさん:2010/05/02(日) 09:31:06
並列となると、ケースごとの条件が一意にならないといけないですよね。
上から順番に判定するルールと、、、そのへん詳しくないのだけど。
588デフォルトの名無しさん:2010/05/02(日) 09:48:31
プリミティブ型をスレッド間でハンドリングする際に妥当なラッパーを生成コードに埋め込む様にすればいいんじゃないかな
589デフォルトの名無しさん:2010/05/02(日) 14:51:47
twitterにこのスレと似たような事をやってるクラスタがあるけど、そっちはもう動くものが出来上がっちゃってるなw
590デフォルトの名無しさん:2010/05/02(日) 14:58:33
2chが順調に終りに近づいてる気がする
591デフォルトの名無しさん:2010/05/02(日) 15:00:52
>>590
人少なくなったね

twitter始まったころとほぼ同時期に始めたけど、
いまいち何が面白いのか分からなかったからやめてたけど、
もういっかいやってみるか。
592デフォルトの名無しさん:2010/05/02(日) 15:02:41
え、ここは雑談しながら
初心者を生温かくいじるとこでしょw
最近規制も多いし
593デフォルトの名無しさん:2010/05/02(日) 15:36:43
>>590
読んでみたいけどどう検索すれば読みやすくヒットするのか
未だにわからんのだよ、twitterってどうも読みにくい。

594デフォルトの名無しさん:2010/05/02(日) 15:43:27
>>593
まずは50人フォローしてみな。
んで適当なtweetにreplyして反応をみろ。
自然にクラスタが出来上がる。
595デフォルトの名無しさん:2010/05/02(日) 15:47:49
>>594
50人ものぶつぶつ言ってること聞かなきゃ、
言語の話にたどり着けないのか?
2chより酷いな(w
596デフォルトの名無しさん:2010/05/02(日) 15:49:21
グーグルの検索でツイッターのつぶやきのようなゴミ情報をヒットさせるな
597デフォルトの名無しさん:2010/05/02(日) 15:51:53
>>595
ゴチャゴチャ言わずに行動しろw
50人登録するぐらい10分でできるだろ。
文句ばっかり言って何もしないニート的性格が身についちゃってるぞ。
598デフォルトの名無しさん:2010/05/02(日) 15:56:33
ツイッターやってる奴って何を求めてるの?つぶやき(笑)って、冗談キツいわ
599デフォルトの名無しさん:2010/05/02(日) 15:58:32
>>598
お前もつぶやいてるじゃん。
twitterではお前の呟きに対してスレ違いと言われないだけマシじゃん?
600デフォルトの名無しさん:2010/05/02(日) 15:59:57
つぶやきなんて何の価値もないからなw
スレ違いというレスポンスが返ってくることもなければ
それ以外のどんな有意義なやりとりもなされないだろうな
601デフォルトの名無しさん:2010/05/02(日) 16:04:16
>>600
同じ興味を持っているみんながお互いにフォローしあってなんとなくクラスタっぽいものが出来上がって、
そこで井戸端会議らしき事がなされる。
お互いがクラスタだと認識するために必要な機能は揃っている。
しかも荒らしは存在できない仕組みになっている。
602デフォルトの名無しさん:2010/05/02(日) 16:07:18
いやいやいや、そうじゃなくて、リンク貼ってくれよ
そこ読んでこれは参加する価値が有ると思えば参加するから。
603デフォルトの名無しさん:2010/05/02(日) 16:07:36
信者きめぇな。2chでツイッター布教しすぎ
604デフォルトの名無しさん:2010/05/02(日) 16:09:06
>>602
俺のlistを見せればすぐに納得できるだろうけど、
匿名掲示板ですることじゃないね。
自分でたどり着いてこい。
605デフォルトの名無しさん:2010/05/02(日) 16:11:21
>>603
信者とは違う。
実際に成果物を上げているコミュニティがあることを言ったまで。
606デフォルトの名無しさん:2010/05/02(日) 16:13:12
紹介できないのなら無いのと一緒じゃん(w
もうこの話はすれ違いだから終わりな。
607デフォルトの名無しさん:2010/05/02(日) 16:14:04
ちなみに、tweetを見る価値があると思われない奴はfollowerがほとんどいないから、
自分の言いたいことを誰にも聞いてもらえず、そういう奴は自然にやめていく。
つまり、ゴミはtwitterに存在できないw
608デフォルトの名無しさん:2010/05/02(日) 16:19:22
ツイッターは個人個人が勝手に好きなことを書き込むのに対して、
2chだとスレタイというテーマに沿って書き込まれるから、ある程度まとまった情報が得られる。
あとツイッターが強制コテハンなせいで自由な書き込みが少ないのも面白くない。
勝手に馴れ合ってれば良いじゃん。押し付けるなよ
609デフォルトの名無しさん:2010/05/02(日) 16:20:24
紹介したくない秘密兵器っぽい言語をつくれよ
布教する手間が省けて色々捗るぞ
610デフォルトの名無しさん:2010/05/02(日) 16:24:08
>>608
別に誰も押し付けてないけどw
2chが潰れたらお前らはどこに行くのかなぁと疑問に思っただけ。
611デフォルトの名無しさん:2010/05/02(日) 16:24:52
>>604
はあ?お前のつぶやきレベルが低過ぎるから見せられたもんじゃないんだろ
なにが、自分でたどり着いてこい(キリッだよwww
参加するに値するものを示せば参加するって言ってるのに順番がおかしいだろw
612デフォルトの名無しさん:2010/05/02(日) 16:28:39
>>611
twitterでは参加するに値するかどうか決めるのはお前じゃないんだよ。
お前がやりたいと思ったらアプローチしてくるのはお前なんだよ。
613デフォルトの名無しさん:2010/05/02(日) 16:30:00
>>607
2chでツイッターの布教してるゴミはなんなの?w
614デフォルトの名無しさん:2010/05/02(日) 16:33:33
twitterは有名人の追っかけか、リアルで交流のある連中の馴れ合いしかできない。
どんな話題で盛り上がってるかなんて、何10人何100人追っかけないと把握できな糞ツール。
615デフォルトの名無しさん:2010/05/02(日) 16:36:05
ブログとしても使えないし、mixi以上に馴れ合ったり気を使ったりする糞ツール
616デフォルトの名無しさん:2010/05/02(日) 16:44:46
チラシの裏以下の糞レスを、荒らしの如く吐き捨てる肥溜めとしては最適
617デフォルトの名無しさん:2010/05/02(日) 16:48:38
うぉ、なんで、こんな話になってるんだ。。。
黙っておけばよかった。orz...
2chは2chで、twitterはtwitterで場合によりけりだと思うんですけど。
618デフォルトの名無しさん:2010/05/02(日) 16:49:04
所詮ローカルだからな
全世界に公開されているように見えて、
検索性が悪くて誰も情報に辿り着けない
619デフォルトの名無しさん:2010/05/02(日) 16:56:57
>>615
でもリアルほど気を使わなくていいだろう
620デフォルトの名無しさん:2010/05/02(日) 17:02:00
twitterでfollowing/followers比が高いヤツほど社会不適合者。
誰と付き合うべきか一発でわかっていいよ。
621デフォルトの名無しさん:2010/05/02(日) 17:03:52
こんな2chの辺境にtwitter布教しにくるゴミとは付き合いたくない
622デフォルトの名無しさん:2010/05/02(日) 17:09:00
>>621
ところが、この過疎スレが今やム板で最も活発なスレの一つなんだよね。
ム板は2chでは一番重要な板だ。
VIPほど人は多くないがVIP住人はそもそも素人集団だ。
2chのあるべき姿を考え行動できるのはこの板しかない。
にもかかわらずこの過疎ぶり。
もう2ch終わったなとしか言いようがない。
623デフォルトの名無しさん:2010/05/02(日) 17:23:03
なにかとんでもない誤解ししている。

2chのあるべき姿を考え行動するのはこの板でも、VIPでもν速でもない。



ススキノで遊んでる中年オヤジと、フィリピン在住のアメリカ人だ。
624デフォルトの名無しさん:2010/05/02(日) 17:26:47
>>623
と思っているお前には何もできないw
625デフォルトの名無しさん:2010/05/02(日) 17:29:15
twitterで議論してる奴って、スラッシュドットとかはてなダイアリーで偉そうにしていた
自称ITコンサルとか自称ジャーナリストとか、わらわらしてそう。
626デフォルトの名無しさん:2010/05/02(日) 17:30:09
twitter民はネット社会の勝ち組。





















これで満足か?
627デフォルトの名無しさん:2010/05/02(日) 17:36:53
まぁ・・負け組は自分からやめていくからね・・・
628デフォルトの名無しさん:2010/05/02(日) 17:44:36
>>607>>627
ツイッターwwww
629デフォルトの名無しさん:2010/05/02(日) 18:20:30
【twitter大勝利】新低級言語誕生でC厨脂肪w
http://pc12.2ch.net/test/read.cgi/tech/1272791627/
630デフォルトの名無しさん:2010/05/02(日) 18:29:48
>>629
削除依頼しとけよ
631デフォルトの名無しさん:2010/05/02(日) 18:49:40
>>630
2ch以外の避難場所確保しとけよ
632デフォルトの名無しさん:2010/05/02(日) 18:52:26
両方使えばいいやん
スレチ過ぎ

しかしこのスレみてたら
今更ながら下からCとgoとscalaと
javaとjsとpythonの6つで十分だなと思う
633デフォルトの名無しさん:2010/05/02(日) 18:54:14
>>632
全部似たような言語ばかり集めたな
634デフォルトの名無しさん:2010/05/02(日) 18:57:41
Cとpythonで十分だよ
635デフォルトの名無しさん:2010/05/02(日) 19:10:37
Haskellにしとけよ
636デフォルトの名無しさん:2010/05/02(日) 19:11:28
Haskellは遅延評価であるがゆえに速度的に越えられない壁が・・
637デフォルトの名無しさん:2010/05/02(日) 19:19:07
まあそういう
クリティカルなところは正格評価させりゃいいからさ
638デフォルトの名無しさん:2010/05/02(日) 19:22:53
>>637
いや、原理的にすべての値のクロージャ変換があるからなんだけど、
最適化でなんとかなるような気もするんだけど、なんともなっていない気がする。
639デフォルトの名無しさん:2010/05/02(日) 19:33:52
RWH読んだか?
640デフォルトの名無しさん:2010/05/02(日) 19:38:09
関数型言語なんか、永遠にマイナーなんだからすっこんでろよ。
641デフォルトの名無しさん:2010/05/02(日) 19:38:15
Ruby World Hacking
642デフォルトの名無しさん:2010/05/02(日) 19:39:35
関数型言語は神のような存在だよ。まさに全知全能。一般人には手の届かない存在なのだ
643デフォルトの名無しさん:2010/05/02(日) 19:44:15
誰にも信仰されない神様
644デフォルトの名無しさん:2010/05/02(日) 19:46:38
その神がいるのが博麗神社
645デフォルトの名無しさん:2010/05/02(日) 20:09:39
悪魔は嵐の中から君たちの心に入り込む。神の道は狭い。
646デフォルトの名無しさん:2010/05/02(日) 20:14:07
名前にVなんとかとか#とかついてる奴らのことだな
647デフォルトの名無しさん:2010/05/02(日) 20:19:39
関数型なんて考えるのが間違っているんだよ。
モジュールのインターフェイスをどうするかという汎用視点で考えりゃ良い。

関数型はモジュールの影響が内部に閉じているだけだろ。
局所化の度合いは強いけど、モジュールの中と外を対称化できないコストもデカいから大変だな、
ぐらいで考えりゃいいだろ。
648デフォルトの名無しさん:2010/05/02(日) 20:22:23
関数型のコードは括弧が沢山あって大変だな、
ぐらいで考えりゃいいだろ。
649デフォルトの名無しさん:2010/05/02(日) 20:28:44
>>639
RWHはHaskellの仕組みには言及していないぞ
650デフォルトの名無しさん:2010/05/02(日) 20:30:12
最適化について徹底的に追っている章があるだろ
651デフォルトの名無しさん:2010/05/02(日) 20:45:39
気をつけろ
652デフォルトの名無しさん:2010/05/02(日) 20:46:54
生徒会が
653デフォルトの名無しさん:2010/05/02(日) 20:50:26
長く深淵を覗くならば、深淵もまた等しく生徒会を見返すのだ。
654デフォルトの名無しさん:2010/05/02(日) 20:59:31
極上生徒会
655デフォルトの名無しさん:2010/05/02(日) 21:06:41
すまねえ。俺がscalaなんてのを入れたばっかりに。。。
656デフォルトの名無しさん:2010/05/02(日) 21:29:06
幸運を祈る
657デフォルトの名無しさん:2010/05/02(日) 23:02:29
OCaml(実用レベル)
D(インディーズ)
Go(未完成)

どれかを使え

658デフォルトの名無しさん:2010/05/02(日) 23:18:16
なぜか命令形…(ゴクリ
659デフォルトの名無しさん:2010/05/02(日) 23:19:20
>>657
一番上の岡村?っての一択じゃね?
660デフォルトの名無しさん:2010/05/02(日) 23:20:49
MSは Visua F# 2010 Express を何で出さないんだろうな。がっかりだよ。
661デフォルトの名無しさん:2010/05/02(日) 23:33:04
岡村さんなにやってはるんですか。
662デフォルトの名無しさん:2010/05/03(月) 01:21:39
リストでもタプルでもいいからヴァリアント型の順序付き集合が欲しいな。
663デフォルトの名無しさん:2010/05/03(月) 01:23:48
>>660
F#は何ができるん?
664デフォルトの名無しさん:2010/05/03(月) 01:23:56
不沈艦googleの名を冠し神が作りたもうたgoに負けは無い
665デフォルトの名無しさん:2010/05/03(月) 01:25:45
googleは有り余る金でパフォーマンス的にあれやこれやと浅く広くやってる感じだろ
検索サイト以外は微妙。ハンパなネットユーザーは至れり尽くせりだと感じてるのかもしれないが
666デフォルトの名無しさん:2010/05/03(月) 01:36:14
>>665
浅く広くは自分の子とじゃねえか。ちゃんと使ってみてねえだろ
Ken Thompsonだから看板に申し分ねえし、
まだ未完成とはいえなかなか悪くねえ言語仕様だよ
アホがよってくるオブジェクト指向と誰もついてこない関数言語を避けているのは賢明だ
667デフォルトの名無しさん:2010/05/03(月) 01:38:25
は?一瞬も使った事ねえよカスが
668デフォルトの名無しさん:2010/05/03(月) 01:45:53
ググッても出てきません!
669デフォルトの名無しさん:2010/05/03(月) 02:15:05
演算子を定義できるってことは文脈に依存する文法だから
文脈自由文法の範囲外なのですね
670デフォルトの名無しさん:2010/05/03(月) 02:16:20
文脈自由とかBNFとかいう言葉をここまで見るスレも珍しいよ。どんだけ初学者ホイホイなんだ
671デフォルトの名無しさん:2010/05/03(月) 02:25:44
>>670
軽口を叩いて生み出される物があるなら教えてください
672デフォルトの名無しさん:2010/05/03(月) 02:26:05
反感
673デフォルトの名無しさん:2010/05/03(月) 02:28:04
反感は生み出すものではなくて買うものです
674デフォルトの名無しさん:2010/05/03(月) 02:31:06
買うのは生産者じゃなく消費者だよ
675デフォルトの名無しさん:2010/05/03(月) 02:35:28
矛盾している。反感を買うって変な言葉だな
676デフォルトの名無しさん:2010/05/03(月) 02:40:15
文脈に依存しない、すなわち自由であることは文法が固定されるということです。
それはつまるところ言語の設計者のみが文法を変更できるということになります。
文脈に依存することによって言語設計者だけではなく、
言語を使う人も文法を変更することができるようになります。
677デフォルトの名無しさん:2010/05/03(月) 02:50:40
>>663
岡村さんができる
678デフォルトの名無しさん:2010/05/03(月) 02:54:03
C一族が嫌いでネイティブ高速が必要ならML系しかなかろう
679デフォルトの名無しさん:2010/05/03(月) 03:05:10
スレ違いだがいかにもMSは長期凋落の会社らしいわな
javaとOCamlの方言とか作って何がうれしいんだ
680デフォルトの名無しさん:2010/05/03(月) 03:12:50
自前で持っとけばビジネスになるだろう?
Word&Excelだっていつのまにかメジャーになったし
681デフォルトの名無しさん:2010/05/03(月) 09:58:24
言語仕様検討に戻って、3項演算子って必要か?
無くても何とかなるけども、あれば便利ってのは
分かる気がするんだよね。
Wikiを見ると、pythonでは順番を変えて導入とか
書いてるし。

ンで、pythonの順番はただしいと思うのだけれども、
どうも3項演算子やってると読みにくい感じも有って。
682デフォルトの名無しさん:2010/05/03(月) 10:05:07
if が式であればいらない
683デフォルトの名無しさん:2010/05/03(月) 10:21:05
BNFは文脈自由文法を記述する記法なので文脈依存文法を記述することは出来ません。
したがってBNFではユーザー定義可能な演算子のある言語を正しく表現することは出来ません。
違和感があったのはこのためでしょう。
文脈自由であることが絶対的な物であるという思い込みが
文脈依存なものを排除したくなる要因なのではないでしょうか?
684デフォルトの名無しさん:2010/05/03(月) 10:23:01
hoge(if (...) { ... } else { ... });

C風文法だと関数型言語と違って違和感あるな
慣れの問題か
685デフォルトの名無しさん:2010/05/03(月) 10:40:02
3項演算子は要するにBNF的な記述が出来るのがメリット
例えば
e = switch(true){
case a == 2 => b
case a == 3 => c
default => d
}
というようにswitch文を式として強化したもので代用できればそちらのほうがよい
686デフォルトの名無しさん:2010/05/03(月) 11:17:29
3項演算子はマクロ関数を作るときに必要だが
inline関数や最適化機能で代用できるので
新入社員には使わないように指導している。
switchは定数との一致だけでなく変数との比較が記述できれば
使い勝手が増すが>>685のようなものはif文を使うべき。
687デフォルトの名無しさん:2010/05/03(月) 11:46:18
そのあたりはパターンマッチングで包括して扱えば良い。
パターンマッチング自体をどうするか議論しようぜ。
688デフォルトの名無しさん:2010/05/03(月) 12:21:47
実装が大変になりそうなんだけど、列挙型は値の指定が出来ない変わりに、
範囲内と言うことを強く型付けしたいと思う。

例えば
enum Weekday { SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY,SATRUDAY};

とした場合、

Weekday day;

day = SATRUDAY;
day++;
if(day == SANDAY){
 // OK SUNDAY
}

となるような感じ。

また、char* dayname[Weekday];
と定義すれば、

char* pday;
pday = dayname[7];
でコンパイルエラーが出るような事に死体。
689デフォルトの名無しさん:2010/05/03(月) 12:23:52
しかし、

char* pday;
int count=6;

count += 2;
pday = dayname[count];
は通ってしまうくらいの感じで。
690デフォルトの名無しさん:2010/05/03(月) 12:31:33
>>688
列挙型ではなく、順序型という別の型を作ったほうが良いな。
691デフォルトの名無しさん:2010/05/03(月) 12:48:28
>>686
if (a) {
 hoge[i][j] = foo;
} else {
 hoge[i][j] = bar;
}



hoge[i][j] = (a ? foo : bar);

だと、分かりやすさに関してはどっちもどっち(趣味嗜好の範囲)だが、
if を使うと左辺コピペミスや修正ミスの入る余地があるのが
個人的には問題あると思う
692デフォルトの名無しさん:2010/05/03(月) 13:02:35
>>691
if (a) x = foo;
else x = bar;
hoge[i][j] = x;

個人的には?:は結構使う方だけど、
そういうのはこう書けばいいと思うよ
693デフォルトの名無しさん:2010/05/03(月) 13:09:00
コピーにコストのかかる型の場合はどうするよ?
694デフォルトの名無しさん:2010/05/03(月) 13:23:07
>>690
むしろ、今の列挙型の方が、順序型だと思うのだが?
695デフォルトの名無しさん:2010/05/03(月) 13:24:11
Haskellの代数的データ型は超ベンリ
696デフォルトの名無しさん:2010/05/03(月) 13:24:44
foo_t *lhs = &hoge[i][j]
if (a) *lhs = foo;
else *lhs = bar;
でいいんじゃね
697デフォルトの名無しさん:2010/05/03(月) 13:24:46
強い型付けって点ではC++0xのenum classが似ているけど
配列サイズに型名を指定ってのはできないな
698デフォルトの名無しさん:2010/05/03(月) 13:27:30
>>696
どちらにしろテンポラリが3つ並ぶのが心臓に悪いというか、
ただの代入ごときでテンポラリが入る事自体がちょっと・・・と思ってしまう
699デフォルトの名無しさん:2010/05/03(月) 13:28:10
* <- これアナルに見える
700デフォルトの名無しさん:2010/05/03(月) 13:28:25
>>698
俺も?:派だけど、こういう書き方しとくと、デバッグ時に便利なこともあるよ
701デフォルトの名無しさん:2010/05/03(月) 13:30:48
まーね
[] がオーバーロードされてる時とか
702デフォルトの名無しさん:2010/05/03(月) 13:46:52
>>689
ん?
> pday = dayname[7];
は、コンパイルエラーにするけど、
> int count=6;
> count += 2;
> pday = dayname[count];
は、エラーにするなと?
だったら、
int count = 8;
pday = dayname[count];
は、どうするの?

>>697
> 配列サイズに型名を指定ってのはできないな
Pascal, Ada は可能だったような気がする。
703デフォルトの名無しさん:2010/05/03(月) 13:55:17
>>702
単に、動的評価(添え字が定義の範囲かチェックするコードを生成することになる)
はまではやらないってこと。

静的評価は出来るのでやるぞ、そう言うこと。
704デフォルトの名無しさん:2010/05/03(月) 14:02:25
わかってるヤツも書いてると思うが
gccの拡張は制限はあるが
ブロックは値を持つ
配列の宣言は定数じゃなくていい
705デフォルトの名無しさん:2010/05/03(月) 14:05:54
>>704
何が言いたいのか分からん。
C言語に代わる言語を設計しようっていうスレだよ?
706デフォルトの名無しさん:2010/05/03(月) 14:31:19
だから?
情報提供に「何が言いたいのか分からん。」て、何が言いたいのか分からん。
707デフォルトの名無しさん:2010/05/03(月) 14:38:58
>>703
そう言うことか、>>689 だと「エラーにするな」のように読めた。

最適化で >>689 でもコンパイルエラーになるケースはありそうだが、
それはいいんだよね。

個人的には、enum と int が混在しててもエラーにならないと言う
のは受け入れ難いけど。
708デフォルトの名無しさん:2010/05/03(月) 15:33:41
enumとintを分ける必要無いだろ。統一したら?
せいぜいコンパイル時整数と実行時整数を分けるぐらいだと思うけど。
709デフォルトの名無しさん:2010/05/03(月) 15:36:30
型エラーにならないほうがおかしいだろ
710デフォルトの名無しさん:2010/05/03(月) 15:40:13
>>688は半端すぎるように思えるなあ
意図が分からん

っていうか、全然「強く型付け」してないだろ、それは
void foo(int x) { Weekday wd = x; }
これを静的にも動的にもチェックせずに許すんだろ?

intとenumは非互換として、
どうしてもintとenumを変換したいんなら、実行時チェックを行う
dynamic_castっぽい仕掛けを使えばいいんじゃないの

Weekday wd = dynamic_cast<Weekday>(x);
Weekdayの範囲に入っていなければ、bad_castをスロー
まあCのレベルの言語なら別の仕掛けになるだろうけどな
711デフォルトの名無しさん:2010/05/03(月) 16:56:58
>>707
>個人的には、enum と int が混在しててもエラーにならないと言う
>のは受け入れ難いけど。

その通りだ、配列の宣言にenumを使える変わりに、そこはenum
型にすれば良いんだ。確かにおっしゃる通し。
712デフォルトの名無しさん:2010/05/03(月) 17:23:20
連想配列のキーにenum型が使えるってことだね。
それはそれでいいかと
713デフォルトの名無しさん:2010/05/03(月) 19:30:57
普通の配列の方が効率が全然いいから
実装上、連想配列でenumはおいしくないな
ま、言いたいことはわかるがね
714デフォルトの名無しさん:2010/05/03(月) 19:43:51
しかしintとenum互換てのは低レベル記述じゃ便利
がちがちな列挙型というとPascalとか思い出すよw
715デフォルトの名無しさん:2010/05/03(月) 19:50:03
>>714
言語を設計しようっていうスレなんだから、
ニュース速報系みたいな、そういう気分を語られても困る。
こういう場合こうなって便利とか書いて欲しい。
>>713
やるとしたら、普通の配列で行くべきだと思ってる。
連想配列とかはライブラリ対応。
716デフォルトの名無しさん:2010/05/03(月) 19:55:19
まあ気楽にやれよw
バイナリのインターフェース書くのに
enumが順序不明ベース型不明とかじゃやりにくいだろ?
717デフォルトの名無しさん:2010/05/03(月) 20:18:51
なんでもごった煮できる言語がいいなら、ポインタと整数の区別もなくすといいな。
ついでに変数も、a は a[0] の意味ってことにして、配列と一本化。
718デフォルトの名無しさん:2010/05/03(月) 20:30:33
なんでもいいからenumの値全部についてループできるようにしてくれ
719デフォルトの名無しさん:2010/05/03(月) 20:41:41
>>716
> バイナリのインターフェース書くのに
そんなところに enum 使う状況が想像できない。

>>714, >>717
「本物のプログラマ」用の言語ですか?
720デフォルトの名無しさん:2010/05/03(月) 21:01:04
アセンブラ
721デフォルトの名無しさん:2010/05/03(月) 21:17:59
BASICのVariantは型がはっきりしないところがバカにされる原因になっていたが、最近はやり出した動的型付けの言語はまさにそう。
722デフォルトの名無しさん:2010/05/03(月) 21:46:20
>>721
> BASICのVariantは型がはっきりしないところが

はぁ? Variant の型がはっきりしないなんて初耳だ。
型をはっきり意識せず使っててバカにされてる奴はいたと思うが。
723デフォルトの名無しさん:2010/05/03(月) 21:49:25
>>721
型が変数に結びついている=静的型
型がオブジェクト/インスタンスに結びついている=動的型
ってだけの話

動的型だが型付けの強い言語もあれば、
静的型だが型付けの弱い言語もある

馬鹿にされるべきはどっちかっつーとお前なんじゃね
724デフォルトの名無しさん:2010/05/03(月) 21:53:56
そういえばC++で開発された動的言語が少ないのは、型を崇拝しているからなのか
725デフォルトの名無しさん:2010/05/03(月) 21:57:51
Variant型が気にくわなければObject型でもいいよ。
726デフォルトの名無しさん:2010/05/03(月) 22:00:05
「最近流行りの動的型言語」がどういうものか見せてやる
分かったら糞して寝ろ

>>> x = 1
>>> y = "this"
>>> type(x)
<type 'int'>
>>> type(y)
<type 'str'>
>>> x + y
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
727デフォルトの名無しさん:2010/05/03(月) 22:04:19
>>719
いんだよ。enumなんて構文にとりこんだ定数定義みたいなもんで。
それだけで不要なマクロなくせる訳だし
計算しちゃっておかしくならないよう演算を制限するだけでよし
728デフォルトの名無しさん:2010/05/03(月) 22:10:48
>>726
COM VARIANTとの違いを説明してくれ。
VBでこれはできるか? みたいなのはよしてよ。
729デフォルトの名無しさん:2010/05/03(月) 22:21:40
>>728
は?

>型がはっきりしない
>最近はやり出した動的型付けの言語はまさにそう

とか馬鹿げたことを言ってるようだから、動的型言語の実例を見せただけだよ
730デフォルトの名無しさん:2010/05/03(月) 22:28:19
動的型付けはコンパイル時にチェックできないのが痛いな。ランしてみないとエラーが分からない地雷みたいなものだ。そんなの怖くて客先に納入できないよ。
ちょっとしたスクリプトには良いが、大規模になるときつい。
731デフォルトの名無しさん:2010/05/03(月) 23:01:35
>>730
単にテストのカバレッジ率が低いんじゃねえか

といいたいところだが、テストが多くなるのが動的型言語の欠点だわな。
Cの代わりになる言語は静的な型でいいだろ
732デフォルトの名無しさん:2010/05/03(月) 23:02:07
>>729
BASICという言語をわざわざだしているのに、型がはっきりしないという言葉をそのように曲解するという思考がよくわからない。
733デフォルトの名無しさん:2010/05/03(月) 23:07:06
>>732
いや、VBのOLE VARIANTって要はタグつきunionだろ?
本質的には動的型言語におけるオブジェクトと一緒だよ

変数の型として(静的に)データが何者かを記述しているのではなく、
自分が何者かを「データ自身が」知っている

「知ってる」んだから、「はっきりしない」というのはおかしいね
それで「馬鹿にされる」とかいうのも意味不明
734デフォルトの名無しさん:2010/05/03(月) 23:12:25
void*よかValiantの方がまだ実行時にチェックできるだけ
ましなデータ型なんだが
中身が何であれ勝手に型変換して通してしまうのが
バカにされる原因だろ
735デフォルトの名無しさん:2010/05/03(月) 23:13:32
VBはバカに使わせる言語だからしゃあねえ
MS系言語は頭悪いから次行こう
736デフォルトの名無しさん:2010/05/03(月) 23:14:12
企業としては正しい
737デフォルトの名無しさん:2010/05/03(月) 23:14:28
>>733
Option Strict を使わず、なんでもVariantにするやつをバカにしていたもんだけどな。
このコンテキストではっきりしないというのは、実行時まではっきりしないという意味だろ。
それ以外の解釈法は私には発想できないな。
738デフォルトの名無しさん:2010/05/03(月) 23:14:31
>>734
C++のキャスト演算子や非explicitなコンストラクタのことですね分かります
739デフォルトの名無しさん:2010/05/03(月) 23:16:58
そういえばC++で開発された言語が少ないのは
文字列処理はランしてみないと入力文字列をチェックできないからなのか
740デフォルトの名無しさん:2010/05/03(月) 23:22:09
ブートストラップしにくいし
ランタイムかくのにC++いらねえ
言語処理はCでも十分
741デフォルトの名無しさん:2010/05/03(月) 23:33:40
C以外に自分自身で書かれている言語って何かあるのかな? 
742デフォルトの名無しさん:2010/05/03(月) 23:36:59
C++みたいな変な色の付いた言語を
新たな言語設計者は好まないだろうな
743デフォルトの名無しさん:2010/05/03(月) 23:38:39
>>741
PyPy
744デフォルトの名無しさん:2010/05/04(火) 00:00:36
>>741
もっと高級な言語だと結構あるよ。
例えばlispとか
745デフォルトの名無しさん:2010/05/04(火) 00:11:32
言語じゃないけど、gccも自分でコンパイルするしな。
746741:2010/05/04(火) 00:11:53
743>>744>> サンクス
探したらちゃんとこんなのがありましたw
http://en.wikipedia.org/wiki/Self-hosting
747デフォルトの名無しさん:2010/05/04(火) 00:12:11
>>741
Java、MonoのC#
748デフォルトの名無しさん:2010/05/04(火) 00:36:55
Dim range As Variant
Set range = [A1]
range = 3 ' さあどうなるか
749デフォルトの名無しさん:2010/05/04(火) 07:26:12
記号演算子を減らして整理整頓したいんだけど、
”<<” ”>>” のシフト演算子って記号じゃなくて、
プロパティで対応するってのどうだろうか?
例えば、

AreaOfTriangular = base * height >> 1;
AreaOfTriangular = base * height.rightshift(1);

ただこれだと演算子の優先順位の問題が出てくるので、
精度を確保したい場合、こうやって。

AreaOfTriangular = (base * height) >> 1;
AreaOfTriangular = (base * height).rightshift(1);

こういうのも有りって事で。ビット演算子も、同様に
radius.and()
radius.or()
radius.xor()
radius.not()

代入については全体に宗教論争になると思うので後回しにするとして、

&& は AND に、 || は ORにしたい。
750デフォルトの名無しさん:2010/05/04(火) 08:08:09
SmalltalkとRubyですね
751デフォルトの名無しさん:2010/05/04(火) 08:18:32
>>でシフトってわかりやすいじゃねえか
むしろfoo >* 4でrorとかbit単位で使える範囲指定子とか
代入、コピー、演算なんかが欲しいね
他にbit型とかでbit var[100][2]とかで2bitx100の配列とかそういうの
変な記号が多いとわかりにくいが、アルファベットばっかも読みにくい
752デフォルトの名無しさん:2010/05/04(火) 08:24:25
ああ重箱隅つつきだが、/2の代わりに>>と書くのは余り良くないぞ
753デフォルトの名無しさん:2010/05/04(火) 08:26:56
>>751
C言語の良さは、演算子がsizeof除いて総て記号で統一されてる事にも有って、
その伝統を大事にしたいと言う気持ちはもの凄く分かるんだけど、それならば
C言語で良い訳だよ。

C言語からC++ときて、0x、拡張されている内に、記号演算子が増えすぎた
のと、優先順位だとかなんだとか、で、読み辛く、実装依存が増えすぎたと思うんだ。
なので、ここらで整理したいってのが>>1なので、そういう視点からの反論が
欲しいんですよ。こんな問題が起きるとか、結局は混乱の元とか。
754デフォルトの名無しさん:2010/05/04(火) 08:28:28
>>749
ビット演算はあまり多用しないだろうから、記号じゃなくてもいいと思う
&&や||はあった方がコードが見やすくていい
755デフォルトの名無しさん:2010/05/04(火) 08:32:35
>>752
計算式の中のビットシフトという事を表現するのに良い例が
見つからなかったので。

>>751
追加、ビットロテートはIntelぐらい?Intelというかx86ぐらい
しか持ってない?その辺詳しくないんだけど、それでそちらの対応は、
あれじゃない、CPU依存言語拡張、前から言ってるENVIRONMENT
DIVISIONの導入で、

unsigned int aa=1;

aa.intel_rot(4);
とかどうだろ?intelにするかx86にするかとか有ると思うけど、
それは後の議論だ罠。
756デフォルトの名無しさん:2010/05/04(火) 08:43:42
あーーーーーー後、今思いついたんだけど、

.rightshift();
.leftshift();
.rightlot();
.leftlog();

って面倒だから、サイン付きで+なら左、マイナスなら右って事で
どうだろ?

aa << 4 == aa.leftshift(4)
なので
aa << 4 == aa.shift(4)

aa >> 4 == aa.rightshift(4)
なので
aa >> 4 == aa.shift(-4)

実装出来るのか?
757デフォルトの名無しさん:2010/05/04(火) 08:46:20
>>754
組み込み屋だかんな
ビット演算なんて普通に多用するし
しょぼいCPUなら多彩なbit演算やrorができたら速くなる演算もあったりすんのよ
bitmapテーブルなんかもよく使うし。
でもCPUにbit演算機能があってもCからは使えなかったりする
演算の種類なんてむしろもっと増やして積和演算用の演算子とか
並列演算範囲の指定とか欲しいね
ま、そういう要求もあるってことね。

富豪なPCクラスのシステムだけ考えるならいまさらCの代替品なんて山ほどあるし
758デフォルトの名無しさん:2010/05/04(火) 08:51:26
>>752
なんで?
759デフォルトの名無しさん:2010/05/04(火) 08:54:10
C言語のシフト演算の欠点はキャリービットみたいな桁あふれ情報が消えちゃうこと。
おかげでアセンブラよりシフト演算が面倒になってる
シフト演算を実装するなら、桁あふれ情報を保持してほしい
(ついでにCPUのフラグレジスタの情報もあると便利かもしれない)

uint8_t x = 0xaa;
x.<<(2);                    #記号でも単語でもどっちでもいいけど
puts x.flood;  #=>2      #2ビットのシフト演算で溢れたビット(2b'10)

uint32_t x = 0xffff.ffff;
x += 1;
puts x;        #=>0
puts x.carry; #=>1

とかね
760デフォルトの名無しさん:2010/05/04(火) 09:01:00
>>759
それなんとかしたいんだけど、どんな表記構文にすれば良いか
タイミングの問題が有るじゃん。

例えば、

bb = aa.leftshif(4) * 5;

という構文にどうやって突っ込むのが分かりやすいか?
後、機械語に落とせる構文じゃないと不味いし。
761デフォルトの名無しさん:2010/05/04(火) 09:07:36
キャリーフラグとかないCPUはどうすんだよ
762デフォルトの名無しさん:2010/05/04(火) 09:10:53
その部分だけアセンブラでいいだろ。
763デフォルトの名無しさん:2010/05/04(火) 09:13:25
>>761
だから、それはCPU拡張で行くんだよって言ってるだろうが。
対象CPUに対してコンパイラ作るんだから、その辺言語仕様で
定義しておけば、新しいCPU作りやすいし、コンパイラも作りやすいじゃん。

CFを持ってるCPU
INTELのCF
をどう交通整理するのかはもう少し後で考えるとして。
言語から、intel_cf 定数を操作出来る訳だよ。
それをどんな構文で扱う事にすれば良いのかて話。

で、例えばintel_cfを使ったプログラムをCFを持たないCPUで
コンパイルするときには、基本的にコンパイルエラーもしくは、
CFを扱えるコードを生成するとかね、そういう風にやっていけば良いと思うんだ。
リファクタリングを視野に入れた言語って事かな?
764デフォルトの名無しさん:2010/05/04(火) 09:15:58
インラインアセンブラでいいだろ。
言語をややこしくする意味がわからん。
765デフォルトの名無しさん:2010/05/04(火) 09:16:10
intelがベースかよ
766デフォルトの名無しさん:2010/05/04(火) 09:18:21
>>760
演算のたびに更新されるでいいと思うけど・・・

確かに、CPUのフラグ変数はグローバルだから、演算のたびに
設定・参照すると重くなっちゃうね。
普通は通常通りで、べつに、溢れ情報を考慮する演算を追加するのがいいかな
aa.leftshift_with_carry(4) とか
767デフォルトの名無しさん:2010/05/04(火) 09:19:06
>>764
アセンブラ記述してしまうと最適化の恩恵を受けられないから。
CFを見る必要のないビットシフトの場合、CPUによって、
シフト命令の方が早かったり、かけ算しちゃった方が早かったり
するでしょ。そこなんだよ。
768デフォルトの名無しさん:2010/05/04(火) 09:19:13
s/フラグ変数/フラグレジスタ/
769デフォルトの名無しさん:2010/05/04(火) 09:22:14
やはり固有言語君だな
まずそのIntel-Win-COBOL脳を改善する必要がありそうだなw
CPU固有の方言言語なんて誰も考えてないだろw

フラグは一見面白そうだがかなり難しいぜw
昔PL/Mで判定に使えたような記憶があるが、
どの演算で変化するかとかCPUによって違うし
最適化すると演算順序変わったり、演算がなくなったり、
関数呼んだら壊れるし、複雑な式のフラグはどうなるのか予想不可能だ
770デフォルトの名無しさん:2010/05/04(火) 09:22:26
>>761
参考までに知りたいんだけど、それなんていうCPU?
771デフォルトの名無しさん:2010/05/04(火) 09:22:47
>>767
フラグぐりぐり使っているところに最適化も期待するのか。
772デフォルトの名無しさん:2010/05/04(火) 09:24:30
>>767
インラインアセンブラは普通に最適化対象だぞ
だいたいそんな命令の置き換えなんてまさに最適化の仕事だろ
773デフォルトの名無しさん:2010/05/04(火) 09:26:55
SHとか知らんの?
774デフォルトの名無しさん:2010/05/04(火) 09:30:46
>>773
知らなかった。SHは無いんだ
775デフォルトの名無しさん:2010/05/04(火) 09:31:50
シフトよりかけ算が速いCPUなんてあんの
776デフォルトの名無しさん:2010/05/04(火) 09:31:59
>>772
どういう最適化の対象かって問題ですがな。
777デフォルトの名無しさん:2010/05/04(火) 09:34:53
ここでキャリーフラグを示すシステム変数の登場
778デフォルトの名無しさん:2010/05/04(火) 09:35:10
>>769
答えたことにまで、異論挟んでくるその知性が
どうにも、答えに対して再反論してくるのなら
ともかく。
779デフォルトの名無しさん:2010/05/04(火) 09:37:12
uint9_t x;
uint33_t x;
780デフォルトの名無しさん:2010/05/04(火) 09:37:17
>>777
じゃなくて、問題はキャリーフラグはCPUグローバルなので
計算の度に更新されちゃうから、どう記述すると違和感なく
扱える構文になるか、って問題で、場合によってはフラグを
退避しても良いと思うんだけどね。そこだよ。
781デフォルトの名無しさん:2010/05/04(火) 09:40:31
C言語って低水準な割に、CPU最大公約数的で残念なんだよね。
CPU最大公約数+対象CPU拡張で、CPU最小公倍数的な言語が出来れば
C言語の代わりの新言語と言えるんじゃないのかなって思うんだ。

C言語拡張したいわけでも、もう一つ別のC言語や式言語作りたい訳じゃなく、
そう言うのは、もう既にみんなやってる。
782デフォルトの名無しさん:2010/05/04(火) 10:13:13
if文拡張して
if.carry
if.nocarry
if.zero
if.nozero
とか
783デフォルトの名無しさん:2010/05/04(火) 10:22:56
>>781
> CPU最大公約数+対象CPU拡張で、CPU最小公倍数的な言語

自分ではうまいたとえだと思ってるんだろうけど、何を言いたいのか
さっぱりわからん。
784デフォルトの名無しさん:2010/05/04(火) 10:26:20
>>782
もうセミコロン廃止して
st1; st2; st3;をst1.chain(st2).chain(st3)にしようぜ。
785デフォルトの名無しさん:2010/05/04(火) 10:29:08
>>782
+. -. >>. <<.
crc演算が美しく書ける
786デフォルトの名無しさん:2010/05/04(火) 10:30:55
キャリー持ち越し演算子もいるんじゃね
787デフォルトの名無しさん:2010/05/04(火) 10:37:54
お前ら具体的なアプリを作る気ないだろ
それこそ公約数的で残念じゃねーか
788デフォルトの名無しさん:2010/05/04(火) 10:48:15
>>782
その発想は無かったわ。そっちの方が良いかも。

今考えてたのは、cpu_flg型を作って。
cpu_flg qa,qb;

aaa.leftshift(4,q=intel_cf);
if(q){
キャリーが有った
}
とすればどうだろうかだったんだけど。

ンで、例えば、
DD= aaa.leftshift(4,qa=intel_cf)+bbb.leftshift(4,qb=intel_cf);
if(qa){
}else if(qb){
}
とか書けちゃえて、
この場合は、CFを退避するコードを生成する事にしたらどうだろ?
789デフォルトの名無しさん:2010/05/04(火) 10:49:08
フラグ持ち越すレジスタとかメモリが必要になっちゃうよ
790デフォルトの名無しさん:2010/05/04(火) 10:50:45
ンで、>>788の最初の例では、そのまま直ぐに評価してるので、
CFを退避するコードは生成しないで、2番目の場合は退避しなきゃね
ってコードを生成する。
791デフォルトの名無しさん:2010/05/04(火) 10:52:20
>>789
>>790で書いたけど、それは覚悟の上で、でも、次のif文とかが
安全ならば、フラグ持ち越さない、フラグを退避しないように
最適化出来たら良いねって事で。
792デフォルトの名無しさん:2010/05/04(火) 10:58:54
最適化考えるよりは、
フラグがつぶれそうなときは出口でCPU依存でフラグのset/resetする方がいいような
793デフォルトの名無しさん:2010/05/04(火) 11:24:24
聞きたいんだけど。
俺の手元には、x86と、PPC601の命令リファレンスが有るんだけど、
32bit以上のCPUでこれは見ておけっての有る?
この際だから、シェアは有るんだけど命令セットが貧弱
そんなCPUな方が良いと思う。

それからインターネットで手に入ると嬉しい。

32bit以下はめんどくさいから考えたくない。
794デフォルトの名無しさん:2010/05/04(火) 13:19:30
新言語としては現行のCPUの細かい仕様にあわせて必要以上に妥協したりはしないから
CPUの一般的な機能について知っているなら改めてデータシートを見る必要はないよ。
(もちろん、個人でCPUの勉強するのはいいことだからどんどんやっていただいて構わないよ。)

それと、低級言語としては組み込み向けが多いから16ビットCPU以下も対象にしないとね。
(これも、一般的な機能を知っているなら改めてデータシートを見る必要はないよ。)
795デフォルトの名無しさん:2010/05/04(火) 13:52:08
>>793
命令セットが美しいのは68030とMIPS32
美しくないのはSPARCとARM
潔いのはSHとIA64
796デフォルトの名無しさん:2010/05/04(火) 13:53:29
>>794
君はそれで実装と提案やっていけばいいと思う。

後、組み込み分野でも16bitは終焉してきてるので、
16bitはC言語やアセンブラに任せておけば良いと思う。
そもそも、64K程度なんだからアセンブラで充分だし。
797デフォルトの名無しさん:2010/05/04(火) 13:55:52
>>796
じゃあ、それでおk。
実装は言語仕様が固まった後だけどね。
798デフォルトの名無しさん:2010/05/04(火) 14:14:42
>>796
> そもそも、64K程度なんだからアセンブラで充分だし。

いまどきそれはないわ。
799デフォルトの名無しさん:2010/05/04(火) 15:21:59
CPU固有言語君とマシン語の美しさ語る老害のコラボ
800デフォルトの名無しさん:2010/05/04(火) 18:07:11
今でも組み込みじゃ8/16bitは多いぜ
アセンブラなんて冗談かよ
801デフォルトの名無しさん:2010/05/04(火) 19:01:32
今日、使われてるC/C++製のOSから新言語製のOSが主流になることなんて生きているうちにあるのだろうか?
802デフォルトの名無しさん:2010/05/04(火) 19:03:04
一生CP/M使ってろ
803デフォルトの名無しさん:2010/05/04(火) 19:14:12
速度のために安全性を犠牲にする
少ないタイプ量のために一意性を犠牲にする
私は英語を使うので英語だけ扱えればいい

いずれもC言語が生んだ悪しき慣習
早々に切り捨てねばなるまい
804デフォルトの名無しさん:2010/05/04(火) 19:25:25
今日のOSでもアセンブラは使われ続けているので、
新言語の新OSでも裏方ではCが使われ続ける
805デフォルトの名無しさん:2010/05/04(火) 20:18:58
アセンブラの使用を認めると、Cから変換しただけのコードも認めざるをえない。
全く新しい物を作りたいなら、Cだけでなくアセンブラも禁止するべき。
806デフォルトの名無しさん:2010/05/04(火) 20:25:27
マジかよ…2進数の世界来たこれ
807デフォルトの名無しさん:2010/05/04(火) 20:41:47
存在する全CPUの固有命令を包括した開発言語など存在し得ない
よってアセンブリ言語禁止など妄言の極みである
何度も言うが抽象化不可能と分かってる部分まで抽象化しようとするな
808デフォルトの名無しさん:2010/05/04(火) 22:24:03
ますますこのスレの電波度が上がってるよなw
809デフォルトの名無しさん:2010/05/04(火) 22:29:57
ネタがネタとして機能する範囲内で頑張ってくれ
じゃなきゃ腐る
810デフォルトの名無しさん:2010/05/04(火) 23:19:23
>805
馬鹿だな。全てのプログラム言語が基本的に等価だということを知らんのかね。
>807の通り基本的な部分と特殊な部分を分離するのが普通だろ。
特殊な部分はミニ言語orマクロで実装すれば良い。
だからベースはForth(ry
811デフォルトの名無しさん:2010/05/04(火) 23:34:59
なにいってんの
全ての道はlispへとつながっとる
812デフォルトの名無しさん:2010/05/04(火) 23:39:07
どんな言語つくってもいいからさ
コンパイル後にCのソースを吐けばややこしいこと考えないで作れるぜ?
813デフォルトの名無しさん:2010/05/05(水) 00:04:46
低級言語ということをお忘れなく
814デフォルトの名無しさん:2010/05/05(水) 00:17:50
だから書いたんだよ
Cなら中間の言語に申し分ないからな
815デフォルトの名無しさん:2010/05/05(水) 01:42:56
OS作るのに必要なものは全部ライブラリやスタートアップにでも突っ込めばいい
そうすればアセンブリ言語は直接触る必要も無い
816デフォルトの名無しさん:2010/05/05(水) 01:52:41
最近じゃめっきりアセンブラを使うことは減ったが
アセンブリでやる必要があるのはOSだけじゃないがね。

ちょいスレチな風味だが
直I/Oとか割り込みハンドラなどの低レベルライブラリが
CPU毎に異なってるのが組み込み屋の悩みだな
メーカ提供のライブラリの出来も千差万別だし
言語の話と離れるが、共通化してくれたらいいのにね
817デフォルトの名無しさん:2010/05/05(水) 02:11:09
>>816
しょーがね
それが共通化出来たらデバイスドライバを書くプログラマの仕事が
無くなる事だけは確かだが
818デフォルトの名無しさん:2010/05/05(水) 02:11:51
悪いageちまった
819デフォルトの名無しさん:2010/05/05(水) 03:18:36
>>816
mathライブラリなんかもアッセンブラで書かれてるよね。 
goのmathライブラリにもある。

./src/pkg/big/arith_386.s
./src/pkg/big/arith_amd64.s
./src/pkg/big/arith_arm.s
./src/pkg/bignum/arith_amd64.s
...
820デフォルトの名無しさん:2010/05/05(水) 06:15:42
コンパイラのランタイムは四則演算なんかも含めてアセンブラ多いね
高速なメモリコピーとかも。
>>817
デバイスは多用だからそんなことはないと思うが
キャッシュセーフなI/Oとか諸々の奴がね。
同じ名前なら実装はなんでもいいって感じ
OS向けにはまた別途コードはいるだろうけど
821デフォルトの名無しさん:2010/05/05(水) 09:01:20
今でも速度重視のところはアセンブラ。
普通の人がアセンブラで書いてもコンパイラの最適化に勝てないけど。
822デフォルトの名無しさん:2010/05/05(水) 09:12:43
>>821
コンパイラの最適化が追いつかないって話よりも、
CPU固有の力を効率よく出すのにアセンブラが必要なのですよ。
少し前とは時代が変わってる。
823デフォルトの名無しさん:2010/05/05(水) 09:22:54
>>822
それはコンパイラの仕事だろ。
824デフォルトの名無しさん:2010/05/05(水) 09:24:57
コンパイラも万能じゃない
825デフォルトの名無しさん:2010/05/05(水) 09:28:55
せっせとアセンブラで書いてコンパイラの最適化に負けたときの悲しさはない
826デフォルトの名無しさん:2010/05/05(水) 09:31:50
今ではコンパイラの最適化に勝てる場面はせっせとSSE2/3を使って
論理演算をさせた時ぐらいになってきてるよ

それ以外の時は手でアセンブラを書く時間でコンパイルして走らせて
しまった方がずっと速い
827デフォルトの名無しさん:2010/05/05(水) 09:32:05
最適化の期待度
??>VM>コンパイラ>手アセ
828デフォルトの名無しさん:2010/05/05(水) 09:54:42
アセンブラの必要ステップ数を適当に推定して、コンパイル結果を逆アセしてステップ数が推定に近くなるまでソースをいじってコンパイルしなおしてるな。
829デフォルトの名無しさん:2010/05/05(水) 10:05:01
超越関数なんかは自分でアセンブラで書いたほうがコンパイラ付属のものより速くできるけどな
数学わからん奴には無理だが
830デフォルトの名無しさん:2010/05/05(水) 10:06:11
数学わからんがエッチな関数だということは知っている
831デフォルトの名無しさん:2010/05/05(水) 10:24:55
乗除算の結果をフルに利用する場合は手アセの方が速かったり
832デフォルトの名無しさん:2010/05/05(水) 11:05:11
インラインアセンブラは構文じゃなくて、関数で実現したらいいと思うんだぜ。
833デフォルトの名無しさん:2010/05/05(水) 11:11:39
>>831
int year=365,week=7,yearofweek,int mod;

”/(剰余=%)”と言う演算子を作ってみる。
yearofweek = year /(mod=%) week; //...(1)

”/(剰余)”と言う演算子を作ってみる。
yearofweek = year /(mod) week; //...(2)

”/(剰余)/”と言う演算子を作ってみる。
yearofweek = year /(mod)/ week; //...(3)

”/剰余/”と言う演算子を作ってみる。
yearofweek = year /mod/ week; //...(4)
これは駄目だな、余剰を取らないのと区別付かない。

”/%=剰余”と言う演算子を作ってみる。
yearofweek = year /%=mod week; //...(5)
右向き代入と左向き代入が混在

”/剰余=%”と言う演算子を作ってみる。
yearofweek = year /mod=% week; //...(6)
=%と区別がつかん。

”/剰余%”と言う演算子を作ってみる。
yearofweek = year /mod% week; //...(7)
すっきりして良いかも。

なので、(1)か(7)でどうだろうか?
834デフォルトの名無しさん:2010/05/05(水) 11:14:56
分かりにくいわ
835デフォルトの名無しさん:2010/05/05(水) 11:15:50
実際にこういうコード書いてるんだろうなあ…
836デフォルトの名無しさん:2010/05/05(水) 11:18:44
>>834
気持ちは分かるんだけど、インテルのCPUだと、DIV命令で、
商と余りがいっぺんに出るんだよね。まぁ当然と言えば当然なんだけど。
なので、旧来のC言語の記法だと、商と余りを得るために、ただでさえ
重たい割り算を二回発行しなきゃならないんだよ。

それをどうやって構文の中に織り込んでいくのが良いかって事で、
読みにくいという批判は重々承知の上で、それでもまだ我慢できる
そういう記法を考えて欲しいんだよ。
837デフォルトの名無しさん:2010/05/05(水) 11:21:47
日本語とコメントが汚いだろ
838デフォルトの名無しさん:2010/05/05(水) 11:33:47
year of weekってなんなん?
839デフォルトの名無しさん:2010/05/05(水) 11:36:43
weeksinayearを言いたかったと思われ
840デフォルトの名無しさん:2010/05/05(水) 11:37:50
こいつの書いたドキュメント読みたくないなぁ
841デフォルトの名無しさん:2010/05/05(水) 11:38:42
一週間が何年か?ってことだろ
だいたい0.02年くらいか?
842デフォルトの名無しさん:2010/05/05(水) 11:45:36
逆だろ普通。
843デフォルトの名無しさん:2010/05/05(水) 11:58:36
int year = 365;
int week = 7;
int weeks_in_a_year;
int mod;

// :% … 左側に商、右側に剰余を出す演算子っぽい何か
weeks_in_a_year :% mod = year / week;

//#せめてこのぐらいは…
844デフォルトの名無しさん:2010/05/05(水) 12:00:34
俺も何言ってるのか分からんな
845デフォルトの名無しさん:2010/05/05(水) 12:01:47
>>843
それも考えたんだけど、
weeks_in_a_year :% mod = year / week;

weeks_in_a_year :% mod = year / week * 7/5;

の場合どうしようもなくなるので、UPしなかった。
846デフォルトの名無しさん:2010/05/05(水) 12:01:52
ゆとりはdiv関数も知らんのか
内部実装と最適化次第でx86のdiv命令直接操作と同等のコードが得られるのに。
847デフォルトの名無しさん:2010/05/05(水) 12:03:04
>>846
だから、関数でOKというのなら、C言語使ってれば良いんだよ。
848デフォルトの名無しさん:2010/05/05(水) 12:04:49
>>843
std::pair<int,int> divmod(int lhs,int rhs)
{
return std::make_pair(lhs/rhs,lhs%rhs);
}

//
boost::tie(weeks_in_a_year,mod)=divmod(year,week);
849デフォルトの名無しさん:2010/05/05(水) 12:40:34
複数パラメタ出力作ってほしい
int q, r, a, b;
(q,r)=div(a,b);

unsigned int x, y, z;
bool c;
(z,c)=add(x,y);
こんな使い方ができる

あとはビット連結(::)とか、その左辺値代入とか。
c::z = x+y;
850デフォルトの名無しさん:2010/05/05(水) 12:47:39
ビット連結てなに?
851デフォルトの名無しさん:2010/05/05(水) 12:51:58
852デフォルトの名無しさん:2010/05/05(水) 12:56:43
>>850
32ビット2個を並べて64ビットとして扱うような。
853デフォルトの名無しさん:2010/05/05(水) 12:58:41
ビッチ連結ってなに?
854デフォルトの名無しさん:2010/05/05(水) 13:00:04
simdじゃダメなんだべか?
855デフォルトの名無しさん:2010/05/05(水) 13:00:33
こういうアホな要求が言語仕様をぐちゃぐちゃにするんだよね
とくに腰の軽いスクリプト系で
856デフォルトの名無しさん:2010/05/05(水) 13:04:28
スクリプト系は作者が使い易いと思えればそれでいいって感じ
857デフォルトの名無しさん:2010/05/05(水) 13:07:29
各社、各CPUのSIMDを比較サイトって無いかな?
MMXから考えると沢山有って、ややこしい。
それぞれに、アセンブラ使ってくれ、という時代が長かったから
しょうがないんだろうけど、後今度インテルが全面的に更新した
命令セット出すとか言ってるし。
858デフォルトの名無しさん:2010/05/05(水) 14:16:44
>>836
商と剰余が同時に求まるのは別にインテル CPU に限ったこと
じゃなくて、割と一般的な動作だよ。

問題は一つの式から二つの結果が返るのをどう扱うかの問題で
片方の値を特殊変数に返す (1) とか、複数値を返す構文 (2)
を作るとかがよくある手だよな。

(1) yearofweek = year / week; mod = _mod_; // _mod_ が特殊変数
(2) (yearofweek, mod) = year / week;

ただどっちの方法も、除算を複数含む式の扱いがスマートにで
きない。なんか、いい方法あるかなぁ。
859>>858:2010/05/05(水) 14:19:49
>>843, >>849 とかぶってた。
忘れてくれ。
860デフォルトの名無しさん:2010/05/05(水) 14:30:09
だから、関数でいいだろ
861デフォルトの名無しさん:2010/05/05(水) 14:44:55
>>860
> 除算を複数含む式の扱いがスマートにできない。
862デフォルトの名無しさん:2010/05/05(水) 14:54:18
結局演算子とか構文を変えるとかその程度の話か
863デフォルトの名無しさん:2010/05/05(水) 14:54:25
タプルみたいなのじゃなく多値返すのが普通な仕様なら
低レベル的にも効率よいな
関数でやるのは組み込みかinline関数必須で参照渡しなのが汚いんだよね
864デフォルトの名無しさん:2010/05/05(水) 14:57:32
だからさ、多値ってsimdとどう違うのさ?
865デフォルトの名無しさん:2010/05/05(水) 14:58:19
(yearofweek, mod) = year /% week;
866デフォルトの名無しさん:2010/05/05(水) 15:05:03
多値は言語レベルの概念で、SIMDはアーキテクチャのレベルの用語で、
レイヤが全く違わないか?
867デフォルトの名無しさん:2010/05/05(水) 15:09:55
多値でやるならコンテキストでわけて
商 = a / b
商, 余 = a / b
でいけるわな
左辺にカッコつけるとリストやタプルみたいなんが構文的に必要になるからダメ
868デフォルトの名無しさん:2010/05/05(水) 15:11:53
実際にリストやタプルを生成しないで
タプル構文を導入すればいいんだね
869デフォルトの名無しさん:2010/05/05(水) 18:34:38
Cの返り値は基本レジスタに入れて返すのだけど、複数の値を返す場合の
ノウハウがないのが問題のようなので、多値を返せる関数フレームのあり方
はどうあるといいのか考えてみては?

870デフォルトの名無しさん:2010/05/05(水) 18:50:27
http://d.hatena.ne.jp/yuyarin/20090825/1251136545

twitterでの議論があったよ
871デフォルトの名無しさん:2010/05/05(水) 19:02:10
複数の戻り値を返せる言語はあるでしょ
872デフォルトの名無しさん:2010/05/05(水) 19:14:16
>>869
>>870 の議論の通り実装については
> 機械語レベルでは構造体の返却と同じ扱いで実装可能
で全然問題ない。

メモリーを使うかレジスタで返すかは CPU によっても違うし。

問題は、わかり易い構文をどうするかで、>>870 のリンク先でも結論
出てない。
873デフォルトの名無しさん:2010/05/05(水) 19:30:10
>>872
CPUじゃなくてコンパイラじゃ?
当然、コンパイラがどちらを選択するのかっては、
CPUで決めるんだろうけど。

874デフォルトの名無しさん:2010/05/05(水) 19:31:56
,で並べると複数値のコンテキストつー感じでいいんじゃないの
Cの,演算子を見直して構文要素とするか複数コンテキストを作る演算子とする
すると多値戻り値も関数引数も多値の演算もすべて複数値コンテキストとして同列に扱える
c,d = foo(a,b=1,5*2,3)なんてのも許しちゃう
複数値を返す関数の戻り値をそのまま次の関数に渡せるし。
875デフォルトの名無しさん:2010/05/05(水) 19:35:51
>>873
レジスタ数と戻り値の型や数で決まるんじゃない
基本型2-3個くらいならほとんどのcpuでレジスタだろうし
続きの使い方次第ではスタック積んだり、入れるレジスタを最適化したりできそう
876デフォルトの名無しさん:2010/05/05(水) 19:38:03
>>870
のまとめはまとめじゃなくて、議論の出発点だな。

>>874
プログラミングモデルで考えると、おいらはむしろ、
戻り値を返さない事にしたい位だけどなぁ。
boolしか返せないようにしたいんだけど、現実的かどうかで
少し悩む。
LWLに馴染んだ人かな?
877デフォルトの名無しさん:2010/05/05(水) 19:38:17
>>874
既存の,はどうすんの?
878デフォルトの名無しさん:2010/05/05(水) 19:39:06
>>874
Cで書かれたpythonで出来てるんだから当然出来るんだろうが

今なにを問題にしてるんだっけ
879デフォルトの名無しさん:2010/05/05(水) 19:44:01
>872
構造体戻しにするんだったらデータを引き出すのは呼び出し元の責任だよ。
呼び出し元の負担を低減するんだったらデフォルト値を用意するという手があるけど、
デフォルト値を戻して欲しいのか多値を戻して欲しいのかはやっぱり呼び出し元の責任だわな。

それよりも多値をバラして使いたいときの方が面倒だな。Cの場合だと一度変数に代入して名前を付けなきゃいかん。
Delphiのwithみたいなのが欲しいけど、構文の話なんで後でも良いや。
880デフォルトの名無しさん:2010/05/05(水) 19:45:25
>874
そこまでやるならForth(ry
881デフォルトの名無しさん:2010/05/05(水) 20:04:36
>>873
> CPUじゃなくてコンパイラじゃ?
確かにそうだな。
CPU によって、レジスタで返しやすいやつとそうでないやつがあるって
言う意味で書いてた。
882デフォルトの名無しさん:2010/05/05(水) 20:11:19
>>881
多値戻り値を議論してるときにそれは無いわ(w
883デフォルトの名無しさん:2010/05/05(水) 20:23:40
多値戻りは、戻りを組み立ててはばらす処理を頻繁に行うことになる。タプルなら組み立てたまま扱えるメリットがあるな。
884デフォルトの名無しさん:2010/05/05(水) 20:28:27
>>874
> 複数値を返す関数の戻り値をそのまま次の関数に渡せるし。

int, float foo(int);
void bar(int, float);
bar(foo(1)); ってやると、

int i;
float f;
i, f = foo(1);
bar(i, f); ってなるってこと?

foo() の、int だけ使いたいときはどうする?
つまり、i, f = foo(1); bar(i, 1.0); ってやりたい時。

>>877
「新たなプログラミング言語」なんだから、既存のやつは
気にしなくていいんじゃね。
885デフォルトの名無しさん:2010/05/05(水) 20:38:17
>>884
じゃあ、今まで通りi, j = 0;なんて書くとどうなるんだろう。
こんなことで悩むぐらいなら(i, j ) = foo(1);と書かせればいい。

ついでにvoidに代入できるようにして、(i, void) = foo(1); bar(i, 10);
とさせればいい。ついでに関数の引数リストと
(x,y,z)記法を同一視できればいい。
#どんどん変な方向へ。
886デフォルトの名無しさん:2010/05/05(水) 20:48:30
> つまり、i, f = foo(1); bar(i, 1.0); ってやりたい時。
bar((i=foo(),i),1.0); でいいんじゃないかな?
887デフォルトの名無しさん:2010/05/05(水) 21:10:41
多値戻り値なんて、テンポラリオブジェクト作って
そのアドレスを渡しまくればいいだけ
888デフォルトの名無しさん:2010/05/05(水) 21:12:26
>>878
タプルみたいなのはデータ型を導入せにゃならん
Pythonの多値はそんな奴だね
>>884
まさにそんな感じ。多値の一つを選択したいなら
bar( i,f = foo(1); i, 1.0)
てな感じでどう。
>>885
i,j = 0は多値コンテキストにシングル値代入だからエラーだ
多値はgolangをイメージしてるんだが引数にはできないんよね
あっちはvoidじゃなく_が捨て変数だね

ちなみにgolangは代入は並列に評価されるからa,b=b,aでswap
a,b=1,2*2,3は出来なくてa,b=1*2,2*3だ

とタプルつーより引数も戻り値も無名で型推論からstructの実体を作るような
イメージを考えたらいいんよね
889デフォルトの名無しさん:2010/05/05(水) 21:19:24
>>887
構文に組み込めば ({a as int ,b as int ,c as bool})func();
呼び出し側が任意で返り値を捨てられる。if ((x)=func)〜 → if (x=a,(bool)c)〜
従来型のモノな返り値型と互換性が保てる。if (func()) 〜 → if (func(),c)〜
890デフォルトの名無しさん:2010/05/05(水) 21:27:36
美的感覚のない文法を量産するでない
891デフォルトの名無しさん:2010/05/05(水) 21:28:52
>>886, >>888
> bar((i=foo(),i),1.0);
> bar( i,f = foo(1); i, 1.0)
う〜ん、一時変数は避けられないか...。
だったら、個人的には素直に2文に分けて書くようにした方が
いいように思う。

>>882
何を言いたいんだ?
892デフォルトの名無しさん:2010/05/05(水) 21:37:13
>>890
言ってもしょうがないから、多値戻りは彼らに任せてしまえば良いと思う。

893デフォルトの名無しさん:2010/05/05(水) 22:03:59
bar((use, ) = foo(), 1.0);
bar(( , use) = foo(), 1.0);
894デフォルトの名無しさん:2010/05/05(水) 22:11:56
多値戻しで何を実現するの?
構造体でダメな理由は?

単にバラすのが面倒というのなら、それこそパターンマッチングを応用すれば良いのに。
895デフォルトの名無しさん:2010/05/05(水) 22:17:55
多値のn番目を取り出すのであれば、
bar(foo()[0], 1.0);とするとか?

関数の引数は多値であると考えると
bar foo() で、fooが多値ならbarの引数として渡せるといいのかも。
896デフォルトの名無しさん:2010/05/05(水) 22:22:12
>>894
構造体だといちいち定義しなければならない。
定義しなくても使えるtupleで十分なんだけどな。tupleの状態で取り回せるのでいちいちばらす必要も無いしな。
897デフォルトの名無しさん:2010/05/05(水) 22:30:06
タプルだとオーバヘッドがあるだろ
構造体をいちいち定義するのも面倒
パターンマッチって意味わからん
データ型を想定しないで多値のコンテキストってを考えたら?
first classで扱っても面白いけど、皮むかないと普通の関数に渡せないよな
898デフォルトの名無しさん:2010/05/05(水) 22:32:28
>>896
それは、LWLの考え方だと思うんだ。
定義することが一々なのか、ライブラリになってしまって
実装詳細を得られ無い事や、変更されたときにどうするっていう
視点が無い。

この視点がないのが問題。

己をよく知ってから、言葉使い選んだ方が良いよ。
899デフォルトの名無しさん:2010/05/05(水) 22:33:05
読みにくいかな?
seconds を sec, min, hour, dayに分解。

#include <stdlib.h>

div_t t;
t.quot = seconds;
int sec, min, hour, day;

t = div(t.quot, 60);
sec = t.rem;
t = div(t.quot, 60);
min = t.rem;
t = div(t.quot, 24);
hour = t.rem;
day = t.quot;
900デフォルトの名無しさん:2010/05/05(水) 22:37:38
>>899
今まで出てきた中で一番分かりやすいな。
901デフォルトの名無しさん:2010/05/05(水) 22:40:42
> 己をよく知ってから、言葉使い選んだ方が良いよ。

正直、鏡を見てみることをお勧めする。
902デフォルトの名無しさん:2010/05/05(水) 22:45:21
rest, sec = second / 60
rest, min = rest / 60
day, hour = rest / 24
903デフォルトの名無しさん:2010/05/05(水) 22:45:23
>>901
LWLの考え方、と言う部分には反論無しかな(www
904デフォルトの名無しさん:2010/05/05(水) 22:52:20
>>902
sec, rest = second / 60
min, rest = rest / 60
hour, day = rest / 24

名なしの型はいいが、名なしのフィールドは間違いの元
905デフォルトの名無しさん:2010/05/05(水) 22:54:29
今のコンパイラなら>>899のソースで
これくらいのコードは吐いてくれるだろう。
mov eax,[second]
xor edx,edx
mov ebx,60
idiv ebx
mov [sec],edx
xor edx,edx
mov ebx,60
idiv ebx
mov [min],edx
xor edx,edx
mov ebx,24
idiv ebx
mov [hour],edx
mov [day],eax
これのどこが不満なんだ。
mov ebx,60が2回あったら不満なのか。
906デフォルトの名無しさん:2010/05/05(水) 22:55:48
水と安全があれば良いのに、なぜか満たされないんだよね
907デフォルトの名無しさん:2010/05/05(水) 22:58:21
scalaでの多値
object a {
 def main(argv:Array[String]):Unit = {
  var a,b = foo();
  var (c:Int,d:Int) = foo();
  var e,f:(Int,Int) = foo();
  var (g,h) = foo();//型推論
  var (i,j):(Int,Int)=foo();// warning
// i,j = foo(); error
// (i,j) = foo(); error
 }
 def foo():(Int,Int) = {
  return (1,2);
 }
}
実装はジェネリックスを使ったjavaのclass。Tuple2〜Tuple20がある。
cのレベルで考えれば型情報のポインタ付きの構造体。
構造体を生成しなくてすませられるかどうかはJVM次第。
908デフォルトの名無しさん:2010/05/05(水) 23:00:15
>>907
いい加減にしてくれよ、C、C++の置き換え言語を作ろうって
話なのに、OSごとくっついてくるjavaの話されても困るんだって。
909デフォルトの名無しさん:2010/05/05(水) 23:04:18
>>905
OS作るときには標準関数無いから。
こっから話さなきゃ駄目?
910デフォルトの名無しさん:2010/05/05(水) 23:07:30
>>909
算術演算ライブラリも無いのか。
FPUの無いCPUではdoubleは使えないのか。
それは困った。
911デフォルトの名無しさん:2010/05/05(水) 23:10:53
おまえら
LISPを作ろうとしているぞ
912デフォルトの名無しさん:2010/05/05(水) 23:11:27
>>894 >>897
scalaで書けばパターンマッチングでこのようにかけるので
こういうことだと思うよ
object a {
 def main(argv:Array[String]):Unit = {
  foo() match {
   case (a:Int,b:Int)=>println(a+b)
  }
 }
 def foo():(Int,Int) = {
  return (1,2);
 }
}
913デフォルトの名無しさん:2010/05/05(水) 23:14:51
>>908
javaのbytecodeは中間表現に置き換えて
JVMの最適化フェーズでやることをコンパイルタイムにやれば同じでしょ。
914デフォルトの名無しさん:2010/05/05(水) 23:15:39
>>911
Algolライクのな
915デフォルトの名無しさん:2010/05/05(水) 23:16:47
>>913
もしかして、本気で、それが反論たり得ると考えてる?
916デフォルトの名無しさん:2010/05/05(水) 23:18:38
>>909
OSに依存しない関数はあっていい。
917デフォルトの名無しさん:2010/05/05(水) 23:19:31
ついったーの餓鬼どもが押し寄せてきてるような気がする(ww
918デフォルトの名無しさん:2010/05/05(水) 23:29:20
>897
関数の戻り値の型を定義する時にどのみち必要だろ。
別定義が面倒ならばそれこそ関数宣言で戻り値の型を定義できるようにすれば良い。

で、>912みたいにして構造体の一部に名前を付けて活用する、と。
919デフォルトの名無しさん:2010/05/05(水) 23:33:44
>>904
pythonだったらこう出来るね
def div(dividend, divisor):
 quot = dividend / divisor
 rem = dividend % divisor
 return (quot, rem)


rest,sec = div(second, 60)
rest,min = div(rest,60)
day, hour = div(rest,24)

これはかなり読みやすい。 標準でmathにあっても良さそうだね。
920デフォルトの名無しさん:2010/05/05(水) 23:35:26
>>905
GCCはだめだった。 IMULとSARの組み合わせを吐いた。
921デフォルトの名無しさん:2010/05/06(木) 00:57:07
>>917
ジジィどももな
仲良くしようぜ
同じ日本人じゃないか
なに?キモイって?
922デフォルトの名無しさん:2010/05/06(木) 01:25:14
>>920
それは定数での除算を逆数での乗算に最適化しているな。
idivとか滅茶苦茶遅いから正しい最適化だ。
60と24を引数で渡してやるとちゃんとidivを発行してくれる。
VC++だと/と%を連続して記述してもidivは1回しか発行しないように
最適化してくれる。GCCでも似たようなものだろう。
923デフォルトの名無しさん:2010/05/06(木) 01:42:38
unsignedの掛け算をunsigned long longにして欲しい時に
(unsigned long long)a * b と書いてもmulに最適化されないgcc
VC++はどうなんだ
924デフォルトの名無しさん:2010/05/06(木) 02:01:21
>>923
VC++はmul一発だな。
925デフォルトの名無しさん:2010/05/06(木) 16:45:53
多値はリスト型でいいよ
926デフォルトの名無しさん:2010/05/06(木) 22:03:40
動的メモリ管理乙
927デフォルトの名無しさん:2010/05/06(木) 22:11:31
タチだけじゃなくてネコの話もしろよ
928デフォルトの名無しさん:2010/05/06(木) 22:30:09
で、そろそろ何か決まったか?
929デフォルトの名無しさん:2010/05/06(木) 22:45:26
>>899
改良した。

div_t sec, min, day_hour;

sec = div(seconds, 60);
min = div(sec.quot, 60);
day_hour = div(min.quot, 24);

printf ("%d days %02.2d:%02.2d:%02.2d¥n",
day_hour.quot, day_hour.rem, min.rem, sec.rem);
930デフォルトの名無しさん:2010/05/06(木) 22:45:44
>>928
変数×関数はリバ可と決まった
931デフォルトの名無しさん:2010/05/06(木) 22:53:32
quotって何?
せめて div_t の定義でもあれば分かりやすいんだけど。
932デフォルトの名無しさん:2010/05/06(木) 22:56:26
>>931
つ stdlib.h

typedef struct {
int quot; /* quotient */
int rem; /* remainder */
} div_t;
933デフォルトの名無しさん:2010/05/06(木) 22:57:12
一昨日簡単な文法はなんだろう、と考えた。
簡単といってもBASIC的な簡単さではなく、
シンプルといった意味の簡単さだ。
そうしていろいろ作ってみたが、要するにそれはLispだった。
934デフォルトの名無しさん:2010/05/06(木) 22:58:16
Lispだろ、と書くまでもなかったな
935デフォルトの名無しさん:2010/05/06(木) 22:58:22
>>932
thx
936デフォルトの名無しさん:2010/05/06(木) 23:52:05
Forth! Forth!!
937デフォルトの名無しさん:2010/05/07(金) 00:17:06
frothってよくわかんね
1 2 +ならしってる
ポーランド基本ね
938デフォルトの名無しさん:2010/05/07(金) 00:37:44
・新しいC言語ではタプルがあるとよさそう。
・最適化技術次第で割り算の商と余りは1つの命令に最適化可能。
・名前なしの構造体あるいは、ジェネリックスで作成されたものと出来そう。
・演算子を定義できるように作れば割り算の商と余を出す演算子はライブラリとして作成可能。
・ただしヘッダファイル等にその情報を記述しておかないとリンクできない。

ジェネリックスをどうするかが課題と。
939デフォルトの名無しさん:2010/05/07(金) 00:42:31
>>933 Lispの呪縛に囚われずにもっと自由に考えるんだ!
C言語はLispより表現力があるだろう。
C言語の表現力の本質は何だ?
940デフォルトの名無しさん:2010/05/07(金) 00:55:23
>>938
新しいC言語にジェネリクスとか、演算子の再定義とかいらねーよ
C++でもやってろよ
941デフォルトの名無しさん:2010/05/07(金) 01:08:26
>>938
では何が欲しいんでしょうか?
942デフォルトの名無しさん:2010/05/07(金) 01:14:32
タプルとヘッダいらんだろ
無名構造体と型推論は欲しいね
943デフォルトの名無しさん:2010/05/07(金) 01:15:48
演算子の定義もいらんね
定義の混乱したのはスパゲッティじゃなくてなんて言えばいんだろ
944デフォルトの名無しさん:2010/05/07(金) 03:36:49
GPL汚染
945デフォルトの名無しさん:2010/05/07(金) 04:25:44
MSベンダーロックインの間違いじゃね
946デフォルトの名無しさん:2010/05/07(金) 07:48:04
GPL汚染だよ
947デフォルトの名無しさん:2010/05/07(金) 08:57:06
>>938
>・最適化技術次第で割り算の商と余りは1つの命令に最適化可能。

「最適化」という表現は適切ではないと思うが、商と剰余を同時に扱うなら多値型を使うのだろう。

>・ただしヘッダファイル等にその情報を記述しておかないとリンクできない。

ヘッダファイルはいらないだろ。
948デフォルトの名無しさん:2010/05/07(金) 09:45:18
他の言語と同様にIDEの使用を前提として
C/C++のヘッダファイルを不要にする。
共通ライブラリは外部参照として別途設定し
宣言は自動的にスコープ内に反映させる。
リアルタイムで構文エラーをチェックする。
これだけで敷居が大分下がる。
949デフォルトの名無しさん:2010/05/07(金) 10:44:02
Javaの強みはファイル単体でコンパイルユニットが完成してしまうこと。
Cと違ってファイル単品で文法レベルならパースできる。
これがJavaのIDEを強力にさせてる。

Cだとインクルードはあるわ、
マクロがトークンをいじったり、トークンを結合したりできる。
950デフォルトの名無しさん:2010/05/07(金) 11:08:45
組み込みならどうせクロスで開発するんだから、
現在の標準的な開発機で現実的な時間でコンパイルが終わるのであれば
必要以上にコンパイル速度に配慮する必要ない。

コンパイル速度のためにプログラマーに必要以上の手間をかけさせない方がいい。
951デフォルトの名無しさん:2010/05/07(金) 11:32:36
じゃあJAVAでよくね?携帯でも使えるし
952デフォルトの名無しさん:2010/05/07(金) 11:33:50
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
953デフォルトの名無しさん:2010/05/07(金) 11:47:56
>>952
じゃあ今までの議論には意味があったとか思ってるの?
954デフォルトの名無しさん:2010/05/07(金) 11:52:09
次スレ

【超高速】C/C++に代わる低級言語を開発したい 5
http://pc12.2ch.net/test/read.cgi/tech/1273199795/
955デフォルトの名無しさん:2010/05/07(金) 12:00:35
>>949-950
インクルードは悪しき伝統だよな。
コンパイラ屋がサボりたいだけだしな。

確かに実装を隠蔽できるというメリットは確かにあるが
もう少し便利になってもいいと思う。
956デフォルトの名無しさん:2010/05/07(金) 13:09:31
その議論は終わってる。
957デフォルトの名無しさん:2010/05/07(金) 13:11:34
その結論は?
958デフォルトの名無しさん:2010/05/07(金) 13:13:57
>>957
ヘッダはIDEが頑張って作る
959デフォルトの名無しさん:2010/05/07(金) 13:18:17
ヘッダは要らない。

実装を隠すためにとかで、どうしても必要ならばコンパイラが吐けるようにしてもいい。
960デフォルトの名無しさん:2010/05/07(金) 13:22:05
基本的にヘッダーファイルは無しということで。
961デフォルトの名無しさん:2010/05/07(金) 13:22:33
・割り算の2つの値を取得するには多値があればよい。
・多値は名前なしの構造体にする。
の2つですか?
962デフォルトの名無しさん:2010/05/07(金) 13:28:24
C++0xのようにリストを戻り値にできるようにすればいいな。

return {1, 0};

割り算の場合は、商だけ取りたいこともあるだろうから
{商, 剰余}のリスト型を、商の型に暗黙キャスト出来てもいいかもしれない。
963デフォルトの名無しさん:2010/05/07(金) 13:29:15
>>957
>>958>>959、これ以上の結論は仕様をまとめる人というか
コンパイラ作る段階になってコンパイラ組む人が自分の好みで
決めれば良いと思う。
ここで結論出すような話題じゃないし。

今はどんなアイデアがあり得るか、っていう段階。
争点として別視点が有るのなら提供して欲しい、
964デフォルトの名無しさん:2010/05/07(金) 13:29:54
IDE前提とかいう与太話はよそでやってくれ
少ない脳みその補完道具と言語とは全然関係ない
965デフォルトの名無しさん:2010/05/07(金) 13:37:27
ヘッダのような手動で作るものは今後はなしになるだろうね
でも内部を隠してexport, import出来る仕組みはないと困るわな
コンパイルしたらobjとともにヘッダ的な情報を用意する必要はあるとおもう
966デフォルトの名無しさん:2010/05/07(金) 13:39:15
>>964
IDEに優しくないというのは、Cの欠点のひとつ。IDEの便利機能を拒否するアホは相手にしなくていい。
967デフォルトの名無しさん:2010/05/07(金) 13:40:25
>>962
それってリストを戻してるのじゃなくて返す型の一時オブジェクトを初期化した
ものを返しているのだから、受け取る方で複数の変数に代入出来る訳じゃ
ないから>>904みたいな事ができる訳じゃないね。 
968デフォルトの名無しさん:2010/05/07(金) 13:43:20
コンパイラが、Windowsでいう.libを作るというのならヘッダなしでもいけるが、C同様に.objをアーカイブして.libにするならヘッダファイルは必要になるだろう。
969デフォルトの名無しさん:2010/05/07(金) 13:43:53
>>967
/演算子が{商,剰余}リストを返すようにして、イコールの前に複数の変数が並んでいればその順に商と剰余を代入するようにすればいいんじゃないの。
970デフォルトの名無しさん:2010/05/07(金) 13:44:38
>>968
そんなのリンカーの仕様だろ。言語には関係ない。
971デフォルトの名無しさん:2010/05/07(金) 13:50:24
商と剰余の両方が必要な状況はそれほど多くない。関数が構造体を返せばできること。わざわざそのために構文を用意するほどのものではない。一般に順序のない多値を返すことができるようにするなら、意味が順序に依存してしまうのは、分かりにくいプログラムを生む原因になる。
972デフォルトの名無しさん:2010/05/07(金) 13:53:18
>>970
ライブラリ関数の型を知らなきゃ駄目なので、色々大変なんだよ。

>>971
>商と剰余の両方が必要な状況はそれほど多くない。関数が構造体を返せばできること。わざわざそのために構文を用意するほどのものでは
CPUを見るとね、って事。(X=CF)と同じ気持ちって奴?
A %= B;
C /= B;

より重くなる多値は、この手の議論からは既に外れてる。
973デフォルトの名無しさん:2010/05/07(金) 13:55:18
>>970
Cはプロトタイプがあるので参照する.objが存在しなくてもコンパイルができる。それを禁止たところで循環参照を解決する何らかの仕組みが必要になる。
974デフォルトの名無しさん:2010/05/07(金) 13:56:33
>>971
つまり、関数呼び出しの時も、すべて名前付きパラメータにするべきだってことだな。

memcpy(dest:d, src:s, n:sizeof(d));

みたいな。
975デフォルトの名無しさん:2010/05/07(金) 13:57:49
>>972
> ライブラリ関数の型を知らなきゃ駄目なので、色々大変なんだよ。

いろいろとは?プログラマーが大変なの?
976デフォルトの名無しさん:2010/05/07(金) 14:29:17
>>975
そもそもコンパイル時に型が決定できないのでコンパイルできない。
テンプレートのようにリンク時に評価することは原理的には可能であろうが、そんな解決は美しくないし、分かりにくい。
977デフォルトの名無しさん:2010/05/07(金) 14:29:29
ヘッダというか言語的な外部参照の情報だからリンカーでもないんだよな
import hogeみたいに使う奴
コンパイルしたらheader的ファイル
PreCompiledHeaderみたいなのを自動で作る感じでいいだろ
今のように手動で作る必要はないわな
978デフォルトの名無しさん:2010/05/07(金) 14:35:38
>>976
>そもそもコンパイル時に型が決定できないのでコンパイルできない。

そんなのコンパイラが頑張ればいいだろ。
979デフォルトの名無しさん:2010/05/07(金) 14:36:28
>>977
そうだね。必要なときに自動生成できればそれでいいと思うよ。
980デフォルトの名無しさん:2010/05/07(金) 14:40:08
>>978
型を知らない関数を、プログラマはどうやって呼び出すのか?

気合いで行くってのも良いのかも知れない。
981デフォルトの名無しさん:2010/05/07(金) 14:47:10
>>980
マニュアル嫁
982デフォルトの名無しさん:2010/05/07(金) 14:49:41
>コンパイラが、Windowsでいう.libを作るというのならヘッダなしでもいけるが、C同様に.objをアーカイブして.libにするならヘッダファイルは必要になるだろう。

.objをアーカイブした.libって型情報とか入っていないの?
983デフォルトの名無しさん:2010/05/07(金) 15:00:17
elfとかcoffみたいな.oや.aをコンパイラが読むのか?
>>977でいいんじゃねえの
吐く情報はxmlでも新言語のやつでも全く独自でもいいけどさ
>>981
問題は人間じゃなくてコンパイラがどうやって知るかだろう
984デフォルトの名無しさん:2010/05/07(金) 15:04:11
>>983
だから、人間を問題にしてるのは>>980なんだが。
>>978はコンパイラに頑張れと言ってるし、>>981は人間にはマニュアル嫁と言っている。
985デフォルトの名無しさん:2010/05/07(金) 15:10:38
ヘッダーファイル無しってもうGoがやってるじゃん。 コンパイラが頑張ってる。
986デフォルトの名無しさん:2010/05/07(金) 15:22:14
>>985
あれは独自の.aを読んでるみたいね

987デフォルトの名無しさん:2010/05/07(金) 15:30:57
>>985
それは、Javaにヘッダがないのと同じ理由。jarの間の依存関係は、非循環である必要があるが、Cでは循環参照した.oを作ることができる。
988デフォルトの名無しさん:2010/05/07(金) 15:32:22
循環参照くらいコンパイラが見つけろよw
989デフォルトの名無しさん:2010/05/07(金) 15:53:55
無理いうなw
循環参照は汚えし
990デフォルトの名無しさん:2010/05/07(金) 19:31:13
99 名前:デフォルトの名無しさん [sage] 投稿日:2010/05/07(金) 19:26:58
前スレ埋めろよ
991デフォルトの名無しさん:2010/05/07(金) 20:55:43
ヘッダーファイルって、実質マクロのためにあるようなもんだよな。
んで、マクロの重要な機能の1つに定数の置換があるわけだが、これはどうするの?
まさかエディタで置換とか言わないよな?外部参照の手段は?
992デフォルトの名無しさん:2010/05/07(金) 21:11:08
ほんものの定数があればいらんだろ
993デフォルトの名無しさん:2010/05/07(金) 21:12:03
ダウングレードだが
言語サポートのマクロに変えればいい
994デフォルトの名無しさん:2010/05/07(金) 21:36:29
Javaが悲しい事に成ってるしな
995デフォルトの名無しさん:2010/05/07(金) 21:59:38
>>993
マクロの置換はインラインだから実行時のオーバーヘッドが無いんだよ。
const修飾だとグローバルスコープに置かなきゃならんので参照のたびにオーバーヘッドが生じる。
この差は非常に大きい。2つを解決できるアイディアはないもんかね?
996デフォルトの名無しさん:2010/05/07(金) 22:01:03
それはコンパイル時に最適化できるだろう。
997デフォルトの名無しさん:2010/05/07(金) 22:01:25
inline constで。
998デフォルトの名無しさん:2010/05/07(金) 22:26:59
inline修飾はあくまでコンパイラへのヒントでしかない。
プログラマの意図どおりにバイナリを生成する保障はどこにもない。
マクロはプリプロセスなので必ずインライン展開される。その違いを認識せよ。
999デフォルトの名無しさん:2010/05/07(金) 22:45:29
このスレではCを現在の文法でつくり直すわけじゃない。その点を認識せよ。
1000デフォルトの名無しさん:2010/05/07(金) 22:46:26
1000
10011001
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。