[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 10/05 19:36 / Filesize : 259 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

「コンパイラ・スクリプトエンジン」相談室8



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 あたり


823 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 02:53:00 ]
>>818ではないですが面白そうな話題ですね。

>クロージャの生成構文を別々に設けるということ?
エスケープ解析とか?

>おれの見解では(略
すまん、理解不能。
といってもクロージャ変換で実装したことしかない俺の知識が足りないだけ。
興味あるので「一般的」の参照をくれるとうれしい。

824 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 04:31:04 ]
>>803
○○○○○.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ 最初に支払ったお金30ドル

●●●◎◎.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ 3ドル返す 2ドルくすねる
└┼┘└┤└───────────┬─────────────┘
  │   │                   └ 主人の手元に25ドル
  │   └ ボーイの手元に2ドル             
  │
  └ お客の手元に3ドル

支払ったお金は27ドル
  9×3=27 9ドルずつを3人で払った
  30−3=27 30ドル払って3ドル返してもらった
  25+2=27  主人に25ドル、ボーイに2ドル払った

ボーイがくすねたお金2ドルは、客が支払ったお金(25+2)の一部
だから支払った27ドルにさらに2ドルを足すことが間違い(25+2+2・・・×)

最初の金額30ドルを求めるには、実際に支払ったお金27ドルに 戻ったお金3ドルを足さなければならない

825 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 04:51:17 ]
エスケープ解析というのを知らなかったのでぐぐってみたのですが、
関数等のスコープの中で定義した変数やクロージャの
利用がスコープの中だけで完結し、外には持ち出されないことを
調べるということでしょうか。

826 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 13:44:56 ]
そうです。

827 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 17:01:53 ]
>>783-784
おもしろい。長くてもいいからやってくれ。
くだらん短い書き込みより、長くてもおもしろいほうがいいや。
長いのがいやなら読まなきゃいいだけ。

>JavaはCが存在していて必要ならば使うことができることが前提だから
>比較的汎用指向の言語でありながら
>Cで書くことが適切であるようなハードウェアレベルの記述機能を
>潔くスッパリ切り捨てた設計ができている。

ここらへんはたぶん違ってて、Javaに低レベルの記述がないのは単にJavaがバイトコードインタプリタを採用したからであって、Cがあるから云々は関係ないと思う。
ポインタをなくしたのもGCを導入しやすくするためで、やっぱりCとは関係ない。


828 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 18:15:07 ]
>>827
そのへんは、鶏が先か卵が先かみたいなもんじゃね?


>>780
>人の認知科学的な処理特性を無視することはできない。
認知科学的には、冗長だとミスが増える法則もあるので
トレードオフだよね。

>ユーザが把握しやすい動作モデルを提供する
同じ物でも「把握しやすさ」はユーザによって
ばらつきが大きいんだよね。
ここを意識しないと宗教戦争になる。


829 名前:デフォルトの名無しさん [2005/12/15(木) 21:03:36 ]
>>827
ポインタはあるよ。
論文ばかり読んでる○○研究者か?

830 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 21:05:42 ]
>818
継続も使いたいから
>めんどいので全部ヒープに取ってGCまかせ
かね……

831 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 21:35:49 ]
>>823
>興味あるので「一般的」の参照をくれるとうれしい。

図にすると下みたいなイメージだけど、その辺は「クロージャ」が
出てくる速い処理系のソースかドキュメントでも読んでよ。
今の所これ以外に速い実装は思いつかないが。

※ |****| はフレームの変数とかの中身
※ (矢印)はフレームポインタ

スタック |******親1******|(←)|******親2******|(←)| ★クロージャ生成直前
ヒープ     ヒープはまだ空の状態

↓ ヒープに落としてフレーム参照を繋ぎかえる

スタック |     親1    |(↓)|     親2    |(↓)| ★クロージャ生成完了
ヒープ  |******親1******|(←)|******親2******|(←)|

エスケープ解析までするなら特定の親のみしかヒープのコピーは発生しない。
例えば親1のフレームしか参照しないのであれば親2のフレームは
そのままスタックに残しても良い。

スタック |     親1    |(↓)|*******親2*****|(←)| ★クロージャ生成完了
ヒープ  |******親1******|(←)| ←─── 生成されたクロージャは直接親1を参照




832 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 22:12:03 ]
>>829
参照のことをポインタだって言い張ってる人はいますね。

