[表示 : 全て 最新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 あたり


129 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 18:14:01 ]
XMLなんて馬鹿の思いつきだよ。
する〜よろ>>ALL

ところで、俺言語いいじゃないか。
どんどん語ってくれ!


130 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 18:24:45 ]
>>129
そういう根拠を述べない決め付けはよくないな。
技術者ならば各手法の選択に当たって目的に対する得失を比較せねばな。

>>127>>125でも述べた通り、
XMLを使ったほうが開発・維持の手間が減らせる場合は確かにある。
逆に使わないほうがいい場合もある。万能な方法はない。

131 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 18:42:53 ]
データ構造を記述するだけの場合にはXMLは非常に優れた能力を持つよね。
でもプログラムを記述する場合にXMLを使う例は今のところあまりないと思う。
JavaMLなんてものもあるけれど、あれは構文木をXMLにしただけだし(うろ覚え)。

132 名前:108 [2005/11/08(火) 18:48:24 ]
んー。XMLでもできそうな気がしてきた。VB使う限りはXML使うのが楽っぽい。
VBはもう終っちゃう言語だろうけどさ、、、
一応XML使ってみるよ。条件分岐が少し多いだけで、多分、そんなに複雑にはなら
ないから多分大丈夫かと。




133 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 18:57:28 ]
>>131
代入や演算、一般的な条件分岐などで
データ・フローやコントロール・フローが複雑になると
XMLではおそらく読みにくくなる。
データ構造記述は比較的それらが単純で局所的な要素が多いからな。

ANTなんかはタスクの依存関係を記述してプログラムのビルドやセットアップを行う
スクリプト的側面を持つが、処理のパターンが依存関係とコマンドというように定型的で
宣言的だからXMLでも比較的追いやすい。

もう一つの基準はスクリプトや設定ファイルの処理で
ツリー構造を作るところまでの仕事が占める割合だな。
データ構造記述の場合パースしてツリーができればかなりがとこ仕事は終わっている。
タスクの依存関係を記述するANTの場合も然り。
けれど代入や分岐などを認め複雑なデータフローや
コントロールフローなどを処理する必要が生じるとツリーを作った後が中心になってくる。
XMLパーサを使うことでコストが減るのはパースする部分までだから、
ツリーなどのデータ構造を作った後の処理の比重が重いと旨みは減る。

134 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 19:04:01 ]
もう一つXML使ってメリットがありうるのはスクリプト自身を処理する
スクリプトを書くなどメタな処理をする場合だな。
スクリプト自身をデータとして処理する予定がある場合や、
XPathなどを駆使してXMLファイル内にXMLファイルの構造を辿るような記述を埋め込む場合だ。
XSLやXML Schemaなどはこのような例だな。

135 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 19:18:46 ]
XSLTはかなり良く設計されていると思う。XML Schemaはノーコメント。

あと、企業独自言語で、XML内にスクリプトを埋め込むというのを何度か見た。
SVGとかも確か、スクリプト(ECMAScript?)をエレメントの中に記述したよね。
よく考えれば、SVGをいうまでもなくXHTMLもそうか。

136 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 19:37:30 ]
>>128
うへえ。
いろんな意味でLISPのS式の方がいいじゃん。

137 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 19:48:04 ]
みんな! 136がVB用のLispパーサを書いてくれるそうですよ!



138 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 19:48:36 ]
>>136 ログ嫁

139 名前:デフォルトの名無しさん [2005/11/08(火) 19:52:00 ]
ばかかお前ら?
XMLのコンテンツとして、文をいれる訳???
まだ、*ispの方が遥かにいいよw


140 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 19:53:13 ]
ん、配列扱える言語なら基本的なLISPぐらい書けるでしょ。
VB使う機会があったら書いてみるよ。

141 名前:デフォルトの名無しさん [2005/11/08(火) 20:07:38 ]
いや、、お前らよく考えろ。XMLなんて素人に書けないぞ。結局XMLを生成する
アプリ作る必要が出てくるに違いない。いや、中間言語としてXMLを使うのは
悪くは無いかもしれんが、、、

