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

「コンパイラ・スクリ ..

113:108
05/11/08 12:15:17
はぁ、、、そもそもVBでこんなことするのがおかしいのか、、、ショック

実は設定ファイルを書くための簡単な自分言語？が必要なんです。
その設定ファイルは現場の人に書いて貰う予定なんで、あまり難しいの無理だし。
がんがって書くか、、、

114:デフォルトの名無しさん
05/11/08 13:20:33
>>113
ならLL文法で十分ぢゃないか。
LL系の学習用の簡単なソースならMicroPlan(パスカル系でセルフコンパイラのソースが付いてた）
とか言うのが大昔のBitに掲載されてたから図書館で探してみれば？

115:114
05/11/08 13:22:10
これね
URLﾘﾝｸ(www.google.co.jp)

116:デフォルトの名無しさん
05/11/08 13:34:18
>>113
設定ファイルならDTDも簡単に書けそうだし、
もうオリジナル言語なんかやめてXMLにしちゃえｗ
一々オリジナル言語設計するより作成もメンテも楽だぞ。
ツールも揃ってきてるし検証パーサ使えば検証もサボれるし。
XSLでHTMLに変換すれば整形表示も簡単ｗ

117:デフォルトの名無しさん
05/11/08 13:39:01
XMLのおかげで、パーサを書く手間がずいぶん減った気がする。
既に存在しているフォーマットを読むとき以外は使わなくなった。

118:デフォルトの名無しさん
05/11/08 13:58:23
VisualBasic XMLでググってみると
URLﾘﾝｸ(kamoland.com)
こんなページがあった。どうやら割と簡単に使えそうじゃないか。

119:デフォルトの名無しさん
05/11/08 14:51:38
果てしなくどうでもいいことだけど、日本人は何でVisual Basicにスペース入れずに書くの？

120:デフォルトの名無しさん
05/11/08 14:54:30
>>119
果てしねーーーーー

121:デフォルトの名無しさん
05/11/08 14:57:38
分かち書きで単語を区切る言語圏に居ないからじゃないのか？

122:118
05/11/08 15:26:02
>>119
漏れの場合は：
スペースはデフォルト設定のMS-IMEでは変換キーなため
日本語入力時は一続きの入力が終わって意図的に変換するとき以外は
スペースキーに触らない。
大文字でスタートするIMEの英字入力モード中はスペースは変換でなく
スで、ペースになるのではあるが、やっぱり触るのに心理的抵抗があり、
入れなくて済むものは入れずに済ましたい心理的傾向がある。
多分それが原因。

123:118訂正
05/11/08 15:27:00
スで、ペース→スペース

124:108
05/11/08 15:42:04
XMLか、、、勉強不足で良く分からないんだけど、例えば、

if (isExist("hoge")) i+3; else i+2;

みたいな条件分岐も何とかなる？

125:デフォルトの名無しさん
05/11/08 15:56:39
「設定ファイル」内でどの程度の計算記述能力が必要かにもよるが、
条件分岐を表現するエレメントを書けば書けない事はなかろう。
（例えばmakeのような働きをするANTのファイルはXMLで書かれている。
あるいはXSLスタイルシートはそれ自身XML形式で、
関数型言語スタイルでかなり複雑な変換処理が書ける）
ただ条件付設定ファイルレベルならばいいが
本格的な汎用スクリプトが必要になるようだと
XMLでは不可能ではないまでもあんまりおいしくなくなる可能性はある。
設定ファイルでどんな種類の条件分岐や計算が必要になるかを
把握することが鍵。

126:デフォルトの名無しさん
05/11/08 16:31:29
>>125
つかそんなXMLを生エディタで書かされる方はたまらんだろう。
108が設定ファイルをXMLにするのなら、むしろそのＸＭＬを生成する条件設定アプリ作る方がマシじゃなかろうか？

127:デフォルトの名無しさん
05/11/08 17:24:44
>>126
いずれにせよ「設定ファイル」として想定される内容次第だな。
ある程度定まったパターンの処理ばかりであるならXML化してもいいが
汎用スクリプト言語的でどんな種類の処理がかかれるかについて
設計時に把握しきれないなら
そもそもXMLを選ばないほうがいい可能性が高いし…。

別の言い方をすれば、主に値や型の宣言が並ぶスタイルならXML向きだが、
複雑な制御フローや汎用の演算セットがあるようなら向かない可能性が高い。
XMLは元来「文書」を表現するためのものだから
「設定ファイル」の性質が「文書」に近ければXMLで比較的表現しやすいし、
「文書」から離れて手続きプログラム的になるとXMLでは段々表現し辛くなる

条件設定アプリはその中間くらいの複雑さのときの解だな。

128:デフォルトの名無しさん
05/11/08 18:07:45
>>124
あくまでも一例
<if test="isExist('hoge')">
<true>i+3</true>
<false>i+2</false>
</if>

実際はXSLなどを参考にしつつもうちょっとマシなのがいいと思うけど。

129:デフォルトの名無しさん
05/11/08 18:14:01
XMLなんて馬鹿の思いつきだよ。
する～よろ>>ALL

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

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

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

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

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

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

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

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

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

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

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

136:デフォルトの名無しさん
05/11/08 19:37:30
>>128
うへえ。
いろんな意味でLISPのS式の方がいいじゃん。

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

138:デフォルトの名無しさん
05/11/08 19:48:36
>>136 ログ嫁

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

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

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

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

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

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

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

146:デフォルトの名無しさん
05/11/08 21:10:57
>>145
ほほぅ、、もしかして「日本語」か？

147:デフォルトの名無しさん
05/11/08 21:12:48
>>145
詳しく

148:145
05/11/08 21:13:20
>>146
その通りw

149:デフォルトの名無しさん
05/11/08 21:45:40
りんごタソは、やまとなでしこ。

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

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

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

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

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

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

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

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

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

154:デフォルトの名無しさん
05/11/08 23:30:51
デザイナー自体は>>91で出てるね。

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

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

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

URLﾘﾝｸ(www.microsoft.com)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

166:デフォルトの名無しさん
05/11/09 16:14:10
GCC

167:デフォルトの名無しさん
05/11/09 16:28:06
ICC

168:デフォルトの名無しさん
05/11/09 16:29:52
>>165
学習と開発を一緒にしないでください。

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

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

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

172:デフォルトの名無しさん
05/11/09 19:22:08
開発が人生のすべてで、他はオマケという人もいる罠。ｗ

173:14
05/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:デフォルトの名無しさん
05/11/09 20:39:13
なんか、俺様言語のオンパレードだなw

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

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

176:デフォルトの名無しさん
05/11/09 22:15:21
>>173
指摘thanx、見落としてました。という事は

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

でどう？

177:108
05/11/09 22:20:08
>>169
多分，
＞比較的自由に条件が設定できる
という部分が誤解を招いたかと。すみません。

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

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

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

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

179:デフォルトの名無しさん
05/11/09 22:24:55
復活するかどうかは普通は決定できない、持っているかどうかは決定できるという話じゃない？

180:178
05/11/09 22:27:18
ごめん。思いつきで書いたけど良く考えなくても決定できそうにない　(；´Д｀)

181:デフォルトの名無しさん
05/11/09 22:45:29
>>１７５
おまえがいちばん鵜剤w

182:デフォルトの名無しさん
05/11/09 23:11:24
>>177
文法がある以上、言語だと思うけど。
多分DB絡んでる？違うかな。。。

183:デフォルトの名無しさん
05/11/09 23:52:02
>>175
ウザイらしいぞw

184:デフォルトの名無しさん
05/11/10 01:32:53
10 omaira
20 nanigeni LV
30 taka sugi

185:デフォルトの名無しさん
05/11/10 22:12:06
構文解析って、もう研究するところないんですかね？
ちょっとそんなこと聞いたもので。。。

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

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

187:デフォルトの名無しさん
05/11/10 23:18:01
>>185-186
禁句w

188:デフォルトの名無しさん
05/11/10 23:24:34
そこで日本語プログラミング言語ですよ

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

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

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

190:デフォルトの名無しさん
05/11/10 23:41:54
あれは読むためのものでしょ？

書く技量＞＞＞＞＞＞読む技量

通常の言語の逆w

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

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

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

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

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

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

196:デフォルトの名無しさん
05/11/11 07:55:21
>>195
依存と言いたい？慣れない言葉を使う時は気をつけよう。

197:デフォルトの名無しさん
05/11/11 08:17:29
いや、自由の方だよ。LRやLLに全然近づけない。

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

199:デフォルトの名無しさん
05/11/11 09:11:50
ハードの側で並列処理が当たり前になれば、新たな進展が見られるんでは？

200:デフォルトの名無しさん
05/11/11 09:43:13
馬鹿？
速度の問題じゃないでしょ？

201:デフォルトの名無しさん
05/11/11 10:15:41
>>195
つ冨田LR

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

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

204:デフォルトの名無しさん
05/11/11 14:29:57
>>201
バックトラックしまくってるだけのアホアルゴリズム。

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

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

207:デフォルトの名無しさん
05/11/11 16:14:29
やってみる前からキレイにオチつくとわかるなら研究なんていらないよｗ

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

209:デフォルトの名無しさん
05/11/11 19:32:47
>>208なんで？

210:デフォルトの名無しさん
05/11/11 20:52:42
>>206
妙に納得w

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

211:デフォルトの名無しさん
05/11/11 20:56:33
>>209
バカにマジレスｶｺﾜﾙｲ

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

212:デフォルトの名無しさん
05/11/11 21:19:38
>>204
……バックトラックではないよ

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

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

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

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

215:デフォルトの名無しさん
05/11/11 22:13:46
それが本当だとしても、最近はLLばかり聞くから、何か欠点があるんじゃない？

216:デフォルトの名無しさん
05/11/11 22:23:44
>>214
bison2.0からだっけ？

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

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

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

220:デフォルトの名無しさん
05/11/11 23:11:10
もう構文解析の話はいいよ

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

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

222:デフォルトの名無しさん
05/11/11 23:26:33
全否定はしとらんだろ
＋１点あがってるんだからw

223:デフォルトの名無しさん
05/11/11 23:27:10
>>221
最近は可逆圧縮が人気なのでは？

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

225:デフォルトの名無しさん
05/11/12 00:07:47
ここのスレの馬鹿住人 >>206 を１００回読めw

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

227:デフォルトの名無しさん
05/11/12 00:11:30
>>226
すまん。
まちがえそうになった。

228:デフォルトの名無しさん
05/11/12 00:19:24
ここのスレの馬鹿住人 >>206 を１００回読めw

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

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

230:デフォルトの名無しさん
05/11/12 00:40:56
本人は複数人いるフリをしてるつもりなんだろ。そっとしといてやれよ。
病気なんだって…。

231:デフォルトの名無しさん
05/11/12 00:46:29
例えばJavaを補完するのが目的のスクリプトエンジンがあるとして
Javaオブジェクト生成のルールを統一した複数のスクリプトエンジンを付け替えたりできたら面白いな。
好きなスクリプトでちょろっとDB更新したり、設定値を変更したり（log出力とか）できる。

232:207
05/11/12 01:49:05
>>209
キレイに落ちがつく研究しかないなら研究する必要ないじゃん。
そんな分野は研究する必要がないから，斜陽の学問だろ。
研究しても意味が無い分野も同様だろ。計算機科学の分野はほとんど
そんな感じ。基礎研究は終わっててあとは実用上どうするかとか，
そういう問題になってる。ハードの性能があがるのを待つか，それが
できないなら，小手先の技術でやるかという話なだけで，できるできない
という話になると研究する前にすでに結論が分かってる。この分野の研究
したことあればそれが常識なんであって，ごまかしごまかし，いかにも成果
があったかのように論文書くんだろ。それは一般的な解じゃなくて，ものすご
く限定された用途であることを承知の上で。

233:デフォルトの名無しさん
05/11/12 08:41:03
>>232
何か君を含めて多数の人間が勘違いしているが
ここは「コンパイラ・スクリプトエンジン相談室」であって
「言語相談室」じゃないよ。
>>231みたいなレスがメインでしょ

234:デフォルトの名無しさん
05/11/12 08:47:54
>>233
>>232 は、その研究について話しているのでは？
Lisp馬鹿がでしゃばる流れより、よっぽど良い議論だと思うが？

235:デフォルトの名無しさん
05/11/12 09:25:03
あの w つける自演キチガイですか？ >>234
だからいきなりキチガイみたいにアンチすんなって。
コンパイラとスクリプトの話をしているかぎりは
別に LISP だろうが Ruby だろうがかまないよ。

236:デフォルトの名無しさん
05/11/12 09:31:30
>>234-235

Lispを脈絡なく出してくる＆Lispに過敏に反応するやつ＝Lisper

237:デフォルトの名無しさん
05/11/12 09:34:57
自作言語にオブジェクト指向入れようとすると、つまんない言語になるよね。
あれってなんでだろう。
object.methodみたいなレシーバ従属呼び出しができない言語は
オブジェクト指向言語じゃないと思われる風潮がある。
逆になんであれobject.method形式であればオブジェクト指向言語と勘違いされて
もてはやされる傾向にある。
なんでだろう。

238:デフォルトの名無しさん
05/11/12 09:47:42
低能君は w がつかなくなったんだね。

>>234 Lisp馬鹿が～（←脈絡なくでてくる） → >>236 ～は Lisper（←自演でたたく）

てなパターンを何度見たか。マジで病院いったほうがいいとはおもう。

239:デフォルトの名無しさん
05/11/12 11:16:55
いや、wつけてるのは俺だし、俺はLispマンセーレスしかしてないからｗ

240:234
05/11/12 12:13:42
>>238
病院いった方がいいのは貴方では？
痛いところ指摘されると、何でもかんでも「自作自演」か？

241:デフォルトの名無しさん
05/11/12 12:15:50
232と234の口調が似てる件について。

242:デフォルトの名無しさん
05/11/12 12:43:43
>>241
いや、似てないと思う。
234は文章の最後に？を付けて、他人に疑問系の発言ばかりするのが特徴。
232は逆に文章は断定系の発言が多いというのが特徴。

俺の主観だとむしろ逆のタイプと思うけど。

243:デフォルトの名無しさん
05/11/12 13:00:36
>>232の読点が「，」なのを見ると理系で論文書いたりする感じの人なのか。

…疲れたんだろうなぁ、きっと。

244:デフォルトの名無しさん
05/11/12 13:16:51
それなら，句点も"．"になると思う．

245:234
05/11/12 14:06:09
流石、構文解析やら字句解析に長けてる人達だ。

246:デフォルトの名無しさん
05/11/12 14:07:03
>>236
代入ですか。
まさに「Lisperということにしたい」だけという現実にマッチしていますね :-P

247:デフォルトの名無しさん
05/11/12 14:42:15
おまいらいつから人の発言の構文解析するスレになったんですか？

248:デフォルトの名無しさん
05/11/12 14:47:47
他人の発言って言うけど、自然言語処理の相談もこのスレで良いの？

249:このスレの1
05/11/12 14:58:56
このスレ立てたの俺なんだけど、なにしろ前スレが1000到達寸前だったので
急いで立てたら書籍関係リンクを貼り忘れるわ、前スレで出てきたリンクなんかも
反映させられなかったわだった。今までも、スレの中で出てきた有用なリンクが
テンプレに反映されなかったことは多々あったと思う。

というわけで、勝手にやってすまんが、Wiki立ててみました。

URLﾘﾝｸ(www6.atwiki.jp)

まだテンプレを貼っただけですが(本を1冊増やしたけど)、よければ使ってやってください。

今のところ完全性善説モードになってます。編集もページ立てもファイルアップロードも
誰でも可能。

250:デフォルトの名無しさん
05/11/12 15:20:16
>>249
乙

251:デフォルトの名無しさん
05/11/12 16:00:15
>>249
GJ!

252:デフォルトの名無しさん
05/11/12 19:22:31
>>247
ワロタw

253:デフォルトの名無しさん
05/11/12 20:27:17
言語を現実のITソリューションに活用or適用する技術者と
言語を研究対象とする研究者がまじってるような。。。

前者は企業に不可欠の存在
後者は（ry

254:デフォルトの名無しさん
05/11/12 21:17:10
文字ちっちゃい…… pxで指定してるのかな

255:デフォルトの名無しさん
05/11/12 22:12:31
>>253
前者は変わりがいくらでもいるIT土方
後者は世界を動かす最先端

256:デフォルトの名無しさん
05/11/12 22:56:26
「ITソリューションに活用or適用する技術者」ﾜﾛｽ
格好良く言ってもただの　IT土方　だな確かに

257:デフォルトの名無しさん
05/11/12 23:26:08
>>255

世界を動かす最先端　　　　　　　　false
世界を動かす最先端と妄想する人　　true

258:デフォルトの名無しさん
05/11/12 23:35:41
>>253
前者は、Java/C/C++などに食いつく
後者は、Lisp/Rubyなどに食いつく

259:デフォルトの名無しさん
05/11/12 23:48:02
ITドカタがキレた

260:デフォルトの名無しさん
05/11/13 00:13:22
お前らIT土方の使ってるCやJavaやC#なども、
言語を研究対象とする研究者様が仕様を考えてやった言語だぞ
感謝しろよ

261:デフォルトの名無しさん
05/11/13 00:16:45
Rubyは違いますが何か？

262:デフォルトの名無しさん
05/11/13 00:29:13
>>260
Dennis Ritchie や James Goslingは確かに研究者と呼べるかもしれないが
Hejlsbergはただのプログラマーだろ。

263:デフォルトの名無しさん
05/11/13 00:36:10
>>260
でも、感謝するような研究者って日本には中田氏ぐらいしかいないでしょ？
あんたらは所詮、社会に何の貢献も出来ないシャヨウ研究者w

264:デフォルトの名無しさん
05/11/13 00:37:09
D言語に至ってはコンパイラ屋だからな。
今いちばんの注目株です。最近地味だが。

265:デフォルトの名無しさん
05/11/13 00:37:15
これだから素人はｗ

266:デフォルトの名無しさん
05/11/13 01:31:27
自称クロートキターーーーーーー!!

267:このスレの1
05/11/13 15:22:18
>>254
>文字ちっちゃい…… pxで指定してるのかな

Wikiのことですか?
だとすると、選んだスキンがよろしくなかったということですが、
私自身、ちょっと字が小さすぎかとも思うんですが、他にあんまり
いいのもなくて。

スキンの一覧がここにあります。こっちの方が、というのがあればよろしく。

URLﾘﾝｸ(atwiki.jp)

268:デフォルトの名無しさん
05/11/13 17:21:35
>>267
URLﾘﾝｸ(www6.atwiki.jp) の…

> body,td
> {
> /* font-family: "ＭＳＰゴシック", Osaka, "ヒラギノ角ゴ Pro W3";
> */ color: black;
>　　 margin-left: 0;
>　　 margin-right: 0;
>　　 /* margin-left: 2%;
>　　　　margin-right: 2%;
>　　 */ font-size: 12px;
>　　 padding:0;
> }

で、font-size: 12px を変えればいいだけ。

>>254
ブラウザの設定で、スタイルシートとかフォントサイズ
指定を無視するようにすればいいだけ。

269:このスレの1
05/11/13 19:18:37
>>268
んなこた言ったってレンタルWikiサービスなんだからスタイルシートを
直接書き換えられはせんだろう、役にも立たない常識レベルの知識を
得意げにひけらかしている人がいるなあ…と思いつつ、念のため調べたら
変更できました。ありがとうございました。

270:このスレの1
05/11/13 22:16:12
URLﾘﾝｸ(www6.atwiki.jp)
・「言語別リンク」のページを追加。
・GC関連のリンクを3つほど追加。
他の方による追加もお待ちしております。

271:デフォルトの名無しさん
05/11/13 23:42:41
>>253
前者は、Java/C/C++/Perlなどに食いつく
後者は、Lisp/リンゴなどに食いつく
素人は、Rubyに食いつく

272:デフォルトの名無しさん
05/11/14 00:37:28
>>271
低能キチガイ出現ー
…ほんと、低能だな。黙っている事も消えることもできないなんて…。

273:デフォルトの名無しさん
05/11/14 00:43:27
これほどのウザさとバカ自演と粘着を兼ね備えたキチガイは近年珍しいね。
ツッコミに対して必死になるところ(>>240 とか)を見ると真性だろうなぁ…

274:デフォルトの名無しさん
05/11/14 01:05:54
>>272
あぁ完全にキレたわ。
放置しようと思ったがお前だけは相手してやる。
Lispとrubyの1vs1。金かけてやろうぜ。負けたほうが10万でいいや。
素で逃げんなよお前。処理系用意できたら連絡よこせ。

275:デフォルトの名無しさん
05/11/14 01:08:32
よし、ここらへんでお前らはマ板にいけ。な？

276:デフォルトの名無しさん
05/11/14 01:14:05
なんか延びてると思ったらまた荒しが暴れてるのか。
>>272 に対してどうしてそーゆうレスになるのか意味わかんない。
バカの考えることって不思議だな。ちょっと恐くなった。

277:デフォルトの名無しさん
05/11/14 01:17:51
あぁ完全にキレたわ。のガイドライン
ｽﾚﾘﾝｸ(gline板)

278:デフォルトの名無しさん
05/11/14 01:24:33
ああ
影響されてコピペしたわけね

279:デフォルトの名無しさん
05/11/14 12:17:07
板にID制の導入ｷﾎﾞﾝﾇ

280:デフォルトの名無しさん
05/11/14 12:58:39
>>279
自治スレへどうぞ。

281:デフォルトの名無しさん
05/11/14 19:32:44
たぶん、キレてるやつは
社会に何の貢献も出来ないシャヨウ研究者w

282:デフォルトの名無しさん
05/11/14 21:40:46
うるせぇ！

283:デフォルトの名無しさん
05/11/14 21:56:15
問題はこのスレで何の話が相応しいかだ。
字句解析・構文解析程度だったら別スレ立ててそっちでやってくれって感じ。
いいかげんそっから先の話がしたい。
それともいっそ専門スレでも立てた方がいいのか。

284:デフォルトの名無しさん
05/11/14 22:05:36
例えば最適化ならそれに特化したスレを立ててみるとか

スレタイ：
言語処理系の最適化相談室1

テンプレ：
プログラミング言語処理系の*最適化*に興味のある人達のスレッドです。

データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。

※字句解析・構文解析などの表層的な話題は以下のスレでやってください。
「コンパイラ・スクリプトエンジン」相談室8
ｽﾚﾘﾝｸ(tech板)

285:デフォルトの名無しさん
05/11/14 22:07:50
>>284
そんなのは他所でやれ。

286:デフォルトの名無しさん
05/11/14 22:17:21
>>284
それでいいんじゃねーの。
本来のスレッドの使い方だよ。
このスレは今後は厨、ネタ隔離スレとして機能する。

287:デフォルトの名無しさん
05/11/14 22:18:18
>>286
自演乙（超久々に使ったよ））

288:デフォルトの名無しさん
05/11/14 22:19:52
自演されるのが嫌ならさっさとID制にしてもらえば？

289:デフォルトの名無しさん
05/11/14 22:20:21
>>283
ネタふれば話が進むだろうが、愚痴じゃ進めようもないじゃねぇか。

290:デフォルトの名無しさん
05/11/14 22:20:38
じゃあ立ててくるか？
俺は無理っぽ

291:デフォルトの名無しさん
05/11/14 22:23:31
ここしばらく変なのが常駐してるから別スレ立てたいなら止めはしない。

292:デフォルトの名無しさん
05/11/14 22:26:10
関係ないけど>>1の「動的バイナリ変換」て何？
昔流行った自己書き換えのこと？

293:デフォルトの名無しさん
05/11/14 22:26:11
既存のスクリプトエンジンをどう組み込むかとかな。
SpiderMonkeyとか設定ファイル代わりに使えば面白い流れが生まれそう。
車輪の再開発より使われていないリソースの発掘のが大事。

294:デフォルトの名無しさん
05/11/14 22:31:28
>>293
使われていないリソースには使われない理由があるような気が
設計が古臭くて今のトレンドとかみ合わないとかライセンスや作者の人格に問題アリとか

295:デフォルトの名無しさん
05/11/14 22:41:42
例えば今まではWebアプリはDBの内容を書き換えることによって動的に設定をいじったりするけど
組み込みが主流になれば、ハッシュをいじる事ができて、マスタテーブルの類はオンメモリで行ける。

296:デフォルトの名無しさん
05/11/14 22:52:59
>>294
（煽りじゃなくって）人格って関係する？

次ページ