833 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 22:43:17 ]
Javaでポインタがあるっていう人間は低脳。バイトコードの仕様書読み直してから来い

834 名前:818 mailto:sage [2005/12/16(金) 01:44:55 ]
>>821
>>・基本はスタック上で、捕捉されたらヒープにコピー
>捕捉されたらとは?生成のこと?
「生成されたクロージャが、
 子孫のスタックフレームでないフレームに捕まえられたら。」かな。
例えばforeach的な関数にクロージャを渡してそのまま捨てるような状況なら
コピーは要らないわけです。
これをやると破壊的な処理がやたらと高くついたり、
いざコピーとなったときにやたらと高くついたり、
その他色々と面倒なことになったりしそうですが。

>>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
>クロージャの生成構文を別々に設けるということ?
コンパイル時に絶対にコピーが要らないとわかったときのみ、
フレームはスタック上に置いて、
それ以外は最初から親フレームはヒープに置いておこうと。
「関数aはクロージャを引数に取るが、それはどこにも保存されない」
ということになればa以外を呼ばない関数のフレームはスタック上に置いて良いでしょう。
が、やっぱり色々あって面倒なことになったりしそうです。

どっちもクロージャより親フレームが長生きなら問題ないよねという方針。

835 名前:デフォルトの名無しさん [2005/12/16(金) 18:53:57 ]
Javaでポインタが無いと信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。


836 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 19:38:44 ]
個人的な主観かもしれないけど、
ポインタ演算が無いものは参照と呼ばないか?


837 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:21:09 ]
例えば、Cのポインタをタンイポと呼ぶように2006年から改正したら、
2006年からポインタが無いことになるぞ。
ポインタだのタンイポだのと言われてることが全て。

838 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:41:20 ]
ポインタをタンイポと呼ぶためには法改正が必要なわけだが、2006年からというのは早急すぎるな。
まずは有識者を集めた小委員会の設置を図った上で、再来年以降の国会提出でも十分だと思う。

839 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:44:35 ]
配列のイテレーターと参照と参照ポインタとメモリアドレスのポインタとを
一括してポインタと呼ぶべきでない。


840 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:04:11 ]
>>835
Javaでポインタが有ると信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。

841 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:05:31 ]
え、ポインタと参照の違いは常識だと思ってたのですが。
またトンデモ本の誕生ですか。



842 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:01 ]
>>840
ほんたまですか?

843 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:22 ]
塗るタンイポえくせぷしょん

844 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:32 ]
懐かしい名前を出さないでください。せっかく忘れていたのに。

845 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:07:45 ]
Pascalのポインタは演算できないけどポインタと呼ぶな
だから正解は>>837

846 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:10:09 ]
でも一般的に見たら、参照とポインタの一般像みたいなもんはあるだろ。
Pascalは例外じゃないか?

847 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:12:33 ]
PascalはInc, Decができるじゃん。

848 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:12:34 ]
たしかにポインタの演算はできないけど数値にキャストできるから同じ事では。

849 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:21:12 ]
みんなそんなにボロカスに言うなよ。
Mさんが可哀想じゃないかw

850 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:22:33 ]
まあ少なくともJavaの参照はポインタではないことは確かだ。
名前が参照だから。

851 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:35:58 ]
そんなの実際どうとかじゃなくて、
設計者がどう定義したかと、その思想によるだろう。
だから>>850が正しい。



852 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:41:17 ]
名前はともかくとしても、実際の内容を素直に受け止めれば
いいと思うけど。なので >>835 が正解。

853 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:42:47 ]
>>835とか>>852は、ポインタと読んでCのポインタを連想した上で書いてるわけっしょ?
だったらやはりCの言葉の定義に(ry

854 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:44:40 ]
実際の所、Rubyにはポインタは存在するがLispには存在しない。


855 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:46:11 ]
>>853 ポインタという言葉の定義or使用はCが最初ですか?


856 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:48:01 ]
RubyもLispもPascalも、同じ太陽を感じ、同じ月を見て. 同じ空気を吸っているのだから
ポインタの有無くらいで区別するのはよくないと思います。

857 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:50:26 ]
しかし、ポインタの有無は実用性を大きく左右するんだよ。

858 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:51:20 ]
うむ。

859 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:52:51 ]
結局は宗教論争。
和平への道はアセンブラ原理主義しかない。