142 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 20:14:25 ]
>>141
その通りだが、Lispもそうなんだよな。デザイナーが書ける言語って何だろう。

143 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 20:17:42 ]
デザイナーとプログラマーのプログラミングに対する意識は人それぞれといえまったく違うみたいだしなぁ

144 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 20:36:48 ]
設定ファイル解釈系相談室、の方が実態に即してるんじゃないか、このスレ。

145 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 20:58:04 ]
>>142
素人受けして、文法に柔軟性がある言語があるが、
あえて名前は書かないw


146 名前:デフォルトの名無しさん [2005/11/08(火) 21:10:57 ]
>>145
ほほぅ、、もしかして「日本語」か?


147 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 21:12:48 ]
>>145
詳しく




148 名前:145 [2005/11/08(火) 21:13:20 ]
>>146
その通りw


149 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 21:45:40 ]
りんごタソは、やまとなでしこ。

150 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 21:51:52 ]
>>142
素朴な疑問だが、どこから「デザイナー」が出てきたんだ?

設定ファイルにLispというと、.emacs.elの感覚かねえ…
素人にはお勧めできないわな、そりゃ。


151 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 22:17:56 ]
>>150
あ、ごめん、俺は昔デザイナーがカスタムタグベースのJSPを書けなくて
ショックを受けて、プログラムをする必要のある素人といえばデザイナーが
脊髄反射で出てきてしまった…

152 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 22:43:01 ]
>>108&113
ここでこういうレスを入れるの自体スレ違いかもしれないけど、iniファイルじゃ
駄目なの?制御構文が絡まなければ別段パーサなんて作る必要性感じないんだけど

153 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 22:51:32 ]
>>101
>うちの言語では、ネイティブ側で確保したオブジェクトへのポインタ型に
>ファイナライザを付けられるようにしてる。それ以外のオブジェクトにはなし。

成程成程、自分の場合作っているのがECMAScriptのスーパーセットなもので
その辺はファイナライザを指す特定のシンボルを動的検索です、ちょっとオーバー
ヘッドが気になるのだけど致し方無しという所です。

>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?

うちの場合も構文木でスタックは持ってないんだけど、要はオブジェクトリスト
を管理している所を2本化してチェック走らせれば良いのでは、と理解しました。

# ちなみに構文木辿っている途中の中間計算で使用されているオブジェクトは
リファレンスカウンタ介してGC時に除外する方式取ってます、ちょっとオーバーヘッド
あるけど。

154 名前:デフォルトの名無しさん mailto:sage [2005/11/08(火) 23:30:51 ]
デザイナー自体は>>91で出てるね。

デザイナーが書ける(こともある)プログラミング言語というと、
やっぱりFlashのActionScriptじゃないかな。


155 名前:14 mailto:sage [2005/11/09(水) 00:15:53 ]
>>153
うーんと。
ファイナライザがあるとGCが厄介だ、というのは、ファイナライザの中で
thisをグローバル変数か何かに放り込まれると、オブジェクトが「復活」する
からだよね?
んで、復活するのは、ファイナライザを呼ぶオブジェクトそのものだけでなく、
そのオブジェクトから辿れるオブジェクトすべてだから、
>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?
と書いたわけだけど。ただ、今読み返すと、>>56氏も>>58氏も、そんなことは
当然として書いてるように思える。恥さらしましたかね。

ちなみに.NET FrameworkのGCについて以下のページに説明があって、

www.microsoft.com/japan/msdn/net/mag00/GCI.asp

下の方に、ファイナライザを含むオブジェクトのGCの話も書いてある。
でも、俺にゃ「完結キュー」がなぜ必要かわからないし(オブジェクトごとの
フラグじゃいかんの?)、復活の話も書いてあるけど、.NETのGCがどう対処してる
のかもよくわからない… 俺がアホなのか。


156 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 10:53:26 ]
>>141
素人さんにはXMLに限らずどんな形式言語でも書けない。
だからユーザとして想定する相手の技術レベルよっては
どのみち設定ウィザードみたいなものは必要。

