- 1 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 19:45:18 ]
- プログラミング言語処理系の開発に興味のある人達のスレッドです。
字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。
前スレ
1 pc.2ch.net/tech/kako/981/981672957.html
2 pc2.2ch.net/test/read.cgi/tech/1021136715/
3 pc5.2ch.net/test/read.cgi/tech/1070089173/
4 pc5.2ch.net/test/read.cgi/tech/1100097050/
5 pc8.2ch.net/test/read.cgi/tech/1106129164/
6 pc8.2ch.net/test/read.cgi/tech/1115335709/
7 pc8.2ch.net/test/read.cgi/tech/1129287390/
関連リンクは多分 >>2-10 あたり
- 950 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 06:38:49 ]
- 開発が進むごとに関数が増え続ける言語では、
関数の数が多すぎて、管理しきれなくなるからだろ。
関数の使用目的や機能等で特定の関数が使用可能な領域を縛ったりすれば、
もしかしたら可能だったかもしれんが・・・
- 951 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 06:47:00 ]
- > 開発が進むごとに関数が増え続ける言語では
増えない言語ってあるの？
- 952 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 07:04:54 ]
- >>951
現在、検案中。
特定の関数の使用できる条件を、経由した関数名や
オブジェクト等で限定できるようにすれば、
関数の個数を減らす事は可能かな？とか考えてる所。
- 953 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 07:46:32 ]
- 要するに、心当たりは無いが、将来的には存在するかもしれないって事か。
- 954 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:00:51 ]
- Cは開発が進むごとに関数が増え続ける言語だが
(Common Lispのパッケージのような名前空間すらない)、
結構大きなシステムが書かれてるよな。
>>950のいう「管理しきれなくなる」というのは
どれくらいの規模のソフトウェアなのかまず明らかにしろ。
- 955 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:30:42 ]
- しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
だからCの後継言語に名前空間が存在するわけで。
- 956 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:38:35 ]
- >>955
> しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
下調べもせずにこんな適当な思い込みで開発するのはいかがなものか
- 957 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:43:31 ]
- というか、949に対する答えとしては、950はおかしいぞ。
HakellやSchemeが「開発が進むごとに関数が増え続ける言語」で
C++やJavaが「開発が進むごとに関数が増え続けない言語」なのか？
- 958 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:57:04 ]
- C++やJavaは、関数が増え続けないように歯止めをかける事が可能な言語かと。ｗ
まあ、その機能を有効活用している例は少ないようだが。ｗｗ
- 959 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 10:42:50 ]
- ヘッダ＆変なプレフィクスが名前空間＆クラスになったと。
本質はあまり変わってないが言語機能でサポートされたから多少は楽に。
- 960 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 12:39:44 ]
- 関数の数なんてソフトウェアの複雑性ではマイナーな問題だろう。
たかが関数が増えることよりも、クラスを一個定義するだけで
ポインタやらconstなポインタやら参照やらconstな参照やら
もちろんあと値渡しも、そしてconstなメンバ関数やらconstでない
それやら、関数ポインタやらメンバ関数ポインタやら……を考えないと
いけないC++の方がはるかに大変だ。
テンプレート使ってると特に。
- 961 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 12:40:37 ]
- えーと。
大概のLispやSchemeのような古い関数型言語には名前空間ないけど、
MLやHaskellなどちょっと新しい関数型言語には名前空間あるよ。
というつっこみを誰もしないのはなぜですか？
- 962 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 13:29:03 ]
- MLが新しいって?
- 963 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 13:44:57 ]
- すまん、全てのMLが新しいみたいに言っちゃったな。
といっても正直、古いLispや古いMLはろくに知らないんで、
少なくとも今生き残っているLisp、MLについては、ってことにしてくれ。
さらに自分で言っといてなんだけど、Schemeって名前空間ないんだよね？
オブジェクト指向っぽいメッセージパッシングなどを
エンコードする形で自力で書け、ってことなのかな。
- 964 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 15:45:28 ]
- LispやSchemeに名前空間がないつっても、Cと違って局所関数やクロージャ、
プロパティリストなどがあるからいくらでも階層構造に出来るしなあ。
その上大抵はベンダーがオブジェクト指向やモジュール機能
提供してるのがデフォだし。
つうか、オブジェクト指向機能を一番最初に搭載したのってLispでしょ？
- 965 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:04:57 ]
- オブジェクト指向とかそのへんはまた荒れるんで、とりあえず
関数型言語は関数が増えるから使い物にならない
か否か、だけにしとこうよ。
- 966 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:10:40 ]
- >>965
だからそのことについてだよ。
ようは、C++やJavaにクラス階層の名前空間があるから、
関数が増えても整理できるっていいたいんだろ？
だったら、Lispで出来るし、むしろLispが最初だってこと。
- 967 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:14:58 ]
- 「大概のLisp」って何時のLispを指してるんだ?
Common Lispにはパッケージがあるぞ。
Schemeは処理系依存だが、次の規格で何か入るらしい。
- 968 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:16:16 ]
- >>967
CommonLispに加えて、Schemeも入れてたから。
- 969 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:18:05 ]
- つまり、関数が増えるからどうのというのはｍとんでもない勘違いでFA。
- 970 名前：デフォルトの名無しさん [2005/12/20(火) 16:21:11 ]
- emacs-lispのイメージがあるんじゃないの？
あれ、なんらかの階層構造の機能を使って、増えた関数を整理するとかして
ないでしょ。
名前のつけ方を長くして階層的にしてるだけで。
- 971 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:24:30 ]
- あれはモード切り替えるから大丈夫なんじゃないか？
カレントディレクトリみたいなもんでしょ。
- 972 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:34:33 ]
- >>969
Common Lispには名前空間（パッケージ）やクラスがあるし、
Schemeにも処理系依存でそれらが存在する。
HaskellやMLにはもちろんあるでFA。
- 973 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 17:36:18 ]
- >>954
C言語はコンパイル単位というか、ファイルスコープやリンカが別になってて
元々環境が地続きではないから、そんなに困らなかったんじゃないかと。
干渉して困るのはプリプロセッサのマクロ定義をヘッダに置いた時とか。
- 974 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 18:59:09 ]
- Cは同じ名前の関数があったとしても型定義に違いがあれば誤用をある程度回避できるしな。
C++は多重定義を認めてるからそうはいかないけど。
それを考えると名前空間の採用はC++にとって必然だったんじゃないかね。
- 975 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:04:45 ]
- ス質急低
- 976 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:18:19 ]
- 一気に下がったな。氷点下。
- 977 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:26:23 ]
- >>975-976
>>775
- 978 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:30:29 ]
- それより、質の高い話ってなんだろう・・・
- 979 名前：デフォルトの名無しさん [2005/12/20(火) 19:32:45 ]
- ポインタの話から移ったと思えばむしろ質は向上しているよ
ついでにスレも物理的に上昇しておこうか
- 980 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:36:57 ]
- 関数の数を減らせれば、CAD方式でも何とかなるのでは？
という話になると思ってたのは漏れだけか？
CAD方式の話は見事に忘れ去られているようだが。
- 981 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:42:01 ]
- 950があまりにもとんちかんすぎただけだな。
- 982 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:51:26 ]
- スレタイからずいぶん距離のある議論になっているな
- 983 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:06:52 ]
- CAD方式のスクリプト、もしくは言語って、何がある？
- 984 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:07:44 ]
- CAD方式は機能が限定されているような狭い言語でないと、うまく行かないと
分かって来たからな。なので最近は（一部の研究を除いて）全く利用されていない。
- 985 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:17:47 ]
- LabViewがそうだったな。
漏れは使ったことないが、特定分野では成功してるみたいだよ。
www.asahi-net.or.jp/~WR9K-OOHS/Pages/Aboutlv/WWJ/WWJ03/wwj03.html
- 986 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:19:02 ]
- >>984
それって言い換えるなら、機能限定をうまく設定できればうまくいく、という事では？
ネームスペース以上に関数や変数等の摘要範囲を限定するような機能を設定できれば、
何とかなるのでは？
- 987 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:43:14 ]
- >>985
ほとんど電子回路だな。
漏れ的にはUMLのシーケンス図みたいなのを期待してたんだが……
CAD形式みたいなのは「作る人にとって」分かりやすい方式になりがちなのかな？
- 988 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:43:33 ]
- 「コンパイラ・スクリプトエンジン」相談室9
pc8.2ch.net/test/read.cgi/tech/1135082582/
- 989 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 07:04:47 ]
- CAD方式は言語というよりもツールになのでは？とか思ったが、
GUI形式の言語という見方をするならば、たしかに言語かもしれんな。
- 990 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 08:03:14 ]
- 複雑になっていくと、他の人や昔の自分が描いたソースを読めなくなりそうだ。
建築設計図ですら欠陥が見抜けないのに、ソフトウェアになったら…
- 991 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 08:52:00 ]
- いや、それはちゃんとコンポーネントを設計して、
ちゃんとコメントを残していけばいい話だろう。
テキスト形式の言語だって最初から完璧だったわけじゃない。
初期の言語で幾多の失敗を重ねたおかげで今の言語があるわけだ。
要はCAD方式言語は研究も経験も蓄積がなさすぎるだけ。
あと、俺らがすでにテキスト方式に慣れすぎてるというのもあると思う。
問題は、テキスト方式の蓄積を捨ててまで
CAD方式に乗り換えるメリットがあるかどうかだが…。
- 992 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 09:11:39 ]
- CAD形式を扱う場合のメリットは、UMLを扱う場合のメリットと同じかと。
図形にすると、処理の流れは分かりやすくなる。
しかし図形には、処理の論理が分かりにくいというデメリットもある。
- 993 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 09:39:02 ]
- UMLはUMLで、オブジェクト指向に関する政治的な駆け引きが色々と絡んで、
ややこしくなってる部分があるからなぁ……
その意味では、CAD形式言語に関しては、図形をいかに定義するかが焦点になりそうだな。
- 994 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 09:54:58 ]
- その場しのぎのやっつけ仕事の場合だと、
むしろCAD形式の方が楽かもしれんな。
世間の仕事の９割ぐらいは、やっつけ仕事だろ？
- 995 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 10:35:34 ]
- UMLはCAD形式の言語？
- 996 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 10:46:20 ]
- フローチャートもCAD方式の言語という事になるな
- 997 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 11:19:07 ]
- CAD型まではいかんが、MAX/MSPやPDは非テキスト型プログラミングの
試みとしては一番成功している部類だろう。
- 998 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 12:01:15 ]
- ﾏﾃﾏﾃ、CAD方式には致命的な欠点があるぞ。簡単にはコピペができんだろ。
特定のツールでしか作れないから、拡張も難しい。
- 999 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 12:47:21 ]
- むしろテキストを図形表示する方が色々と楽かもな。
- 1000 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 13:13:35 ]
- 普通に１０００ゲット
- 1001 名前：１００１ [Over 1000 Thread]
- このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
|
 |