860 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:53:34 ]
>>855
ALGOL60にPOINTERという型は既に存在したらしいぞ
ttp://www.99-bottles-of-beer.net/language-algol-60-24.html


861 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:55:01 ]
Java ポインタ の検索結果 約 197,000 件中 1 - 10 件目 (0.03 秒)
www.google.co.jp/search?hl=ja&q=Java+%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF&lr=
Java 参照 の検索結果 約 2,830,000 件中 1 - 10 件目 (0.24 秒)
www.google.co.jp/search?hl=ja&q=Java+%E5%8F%82%E7%85%A7&lr=

この様にJavaポインタ派は、Java参照派と比較するとごく少数です。
どうやら集団で勘違いされているみたいです。


>>856
Rubyにはポインタはありません。
ポインタに相当する機能は持ってますが、
それはポインタではありません。



862 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:58:05 ]
実にくだらない話題に収束したな。

863 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:29:43 ]
ポインタ演算とか、インクリメントとかデクリメントとか、数値へのキャストとかそういうのを
わざと制限したものは普通、ポインタじゃなくて参照って言わない?

864 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:33:18 ]
>>857
同意。ポインタのある言語は領域破壊のバグが頻繁に紛れ込むが、
Javaのようにポインタのない言語はそうしたバグは非常に少なくなる。

865 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:33:48 ]
いわないね。
Delphiだと明確に区別されてるし。

866 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:34:56 ]
>>865
Delphiは言うじゃん。参照って。

867 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:37:26 ]
つまり、865は「ポインタとは言わない」と言いたいちゃうんかと。

868 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:40:25 ]
あぁ、863へのレスのつもりなのね。

869 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:52:19 ]
>>857
つまりLispは実用的でない証明ってこと言いたいわけ?w

870 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:05:20 ]
lispにポインタはありません。ポインタの無い言語は実用性で勝ります。864を参照。

871 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:10:12 ]
Cにはポインタがあります。ポインタのある言語は自由度と汎用性で勝ります。864参照。



872 名前:デフォルトの名無しさん [2005/12/17(土) 00:10:39 ]
Lispにポインタはあるが、そういえば、Lispのポインタって完全にJava、Rubyなどで言う参照だよな。
結局その言語でそれをなんと呼ぶかってことだな。

873 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:11:26 ]
>>871
確かにバグを出す自由度で勝りますねw

874 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:19:31 ]
ようやくLispが出てきたか

やっぱこのスレの主役はLispだよな!

875 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:20:01 ]
Lispこそがすべての源流であるということは認めざるを得ない。

876 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:23:32 ]
そもそも「Javaでポインタ」って話は、C++使いにJavaの参照を教えるときに「C++の参照と違ってポインタみたいなもんですよ」って説明するだけの話じゃなかったっけ?
それ以外の時に普通Javaの参照はポインタとは言わない罠。
まあ「何かを指し示す」って意味に限定すればJavaの参照とCのポインタは一緒だから「存在しない」とまでは言う気ないけど。
ポインタ演算ができるかどうかなんてポインタの本質じゃないでしょ。

877 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:25:38 ]
>>876
一般に参照とポインタの区別を云々する場合、ポインタ演算の有無こそが本質のうちの1つです。

878 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:26:56 ]
>>877
そうなの?ポインタキボンヌ。

879 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:27:45 ]
ポインタ演算があるのと無いのとではバグの量と種類に大きな違いが出るのだよ。

880 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:29:26 ]
Cのポインタは、演算によって「値をずらす」ことができるだろ。

int a;
int *p = a;

p += 1; //←これ


参照はそれができない。


881 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:30:15 ]
それはポインタ演算の有無の話であってポインタの有無の話ではないですね



882 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:31:08 ]
間違った。

int a;
int *p = &a; //アドレスを代入

p += 1; //←これ

*p = 1; // 任意のアドレスのデータを破壊

参照はこれができない。


883 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:32:00 ]
ポインタの有無の話ですよ。今や、それが出来ないものをポインタではなく参照とよぶことが多いんですから。

884 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:32:51 ]
ポインタは任意のハードウェア例外を引き起こす。

*(int *)(0) = 0; // 不正なアドレスへの書込み



参照ではこれはできない。

885 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:33:23 ]
これぐらいか?

●同じ点
Javaの参照もCのポインタも、どちらも間接参照を表すためのものである。