157 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 11:02:10 ]
>>152
どっちみち.iniファイルの中の仕様を決めねばなるまい、
あれだって単純とはいえ一応形式言語だぞ?

それと>>124を見る限り、
>>108は簡単な設定ファイル内で簡単な条件判定くらいはするつもりらしい。



158 名前:108 [2005/11/09(水) 12:19:08 ]
ん。そうです。設定ファイルというと語弊があったかも、、、実際には
現場の人に計算式を入れて貰うわけです。パラメータにAがあったらこういう計算、
パラメータにBがあったらこういう計算。寸法がある範囲内ならこういう計算、
みたいに計算式と条件を書いて貰おうと。

この条件の部分が後からどうなるか分からないので、比較的自由に条件が設定できる
ようにしたいわけです。

とりあえずLL(1)で書いてみたけど、ちょっと気持ち悪いです、、、
getcharのかわりにmid関数とか使ってるんだけど、こんなんでいいの?



159 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 12:34:49 ]
条件式はかなり複雑なものになりえる?
計算式もスクリプトが計算するのか?
その辺がYesならまぁXMLは向かない可能性が大なので忘れてくれ。

>>135
XMLに別言語のスクリプトを埋め込むのはまぁあんまりオススメはしない。
特に埋め込む言語が広く使われている既存の言語ではないとか、
XMLのフォーマットが既にある程度普及してる訳ではない場合とか、
スクリプトが断片的でXMLの記述と絡み合い、
それ自身では完結しない場合とか。
いずれも処理が煩雑になり理解もしにくいものになるからな。

まぁHTMLにJava Script(ECMA Script)埋め込んでそれなりに動いてる
って前例があるからやりたくなるんだろうが…。
あれはHTMLが爆発的に普及してその拡張手段が必要となって
止む無くやってるわけで最初から目指すものではない気がする。

まぁTeXとPascalコードを融合してアルゴリズムの文書的記述と
プログラムを融合したweb(Knuthの提唱する文芸的プログラミング)
という試みもあってそういうのは面白いかも試練が、
あの場合はドキュメント+実行可能サンプルって意味合いが強く
コードとドキュメントにキレイに分離できて、
分離後は別々に処理できたから問題なかった。

160 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 13:53:46 ]
昔、INIファイルのままでTinyBASICもどきを作ろうとしたことがあった
(実行環境に応じて設定が動的に変わるように)
[MAIN]
VAR=グローバル変数
100=A=0
110=FOR I=0 TO 10: PRINT I;: NEXT I
120=GOSUB MOKEKE
130=END
[MOKEKE]
100=VAR=$SCREENWIDTH
110 RETURN

とか
仕様考えているうちにダルくなってそれっきり。
やっぱGOSUBは!=じゃなきゃだめとか(ぉぃ

161 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 14:56:17 ]
>>158
やはり、という気がするのだけれど、それを設定ファイルと呼ぶのは、
問題に対する誤解を生むだけの間違いのような。
条件はともかく計算式を「現場の人に書かせる」のが必然かどうか知らんが、
入力の妥当性検査やエラー含めて、どの程度の記述能力が必要なのか、
確定しているのかな? 下手すれば(少なくともUI的には)
本体の処理内容自体よりよほど重要なわけで、それが
>この条件の部分が後からどうなるか分からないので、
というのは、設計以前の問題把握/認識として大丈夫かな、と……


162 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 16:01:36 ]
58です。
>>155
CLRの図で行くとFリーチャブルキューが生成された時点ではまだヒープに
オブジェクトは残っていて、1回のGCサイクルが

1) 完結キューに無く、かつFリーチャブルキューにのオブジェクトをヒープから削除
2) 完結キューに存在するオブジェクトの参照をFリーチャブルキューに移動
(この時点ではオブジェクトは残っている)

2')非同期でファイナライザ実行スレッドが走る

なので次の実行時に復活されているオブジェクトはそのまま残るのでは?
56の話も1GCサイクルは

1) ファイナライザを持っていてファイナライズされていないオブジェクトはリストへ、
それ以外の未使用オブジェクトは削除
2) ファイナライズリストにあるオブジェクトはファイナライズ実行