●異なる点
Javaの参照はヒープ上にあるオブジェクトしか指す事ができない。
Cのポインタはどこにあるオブジェクトも参照できる。

Javaで参照されているオブジェクトは決して消滅しない。
Cで指されているオブジェクトはいつの間にか消滅している可能性がある。
(そして、消滅したオブジェクトへの参照をたどった場合の動作は未定義である)

Javaの参照にはCのポインタ演算のような機能はない。
Cのポインタ演算は、配列の要素を指すポインタのみに使う事ができる。
それ以外の場合の動作は未定義である。

Javaの参照の動作はかなり厳密に定義されている。
Cのポインタに対する操作には「未定義である」という部分が多い。
それを利用して環境依存の色々な技が使えたりする。

886 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:34:20 ]
Cのポインタが安全性を保証してないだけの話じゃん

887 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:35:50 ]
クロージャの話しようぜ

888 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:37:11 ]
>>887
まずクロージャを定義してださい。

889 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:38:20 ]
ポインタは本来、「何かを指し示すもの」という意味でした。
この言葉は、アドレスやそれを格納した変数などにたいして用いられてきました。

しかし、時代が移り変わるにつれ、ポインタ演算によって、頻繁に深刻なバグが
発生することがわかってきました。ポインタ演算の有無が非常に重要だという
ことがわかってきたのです。

かくして、本来は本質でなかったポインタ演算の有無が、時代とともに重要視
され、ポインタの本来の意味が変わってきたわけです。

890 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:38:34 ]
ださいとかいうなや

891 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:42:25 ]
ポインタ演算を適用できる変数やアドレスの数値と、参照との区別を明確にするため、
前者のことを特にポインタと呼ぶようになったのです。
特に言語として、Cがダントツで有名になったこともこの背景にあります。



892 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:05:55 ]
・ポインタ演算を元に考えればJavaやその他の言語にポインタはない。
・そうでなければいわゆる参照(C++の参照を除く)はポインタみたいなもん。
ってことでFA?

893 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:12:47 ]
代入なんかをインスタンス化してしまう言語にはポインタがない、参照切れもない。

894 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:16:58 ]
>>892
あと、
・その言語がポインタと呼んでいないものは、その言語ではポインタではない。

895 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:18:08 ]
>>893
ポインタ演算ができないからでしょ。

>>894
そんなこと言ったらJavaScriptにはクロージャはないってことになるじゃん。

896 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:21:50 ]
いろんな言語のポインタ、いろんな言語やハードのアドレスは、それぞれ別のものを
別々に定義可能。
それらの用語の使い方は仕様によって異なる。
時々これらを混同して、「アドレスはポインタか?」とかの議論で、おかしな議論を
展開しちゃってる人がいるけど。

897 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:23:05 ]
>>895
クロージャを他の機能で代替してるだけなら、
厳密な意味ではクロージャはないんじゃないの?

898 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:25:39 ]
ECMAScriptの仕様書のP144にクロージャ出てきますが何か?

899 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:25:40 ]
厳密な意味ならね。

900 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:26:56 ]
>>896
禿同。
このスレは変な議論で盛り上がるよなw

901 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:26:57 ]
その言語がそれをクロージャと呼んでいないなら、クロージャじゃない。



902 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:29:06 ]
>>898訂正
×P144
○P132

903 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:32:05 ]
ああ、Cのポインタは実装によってマシンのアドレスと違うことがあるから、
アドレスはポインタではないとかいっちゃってる人いますね。
Cのアドレスとマシンのアドレスを混同しちゃってる例ですかね。

904 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:46:37 ]
要はどっちでもいいだろって話でしょ。
Javaの言語仕様に関する議論で「ポインタは〜」とか言ってたら指摘すべきだが、>>876みたいな文脈で「ポインタみたいなもん」って言ってるだけでつっこむとしたら揚げ足取り以外の何物でもない。

905 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:51:38 ]
ポインタをマシン語のアドレスと思ってあつかうと
マルチコア、マルチタスク、マルチキャッシュなCPUでは
競合が発生して、かなりわけわからんことになる昨今。

906 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:53:11 ]
>>888
では混乱を無くすために
クロージャ=Schemeのクロージャ(あるいはラムダ式、無名関数)
と定義するよん。他の言語も右に倣えだから意味論はほとんど同じ。

例えばクロージャのある言語ではnewのような特別な構文を
定義することなくオブジェクトの生成を記述できる。

(define new-point
 (lambda (x y) ;---メンバ変数に相当、隠蔽される
  (lambda (message . args) ;---this、selfに相当
   (case message
    ((getx) x) ;--- getter
    ((gety) y)
    ((setx) (set! x (car args)) x) ;--- setter
    ((sety) (set! y (car args)) y)
    (else (error "unknown method " message))))))

実際にやっていることはクロージャを生成するクロージャを
定義しただけ。それでも以下の様にオブジェクトとして扱える。

(define point (new-point 1 2))
;メンバ変数はどうやってもアクセサ経由でしか参照できない
(point 'getx) ;=>1
(point 'gety) ;=>2
(point 'setx 3)
(point 'getx) ;=>3


907 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:58:41 ]
燃料投下

Javaでは、NullPointerExceptionっていう言語定義された例外が存在するんですがwwwww

908 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:59:53 ]
NullPointerExceptionを考えた馬鹿を吊るし上げればいいだけだお^^

909 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:01:45 ]
>>906
なるほど
JavaScriptやlua、perlもそれと同じだね。

910 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:04:49 ]
>>907
Javaにポインタがあるとか言ってる奴の主張はそれじゃなくて
参照のことだろ。

911 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:08:44 ]
ttp://nantan.xrea.jp/tag/Java
「ポインタ(pointer)」と「参照(reference)」とは、同じようで微妙に異なる。
簡単にいうと、「参照」はデータを間接的に参照することで、「ポインタ」は
その実現方法。つまり「参照」は仕様であり、「ポインタ」は実装である。
よく「Javaにはポインタがない」「いや、Javaの参照変数はポインタ
そのものだから、Javaにもポインタがある」という論争があるけど、
前者は「Javaの言語仕様にはポインタがない」ことを後者は「Javaの
実装にはポインタが使われている」ことをそれぞれ言っている。
つまり話の焦点がずれているため、両者の議論はかみ合うはずがない。
ただまあ、「NullPointerException」という名前はよくなかったな





912 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:11:13 ]
もし NullPointerException を改名するとしたら何にするのがよい?

913 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:12:26 ]
NullpoException

914 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:14:25 ]
CantDereferenceException

915 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:31:26 ]
燃料の質が悪かったか。精進します。

916 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:36:52 ]
NullReferenceException

www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemnullreferenceexceptionclasstopic.asp

917 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 03:54:34 ]
で、そのポインタ論争がこのスレと何の関係があるんですか
マ板のぬるぽスレでも行って騒いでなさい

918 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 03:56:44 ]
ポインタについては、このスレで議論することですか?

919 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:44:46 ]
このスレで議論することは何ですか?

920 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:49:30 ]
質(略)

921 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:50:09 ]
次スレの準備かな。



922 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:51:33 ]
まだ早いよ

923 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:53:08 ]
元々クロージャの話だったからそれをギロンすればいい

924 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 06:00:54 ]
じゃ、まずはおまいからギロンを始めてくれ。

925 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 10:10:43 ]
ぎろーん

926 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 10:47:16 ]
ポインタなどという用語を不用意に使うような糞言語は捨てですね
何も反省していないということがわかる

やっぱりLISPですね

927 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 11:01:35 ]
昔の言語だったらしょうがないけど、今時ポインタという用語使う言語の方が珍しい。

928 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 12:15:13 ]
>>911
>「ポインタ」は実装である。
これの一次情報ってどこなんだろう?
少なくともCの仕様書ではそうなってない。
言語はC言語で実装することが多いので、
参照を表すのにポインタが直接使えるだの使えないだのという話はするけど。


929 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 13:02:20 ]
ポインタはCでは仕様、Javaでは実装ってことじゃね?

930 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 18:08:17 ]
>>926
Emacs Lispのリファレンスマニュアルだと、全編を通じて
「ポインタ」という用語を使っているわけだが w

www.fan.gr.jp/~ring/doc/elisp-manual/elisp_81.html#SEC82

931 名前:930 mailto:sage [2005/12/17(土) 18:14:58 ]
ごめん、URLはこっちとかの方が適切だね。
www.fan.gr.jp/~ring/doc/elisp-manual/elisp_84.html#SEC85




932 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 19:30:44 ]
まあcより古い言語なんだし、その辺は仕方ないんじゃない?
lispのポインタは今でいう参照だな。