なので次の呼び出しで復活している場合は1で参照されているので復活は処理できるのでは
ないかと思ってるんですが、何か抜けてる?

完結キューの話はその方がクラスのメモリ上のレイアウトがすっきりするし、CLRの
場合クラス設計は静的だからオブジェクト作成時にファイナライザがあるかどうかは
はっきりしているので、実装によってはそういう方法もあるかな、位に考えてました
が、、、抜けてるかな

163 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 16:06:27 ]
間違い)
1) 完結キューに無く、かつFリーチャブルキューにないオブジェクトをヒープから削除

164 名前:108 [2005/11/09(水) 16:08:50 ]
>>159
ありがとうございます。とりあえず、XMLは勉強不足なので、今後の課題に
したいと思います。

>>161
すみません。設定ファイルと言うと誤解されても仕方ないですね。
条件が後からどうなるか分からないというのは、
現状なら大丈夫だけど、今後、外的要因で変わる可能性もあるっつーこと
です。



165 名前:デフォルトの名無しさん mailto:??? [2005/11/09(水) 16:11:02 ]
C言語の学習および開発をしたいのですが、visual C++.netよりも
いいものってあるでしょうか?

166 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 16:14:10 ]
GCC

167 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 16:28:06 ]
ICC



168 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 16:29:52 ]
>>165
学習と開発を一緒にしないでください。

169 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 16:31:57 ]
>>164
>条件が後からどうなるか分からないというのは、
>現状なら大丈夫だけど、今後、外的要因で変わる可能性もあるっつーこと
いや、当然せめてそのレベルにないと話にならないわけで……
その可能性等、未確定要素でもある程度認識しておかないと、
>比較的自由に条件が設定できるようにしたいわけです。
たって、なんでもできる万能言語を作る能力にめぐまれるわけでも無く、
記述能力の水準やら(言語の)設計方針もきまらないんじゃ? と、
心配するわけです。(だから軽く設定ファイル、なんて言っちゃうのかなと)

170 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 16:41:26 ]
>>165
TinyCCが良い、コンパクトなのでソースも読み易いぞ

171 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 17:01:00 ]
>>168
まぁしかし広義には人生これ全て学習じゃよw
開発も人生の一部であるからにはまた然りじゃろて。

172 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 19:22:08 ]
開発が人生のすべてで、他はオマケという人もいる罠。w

173 名前:14 mailto:sage [2005/11/09(水) 20:27:28 ]
>>162
>1) ファイナライザを持っていてファイナライズされていないオブジェクトはリストへ、
>それ以外の未使用オブジェクトは削除
>2) ファイナライズリストにあるオブジェクトはファイナライズ実行

単純なmark sweep GCを考えると、この1)のフェーズの前にmark phaseがはいってて、
1)はsweepと同時にやるようなイメージなんですが、ここまでの認識は合っているでしょうか?
ファイナライズされるオブジェクトをAとすると、Aは定義からしてマークされていないはずで、
当然、Aが参照しているオブジェクト(Bとします)もマークされていないはずです。
この状態でsweepすると、Bはなくなってしまうわけですが(Bにはファイナライザはついて
ないものとして)、Aが復活したら、Bも一緒に復活しなければなりません。
だから、
>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?
と書いたわけで。

もちろん、mark phaseにて、ファイナライザ持ったオブジェクトは最初から
すべてmark対象にしてもいいわけで、そう考えると.NETの完結キューも
意味があるのかな、とこれは今思った。完結キューもルーツに含めればよいわけで。

174 名前:デフォルトの名無しさん [2005/11/09(水) 20:39:13 ]
なんか、俺様言語のオンパレードだなw

プログラミング言語 俺様 改訂2版


175 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 22:14:28 ]
>>171 >>172 >>174 あたりがウザイ。せめてアボーンできるようにコテハンつけてくない?


176 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 22:15:21 ]
>>173
指摘thanx、見落としてました。という事は

1) 通常通り変数,Fリーチャブルキューから参照されているものをmark
2) 1でmarkされなかったファイナライザ付きオブジェクトを
ファイナライズリスト/Fリーチャブルキューに登録し、そのオブジェクトを起点にmark
3) sweep
4) ファイナライザ実行

でどう?


177 名前:108 [2005/11/09(水) 22:20:08 ]
>>169
多分,
>比較的自由に条件が設定できる
という部分が誤解を招いたかと。すみません。

条件の部分はあらかじめ組み込み関数を用意する予定です。
現場の人にはそれらと論理演算記号とを組み合わせて条件を書いてもらいます。
今後何かあっても変更になるのは条件の部分だけなので,変更があったら,
組み込み関数を都度追加すればよいだけなんで。

正直,これ,条件分岐と,四則演算さえできればいいんです。
言語というほどのものではなく,eval関数に毛が生えたみたいなもんだと
思っていただければ・・・・そもそもあまり難しくすると現場の人書けない
ですから。

というわけで,大体できました。皆さんありがとうです!



178 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 22:23:38 ]
あれ? ファイナライザでオブジェクトが復活するかどうかって、コンパイル時に決定できる?

179 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 22:24:55 ]
復活するかどうかは普通は決定できない、持っているかどうかは決定できるという話じゃない?

180 名前:178 mailto:sage [2005/11/09(水) 22:27:18 ]
ごめん。思いつきで書いたけど良く考えなくても決定できそうにない (;´Д`)

181 名前:デフォルトの名無しさん [2005/11/09(水) 22:45:29 ]
>>175
おまえがいちばん鵜剤w

182 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 23:11:24 ]
>>177
文法がある以上、言語だと思うけど。
多分DB絡んでる?違うかな。。。

183 名前:デフォルトの名無しさん mailto:sage [2005/11/09(水) 23:52:02 ]
>>175
ウザイらしいぞw

184 名前:デフォルトの名無しさん mailto:sage [2005/11/10(木) 01:32:53 ]
10 omaira
20 nanigeni LV
30 taka sugi


185 名前:デフォルトの名無しさん mailto:sage [2005/11/10(木) 22:12:06 ]
構文解析って、もう研究するところないんですかね?
ちょっとそんなこと聞いたもので。。。

#もちろん、皆無っていう意味でなくって、
#大きなテーマが無く、あとは重箱の(ry

186 名前:デフォルトの名無しさん mailto:sage [2005/11/10(木) 23:04:46 ]
構文解析に限らず,新たなパラダイムが無いと難しいんじゃないの?この
分野。自然言語処理ならともかく,プログラミング言語って話だと。。。

187 名前:デフォルトの名無しさん mailto:sage [2005/11/10(木) 23:18:01 ]
>>185-186
禁句w



188 名前:デフォルトの名無しさん mailto:sage [2005/11/10(木) 23:24:34 ]
そこで日本語プログラミング言語ですよ

189 名前:デフォルトの名無しさん mailto:sage [2005/11/10(木) 23:36:38 ]
>>188
ぴゅう太やら、年刊Ah!SKI第1号以来の、手垢のついたネタだよなあ。

そういえば、盲導犬に命令を出すとき、日本の盲導犬でも英語を使うんだけど、
その方が、いざというとき言い間違えたりしないからよい、というのを、
大昔ドラマかなんかで言ってたのを思い出した。
犬に、「ゴー」の代わりに「行け」を覚えさせることはもちろん出来るけど、
日本人が普段から「行け」を使っていると、いざっていうときに「行ってえ!」とか
叫んだりして犬にはそれがわからない、ってことだったと思う。

日本語プログラムは、読む方は確かに読みやすいと思うけど、書く方は、
文法エラーにされたりしてかえってストレスたまらないのかなあ。
使っている人の感想求む。

190 名前:デフォルトの名無しさん [2005/11/10(木) 23:41:54 ]
あれは読むためのものでしょ?

書く技量>>>>>>読む技量

通常の言語の逆w

191 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 01:18:54 ]
>>189
そういうのよく言ってる奴いるけどさぁ
じゃあ英語が母国語の奴らはどうしてんだよ。

192 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 01:27:37 ]
>>191
英語はGO以外の言い方がないんだよバカだから
南部なまりでもGOはGO
おまえだってゴーパピー!って一回ぐらいは言ったことあるだろ

193 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 03:15:21 ]
>>185
テクニック的な事と研究を一緒にしないでくださいね。

194 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 05:30:51 ]
>>185
生成文法の分野としてはその通り。
ユーザインタフェースの分野としてはまだまだ、だと思う。

今まではユーザインタフェースは研究と見なされなかったけど、
生産性が重要視されるこれからでは十分研究になるんじゃないかな。

195 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 06:31:56 ]
研究され尽くしたとか言われる割には、一向に文脈自由文法を実用的
速さで解析するアルゴリズムが出ませんね。

196 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 07:55:21 ]
>>195
依存と言いたい? 慣れない言葉を使う時は気をつけよう。

197 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 08:17:29 ]
いや、自由の方だよ。LRやLLに全然近づけない。



198 名前:デフォルトの名無しさん [2005/11/11(金) 09:04:29 ]
え、、、文脈自由文法ってそういうもんじゃねーの?俺の認識不足?
O(n^3)ってのは崩れないんじゃ?できないものはできないんでは?



199 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 09:11:50 ]
ハードの側で並列処理が当たり前になれば、新たな進展が見られるんでは?


200 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 09:43:13 ]
馬鹿?
速度の問題じゃないでしょ?

201 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 10:15:41 ]
>>195
つ 冨田LR

202 名前:デフォルトの名無しさん [2005/11/11(金) 10:35:29 ]
CFGについては、並列アルゴリズムは既に提案されてるだろうし、発見的手法も
提案されてるはず。というかどっちかしか研究のネタないよ。後はハード面から
やるか。計算量は理論的に決まってるからどうしようも無い。
できることはできるし、できないことはできないってはっきりしてるのが計算機
科学なんだからさ、、、どのみち斜陽の学問ですよ。



203 名前:デフォルトの名無しさん [2005/11/11(金) 14:03:23 ]
社用とはキツイナw
まぁ、社内でも能力給制度が始まったんだが、
飛び抜けて評価が低かったのも実はないしょw


204 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 14:29:57 ]
>>201
バックトラックしまくってるだけのアホアルゴリズム。

205 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 15:16:30 ]
>>202
いかにそのサブセットで性質のいいものを見つけるかって方向性もあるだろ?
LALR(1)とかLRとかLL(k)とかはそういう方向でしょ?
斜陽じゃなくてブレークスルーが求められてると見た方がいいんじゃない?
流行が終わるとすぐ誰もやらなくなるのが日本の悪いとこ。

206 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 15:49:07 ]
下手にブレイクスルーが起きたって自然言語まがいの
複雑怪奇な言語が出てくるのが落ち。

207 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 16:14:29 ]
やってみる前からキレイにオチつくとわかるなら研究なんていらないよw



208 名前:デフォルトの名無しさん [2005/11/11(金) 18:43:44 ]
>>207
だから、社用の学問とか言われちゃうんだろ。


209 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 19:32:47 ]
>>208なんで?

210 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 20:52:42 ]
>>206
妙に納得w

研究としては面白みに欠ける分野なんだろうけど、
逆の見方をすれば、信頼できる枯れたテクノロジーということも出来る。

211 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 20:56:33 ]
>>209
バカにマジレスカコワルイ

>>210
俺も同意。
まあこれ言っちゃおしまいだけど、プログラミング言語の構文としては、
Cあたりでだいたい実用上困らないところまで行っちゃってるんじゃないか。
細かい不満はあるものの、LALR(1)で「プログラミング言語としては」必要十分というか、
これ以上がんばっても98点を99点にするようなもので、労多くして益少なし
なんじゃないかな。

212 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 21:19:38 ]
>>204
……バックトラックではないよ

213 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 21:53:30 ]
>>211
> 細かい不満はあるものの、LALR(1)で「プログラミング言語としては」必要十分というか、
> これ以上がんばっても98点を99点にするようなもので、労多くして益少なし
> なんじゃないかな。

うまい表現ですね。私も同感です。
ただ、あえて言うとすると、LALR(1)は表現しにくいという所が
気に入らないと言えば気に入らない点ではありますけどね。

# 言語大量発生の防波堤にはなるのかな?

214 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 22:05:53 ]
誰も冨田LR(GLR)を知らんのか。
CFGをフルカバーする上に、実用上はO(n)なんだけど。
bisonでも使われてる。

215 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 22:13:46 ]
それが本当だとしても、最近はLLばかり聞くから、何か欠点があるんじゃない?

216 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 22:23:44 ]
>>214
bison2.0からだっけ?

217 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 22:24:45 ]
>>215
LLが流行ってるのは、再帰下降で実装した上で
一部の関数をユーザ定義のもので差し替えるという手が使えるから。
CFGを超えるような言語を扱えるようになったりする。
泥臭いけどがんばれば何でもできるのが魅力。



218 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 22:33:43 ]
素のLRってテーブルが馬鹿でかくなるんじゃなかった?
それで改良版のLALRが出来たと何かの本で読んだけど。

219 名前:217 mailto:sage [2005/11/11(金) 22:44:08 ]
>>216
それぐらいだと思う。
もしかしたら 1.8なんとかぐらいの時もあったかも。
>>215
しっかり答えてなかったスマソ。
LLと比べると、基本はLRなんでユーザが途中の処理にちょっかいをだすのはやりにくい。
あと、yaccみたいに構文の要素に対してプログラムを実行する形式で使うと、
構文の要素が仮決定の段階でプログラムが実行されてしまうということが起こる。
本来の冨田LRは解析木を出力するもので、解析木を完全に作ってから色々すれば問題ないんだけど、
その場合異常に長いソースを食わせたときにO(n)のメモリ量が必要になるので困るかもしれない。
長いソースを書くなとか、メモリをきちんと積んどけとユーザに言える環境だったら問題ないと思う。
>>218
冨田LRはLALRのテーブルでもOK。最近のメモリ事情だったらLRでも大丈夫な気もする。

220 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 23:11:10 ]
もう構文解析の話はいいよ

221 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 23:21:55 ]
>>211
>これ以上がんばっても98点を99点にするようなもので、労多くして益少なし

分野は違うが圧縮アルゴリズムを研究してる人間を全否定するような発言だ。

222 名前:デフォルトの名無しさん [2005/11/11(金) 23:26:33 ]
全否定はしとらんだろ
+1点あがってるんだからw

223 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 23:27:10 ]
>>221
最近は可逆圧縮が人気なのでは?

224 名前:デフォルトの名無しさん mailto:sage [2005/11/11(金) 23:38:42 ]
Skypeなんていう素晴らしいものが登場できるくらいだから、コンパイラ屋もがんばれ!
ある程度成熟した分野では、技術は用途が前提にならないと無駄になるよね

225 名前:デフォルトの名無しさん [2005/11/12(土) 00:07:47 ]
ここのスレの馬鹿住人 >>206 を100回読めw

226 名前:デフォルトの名無しさん [2005/11/12(土) 00:10:01 ]
>>221
だがそれも事実だ。
企業にとっては対費用効果が重要になる。
決してタイ費用高価ではない。間違うなよ。

227 名前:デフォルトの名無しさん mailto:sage [2005/11/12(土) 00:11:30 ]
>>226
すまん。
まちがえそうになった。



228 名前:デフォルトの名無しさん [2005/11/12(土) 00:19:24 ]
ここのスレの馬鹿住人 >>206 を100回読めw

229 名前:デフォルトの名無しさん mailto:sage [2005/11/12(土) 00:30:58 ]
なんつーか、前スレからだけど、
面白くもないネタやダジャレ(と本人が思っているもの)や
くだらなーい、くだらなーい煽りとかを、
常にageで書き込んでいる低脳がいるな。

これって何人いるの? もしかしてひとりでやってんの?






[ 続きを読む ] / [ 携帯版 ]

前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