933 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 21:10:48 ]
だから、lispはポインタ無いって何度いえば(ry

934 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 21:23:52 ]
もういいよ、その話題は。

935 名前:デフォルトの名無しさん mailto:sage [2005/12/18(日) 00:32:13 ]
だから、rubyはポインタ(ry

936 名前:デフォルトの名無しさん mailto:sage [2005/12/18(日) 00:52:22 ]
さて、そろそろ次スレの準備かな。
立てたい奴、テンプレのリンク切れてるのチェックしてきてくれよ。

937 名前:デフォルトの名無しさん mailto:sage [2005/12/18(日) 07:04:06 ]
4年前の発掘
pc.2ch.net/tech/kako/1004/10048/1004873294.html

938 名前:デフォルトの名無しさん [2005/12/18(日) 23:03:22 ]
コンパイラ作る人は、「デバッガ」を、どのくらい「親切モード」に
搭載しているんだろう。手取り足取りでは作る手間かかりすぎるし、素っ気
なさ過ぎると、それはそれで文句言う奴も出てくるはず。

939 名前:デフォルトの名無しさん [2005/12/19(月) 18:04:56 ]
コンパイラヤサンは、でばっがやさんとは捌


940 名前:デフォルトの名無しさん mailto:sage [2005/12/19(月) 22:11:29 ]
938が誰に何を聞きたいんだかさっぱりわからんのだが。
(VC++とかgccとかの)広く使われている処理系について、どのくらい親切な
デバッガが搭載されてるか、なんてことなら、938の使ってる処理系についてなら、
938自身がよく知ってることだろう。

そうじゃなくて、
「コンパイラを作るとき、デバッガをどの程度意識して作るものなのか。
 コンパイラ屋さんはたいして意識せず、デバッガ屋さんががんばるものなのか、
 それともコンパイラ作る段階で相当意識するものなのか。」

という疑問であるとか、

「なあみんな、処理系作るときどれくらいデバッガ意識してる?」

という問いかけであるのならわかるんだけど。


941 名前:デフォルトの名無しさん mailto:sage [2005/12/19(月) 23:56:40 ]
SmalltalkやObjectCの話を聞いたときには、「そのうちプログラムも部品化・汎用化されて
CADのように配置して、入出力を線で結んで作るようになるんだろうなぁ」とか
思ったんですが、
なんでエディタで変数名をマウスで触ると宣言が出てきたりとか、コード補完してくれるとか
そっちへ行ってしまったのだろうか。
キーボードの呪い?




942 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:08:13 ]
>>941
CAD方式のほうがめんどくさいことがわかったからだ

943 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 01:30:21 ]
>>941
VisualAge for JavaってのがIBMから出ててな、結構やすいからまだ手に入るなら試してみな。
そうすりゃどのくらい便利でどっからあたりでマンドクサイかよ〜くわかるから。

944 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 01:57:01 ]
graphical だと patch 作るの面倒そう。

945 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:08:54 ]
>>944
そうでもないよ
画面からテキストへの写像でしかないから
UNIXから来た人は想像できなくて誤解も多いだろうけど

946 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:28:49 ]
ん、一旦テキストに落とすの?

947 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:57:44 ]
LispやSmalltalk界隈では普通に行われてるけど
他の言語では一般的にマーシャリングとかシリアライズと言われている機能かな
データ記述能力の低い言語ではXMLとかの別の構造に記録したりする

948 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 03:16:07 ]
>>943
シンセのエミュで、フィルタとかを結線するのは見たことがある

949 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 03:18:14 ]
SchemeやHaskellの話を聞いたときには、「そのうちプログラムも関数になって
参照透明に設計して、引数と返り値のやりとりだけで作るようになるんだろうなぁ」とか
思ったんですが、
なんでCの拡張のC++とか、Cの改良のJavaとかそっちへ行ってしまったのだろうか。
手続き型の呪い?

と同種の悩みなんだろうか。

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は、関数が増え続けないように歯止めをかける事が可能な言語かと。w
まあ、その機能を有効活用している例は少ないようだが。ww


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 ]
つまり、関数が増えるからどうのというのはmとんでもない勘違いで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形式の方が楽かもしれんな。
世間の仕事の9割ぐらいは、やっつけ仕事だろ?


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 ]
普通に1000ゲット

1001 名前:1001 [Over 1000 Thread]
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。








[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<259KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef