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

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

[1からを表示]
50:デフォルトの名無しさん
05/05/10 20:46:08
馬鹿かおまえら？
LISPじゃあるまいし

51:デフォルトの名無しさん
05/05/10 23:27:57
LISPがあればいいや

52:42
05/05/10 23:42:48
>>46
>Rubyに限らずわりとよくある要求だろ。 > lexerに文脈を渡す

そうかねえ。
Cあたりでも、typedefなんかでparserがlexerにちょっかい出すけど、
parserがlexerに『頻繁に』ちょっかい出すのはやっぱり行儀悪いと俺は思うよ。
人間にとっても曖昧な、落とし穴の多い言語になりそうだ。

>>47
>むしろ変数で情報を渡すよりカプセル化に有益なんでは。

「変数で状態を渡す」と言った覚えはないし、

>それ以後%startと整合性をとる必要を生じるのが「かけるべき手間」ってのもなあ…

「%startと整合性をとる必要を生じる」ってのがわからないんだけど。
俺アホだからなにか気付いてないことがあるんかね。だとしたら教えてくれや。

>マゾじゃあるまいし。

クラスにsetterメソッド書くのがマゾだ、とまで言うんならもう何も言わないけどさ。

現状で、flexでさえそんな機能がないってことが、大半のプログラマはそんな
機能を望まない、っていうひとつの証拠だと思うよ。

53:デフォルトの名無しさん
05/05/11 00:00:13
アホなら黙ってりゃいいのに。

54:デフォルトの名無しさん
05/05/11 02:18:35
>>52
機能がないことがその証拠ってのもおかしいだろ。機能がないからほとんどの人間が気づいていないだけ、という可能性も十分あるわな。
いろんな記号を多用するような言語（スクリプト言語では多いよな）なら、コンテキストによってlexerの動作を変えたいという要求はすごくある。
それが今までのツールじゃ難しかったか面倒くさかったから、言語の機能が増えるたびに予約語も増える傾向にある。

55:デフォルトの名無しさん
05/05/11 03:05:04
>>52
> 人間にとっても曖昧な、落とし穴の多い言語になりそうだ。
ここに全く同意できない。
開発する人間とって曖昧な、落とし穴の多い実装になりそうだ。
↑これなら納得するし説得されてやる。

56:デフォルトの名無しさん
05/05/11 04:44:45
>>55
>開発する人間とって曖昧な、落とし穴の多い実装になりそうだ。
んで、だからこそそれをサポートする>>39の提案が意味を持つわけだね。

57:デフォルトの名無しさん
05/05/11 20:41:25
WindowsでC++モドキを作ってて、UNIXに移植する段階でこの問題が出た。

WindowsのC++処理系のほとんど（全て？）はtry catchの例外機構を
SEHで実装してるけど、
UNIXでは何使って実装するもんなの？まさかsetjmp/longjmpとか？

58:デフォルトの名無しさん
05/05/11 20:54:31
g++を見たほうが早いような

59:デフォルトの名無しさん
05/05/11 21:01:17
たぶんアセかな。
そのアセ自体が何してるのか知らんが。

60:デフォルトの名無しさん
05/05/11 21:07:35
>>57
言いたいことはわからんでもないが，SEHとはtry/catchのような構文によるエラー処理の
総称では？
SEHをCで実装する場合、setjmp/longjmpもしくは2返戻値によるのが普通かな。

61:デフォルトの名無しさん
05/05/11 21:09:26
確かに
> try catchの例外機構をSEHで実装してるけど、
という言い方は変だよな。

62:デフォルトの名無しさん
05/05/11 21:10:15
>>57
つまり、そのまさか。

63:デフォルトの名無しさん
05/05/11 21:12:12
>>60-61
知ったかぶんなよ。
WindowsにはSEHという機構がOSに組み込まれてるの。

64:デフォルトの名無しさん
05/05/11 21:19:39
>>63
そんなことは分かってる

65:デフォルトの名無しさん
05/05/11 21:20:25
ちなみに例外がアプリケーション側で補足されず、そのままスルーすると出る
デフォルトのダイアログ（ご迷惑をお掛けしています～）は、
OS側にこの機構があるおかげです。
UNIXの糞ダンプと違って、そのままデバッガに飛ぶなりできます。。。

66:デフォルトの名無しさん
05/05/11 21:22:08
>>64
いや、おまえ判ってない。
ぜんぜんわかってない。

67:デフォルトの名無しさん
05/05/11 21:23:08
＞SEHをCで実装する場合、setjmp/longjmp
なんせこんなこと言ってるし

68:デフォルトの名無しさん
05/05/11 21:25:45
じゃあ糞UNIXはsetjmp/longjmpで糞チェインを自分で作らないと駄目って事で。

69:デフォルトの名無しさん
05/05/11 21:28:21
言語語ってるやつが、WIN使いとはなｗ
ワロタ

70:デフォルトの名無しさん
05/05/11 21:29:36
え、どこが面白いの？

71:デフォルトの名無しさん
05/05/11 21:31:13
>>69
そんな奴おらんだろｗ

72:デフォルトの名無しさん
05/05/11 21:33:25
Windowsの高度な技術議論についてけずUNIXerの頭が崩壊したらしいなw

73:デフォルトの名無しさん
05/05/11 21:34:28
それで、UNIXでは本当にsetjmp使うんですか？
なんか信じられないけど。
まあgcc読んできますが。

74:デフォルトの名無しさん
05/05/11 21:39:00

SEHとはこれのことだろ。
URLﾘﾝｸ(www.microsoft.com)
URLﾘﾝｸ(www.microsoft.com)

75:デフォルトの名無しさん
05/05/11 21:42:23
>>65
ｻｰﾊﾞでそんな事してたらｱﾎだろ

76:デフォルトの名無しさん
05/05/11 21:42:36
なんでsetjmp使うことに驚く。別にUNIXでなくても普通に使ってるぞ。

ところで上でもめてるようだが、SEHという言葉には

・win32固有の機能（よく__try, __exceptで利用するものね）
・try～catch的なエラー処理構文（on error goto等との対比で）

のふたつの意味があり、Microsoftでもその両方を文脈に応じて使いわけている。

77:デフォルトの名無しさん
05/05/11 21:45:19
>>75
Windowsにはサービスというものが(以下略
ほんと糞UNIXerは使えねえなw

78:デフォルトの名無しさん
05/05/11 21:46:00
UNIX使いの使えなさ加減にﾜﾛﾀ

79:デフォルトの名無しさん
05/05/11 21:46:44
>>76
文脈から理解できなかったアフォの言い訳だなw

80:デフォルトの名無しさん
05/05/11 21:48:08
UNIX使いのアホさ加減にﾜﾛﾀ

81:デフォルトの名無しさん
05/05/11 21:49:08
やけにスレ伸びてるかと思ったら
UNIX嫌いのバカが一匹いるだけか

82:デフォルトの名無しさん
05/05/11 21:49:50
UNIX使いの煽りってたいしたことないのなw

83:デフォルトの名無しさん
05/05/11 21:50:15
>>77
一生ﾓﾆﾀのお守りしてるつもり?

84:デフォルトの名無しさん
05/05/11 21:50:18
UNIX使いの煽りの低レベルさにﾜﾛﾀ

85:デフォルトの名無しさん
05/05/11 21:51:11
windows最高。microsoftは神。

86:デフォルトの名無しさん
05/05/11 21:51:14
>>83
無知がでしゃばるなって。
サービス登録すれば勝手に再起動とか色々できるわけですよ。

87:デフォルトの名無しさん
05/05/11 21:51:42
UNIX使いの無知さ加減にﾜﾛﾀ

88:デフォルトの名無しさん
05/05/11 21:52:06
はやくunixにもwin32が移植されるといいね。

89:デフォルトの名無しさん
05/05/11 21:52:40
win32万歳。seh万歳。

90:デフォルトの名無しさん
05/05/11 21:54:02
>>86
ﾍｪ、凄い凄いw

91:デフォルトの名無しさん
05/05/11 21:54:13
windowsは究極のos

92:デフォルトの名無しさん
05/05/11 21:54:33
UNIXを馬鹿にしないでください
2chのサーバだってUNIXですよ？

93:デフォルトの名無しさん
05/05/11 21:54:44
windowsに足りないものは何もない

94:デフォルトの名無しさん
05/05/11 21:55:51
余分なものは山ほど(ry

95:デフォルトの名無しさん
05/05/11 21:56:07
みんなで崇めようwindows

96:デフォルトの名無しさん
05/05/11 21:56:26
>>92
おれが馬鹿にしてるのはUNIXでなくてここにいるUNIX使いだってばw

97:デフォルトの名無しさん
05/05/11 21:56:59
>>96
おい、レベル下がってるぞ
もっと面白い事言ってくれよ

98:デフォルトの名無しさん
05/05/11 21:57:00
こんなに愛されて…windowsも幸せ者だな

99:デフォルトの名無しさん
05/05/11 21:57:29
UNIX使いの早とちりにﾜﾛｽ

100:デフォルトの名無しさん
05/05/11 21:57:47
そうだwindowsで行こう

101:デフォルトの名無しさん
05/05/11 21:58:38
世の中windowsが標準です

102:デフォルトの名無しさん
05/05/11 21:59:52
つまらん

103:デフォルトの名無しさん
05/05/11 22:00:33
　 _ 　∩
(　ﾟ∀ﾟ)彡　windows! windows!
　⊂彡

104:デフォルトの名無しさん
05/05/11 22:00:38
UNIXにもプロセスが死んだらコアダンプというものがあって、
デバッガを自分で起動できますが何か？

105:デフォルトの名無しさん
05/05/11 22:02:20
unixさんが好きです。でもWindowsさんの方がもっと好きです。

106:デフォルトの名無しさん
05/05/11 22:03:53
お前ら、まとめてこっちへ行っちゃえ。

最高に頭悪そうな発言してください in ム板 (V)
ｽﾚﾘﾝｸ(tech板)

107:デフォルトの名無しさん
05/05/11 22:06:38
ためになるお話でした。

108:デフォルトの名無しさん
05/05/11 22:10:48
いまさらWindowsで動かない処理系はクソだと思ってる俺様がきましたよ

109:デフォルトの名無しさん
05/05/11 22:12:14
もうみんな帰っちゃったよ

110:デフォルトの名無しさん
05/05/11 22:40:37
>>108
馬鹿の見本みたいな奴だなｗ

111:デフォルトの名無しさん
05/05/11 22:41:58
windowsが好きで好きで仕方がない

112:デフォルトの名無しさん
05/05/11 22:42:57
>>110UNIXだけだとサーバの日陰者アプリしか作らないじゃん

113:デフォルトの名無しさん
05/05/11 22:44:00
windowsを愛することにかけては誰にも負けない

114:デフォルトの名無しさん
05/05/11 22:44:42
>>112
UNIXでも最近まともに動いてるサーバはWebぐらいだよ。
正直ApacheやJavaのおかげと言っていい。
他の用途では正直使い物にならない。

115:デフォルトの名無しさん
05/05/11 22:44:50
windowsのためなら死ねる

116:デフォルトの名無しさん
05/05/11 22:46:41
まだDBがあるさ。
Oracleとかのおかげだけど。

117:デフォルトの名無しさん
05/05/11 22:47:07
削れるものは何もない。加えるものは何もない。それがwindows

118:デフォルトの名無しさん
05/05/11 22:48:25
何も足さない、何も引かない

119:デフォルトの名無しさん
05/05/11 22:48:53
Windowsの49日ルールがある限りUNIXは生き残れる！

120:デフォルトの名無しさん
05/05/11 22:50:01
そんなにいいのかwindowsは。明日買ってこよう。

121:デフォルトの名無しさん
05/05/11 22:50:10
そろそろ違う所でやってもらえませんか？＞UNIX関係
一応誘導しておきます。

UNIXプログラミング質問すれ Part5
ｽﾚﾘﾝｸ(tech板)

UNX板
URLﾘﾝｸ(pc8.2ch.net)

122:デフォルトの名無しさん
05/05/11 22:50:51
凄いな。俺も買ってこよう。

123:デフォルトの名無しさん
05/05/11 22:52:31
でもこんなにいいwindows、高いんじゃないの？

124:デフォルトの名無しさん
05/05/11 22:56:59
無料Linuxが1円の価値だとすると、プロ仕様はその約3万倍ぐらいです。
でもほとんどのお店で売ってるPCに何故か付いてきます。
何故でしょうね。
この謎を解き明かしてみるのも面白いかもしれませんよ。

125:デフォルトの名無しさん
05/05/11 22:57:10
それが奥さん、聞いてくださいよ。
なんとたったの28,350円(価格コム調べ）
URLﾘﾝｸ(kakaku.com)

さらに今お買い上げいただくと

126:42
05/05/11 23:16:31
なんかスレッドが伸びてると思ったら... なんだこりゃ。

で話を戻すけど、
>>55
>> 人間にとっても曖昧な、落とし穴の多い言語になりそうだ。
>ここに全く同意できない。

根拠もなしにんなこと言われてもなあ。実際Rubyは落し穴の多い言語になってるし。
URLﾘﾝｸ(i.loveruby.net)

で、Rubyのlexerには状態が9種類あるようだけど、parserから設定するのは
4種類だけだ(EXPR_BEG, EXPR_END, EXPR_ENDARG, EXPR_FNAME)。
だったらlexerにsetterを4個付ければ済む話。
たいした手間じゃないし、勝手に他の状態にされる危険もないし(カプセル化の基本)。

>>54
>機能がないからほとんどの人間が気づいていないだけ、
>という可能性も十分あるわな。

本気でそう思ってるんならパッチでも何でも作って公開すりゃいいじゃん。止めないよ。

>>57
ちなみにだが、Rubyの実装ではsetjmpもlongjmpも使いまくってるよ。
# ありゃひでえ。

127:デフォルトの名無しさん
05/05/11 23:41:25
初期のいったんCのコードを吐くやつはsetjmo,longjmp使いまくりだったじゃん

128:デフォルトの名無しさん
05/05/12 09:48:50
>>57-
例外が発生しない場合のオーバーヘッドを０にする手法がある。
setjump/longjumpだと、tryに入ったときにsetjumpして、
例外が発生したらlongjumpすると思うけど、
setjumpを省く代わりに、例外が発生したらスタックを遡りながら、
例外を起こしたコードのアドレスから対応するcatchを特定する。

129:デフォルトの名無しさん
05/05/12 11:37:43
何がひどいのかよくわかりません

130:デフォルトの名無しさん
05/05/12 12:18:26
とにかくRubyがひどいんでしょう

131:デフォルトの名無しさん
05/05/12 12:41:16
Rubyのソースが酷いのはRuby使い(信者除く)も認めてるらしいので
具体的に酷いところを挙げてみてほしいなぁ

132:三遊亭円楽
05/05/12 14:42:43
座布団ageようとおもって山田君駆動レコードをスタックに積んだのだが
何故、windowsやらunixやらですれがのびるんだね。

133:デフォルトの名無しさん
05/05/12 19:05:56
構造化例外処理のメジャーな手法は、
setjmp法、>>60の2返戻法、>>128の例外表法
の3つかな。
個人的には、変換後最適化が色々適用できる2返戻法が好きかも。
定量的な比較はしてないが…

134:デフォルトの名無しさん
05/05/12 19:59:16
＞2返戻法
これの説明だれかしてください
意味わかんねえよ

135:デフォルトの名無しさん
05/05/12 20:30:02
(通常の戻り値,例外オブジェクト)
だとググらずにカキコ

136:デフォルトの名無しさん
05/05/12 20:40:49
＞setjmp法、>>60の2返戻法、>>128の例外表法
つーか>>133説明してくれよ
そもそもそんな～法なんて言い方あるのかも

137:デフォルトの名無しさん
05/05/12 20:50:25
"2返戻値法" はググるで引っ掛かった
千葉雄司という人の造語?

URLﾘﾝｸ(ssl.ohmsha.co.jp)

138:デフォルトの名無しさん
05/05/12 21:26:46
URLﾘﾝｸ(fw8.bookpark.ne.jp)

735円だって

139:デフォルトの名無しさん
05/05/12 22:05:10
>>130
そうではない。
古いいまのパーサやスキャナの枠組に入らないだけ。

「古いブドウ酒は、新しい皮袋に馴染まない」

とは、まさにことこと。
新しい言語は、古い開発パラダイムを駆逐する。

140:デフォルトの名無しさん
05/05/12 23:15:18
>>139
信者乙。

141:130
05/05/12 23:27:10
>>139
ごめん、あれは42に対するいやみのつもりだった。

142:デフォルトの名無しさん
05/05/12 23:41:11
さっぱり意味不明

143:デフォルトの名無しさん
05/05/12 23:46:43
>>142
古いタイプの人間?

144:デフォルトの名無しさん
05/05/12 23:47:24
>>42

145:42
05/05/13 00:16:26
>>131
>具体的に酷いところを挙げてみてほしいなぁ

だから挙げてるじゃん。
(eval.cにおいて)setjmp, longjmpを使いまくってること、
parserがlexerにむやみにちょっかい出すこと。
まあ後者は言語仕様の問題だが、それを実装するために、
グローバル変数で通信してるってのはどうかと思う。
eval.cとparse.yが汚いってのは作者も認めてたと思う。

>>141
いやみったって、意味わかんねえんだけど。
むしろparserとlexerがきれいに分かれない言語の方が、古い言語っていうイメージが
あるけどね。俺は。

146:デフォルトの名無しさん
05/05/13 00:23:32
その実装のせいで処理系のユーザにとってどういう不具合が出てくるかが知りたい。
処理系自体がどういう実装になってようが、処理系のユーザにはあまり関係ないよね。

147:42
05/05/13 00:41:42
>>146
そりゃ実装が汚いからってユーザに不具合が出るとは限らんわな。
だから俺そんなこと言ってないし。

なんか粘着に絡まれてるなあ...

148:デフォルトの名無しさん
05/05/13 00:42:27
URLﾘﾝｸ(i.loveruby.net)

スペースの入れ方で解釈が変わる言語ってどうなのよ？

149:ヽ(´ー`)ノ ◆.ogCuANUcE
05/05/13 00:43:42
>>146
> 処理系自体がどういう実装になってようが、処理系のユーザにはあまり関係ないよね。
それを言っちゃうとこのスレの存在意義がなくなってしまうのだが。

150:デフォルトの名無しさん
05/05/13 00:50:48
>>148

a[i] = 1 # a[i] = (1)
a [i] # a([i])

前者はインデックス代入であり、後者はメソッド呼び出しの括弧を省略して引数に配列の要素を渡している。

また次のような場合もある。

a + 1 # (a) + (1)
a +1 # a(+1)

このあたりの仕様は一部の地域でやたらと嫌われているようだ。

つうかわざわざこんな仕様にした作者の意図を激しく聞いてみたい

151:デフォルトの名無しさん
05/05/13 02:42:38
別にそれらをそういう風にしたかったわけじゃなく、
メソッド呼び出しの括弧を省略できるようにした結果だろうね。

152:デフォルトの名無しさん
05/05/13 02:47:39
>>149
そんなことない。
効率的な実装で処理系が速くなるならユーザにも意味はあるし、
言語仕様や意味論の話題だってあるだろう。

153:デフォルトの名無しさん
05/05/13 02:49:33
なんでルミナスのウッドシェルフに35*120がないんだ…
構成考えた後に気づいて鬱…orz

154:デフォルトの名無しさん
05/05/13 02:49:59
誤爆すまん…orz

155:デフォルトの名無しさん
05/05/13 03:19:28
>>151
なんというか・・・そのために文法が複雑になり、パーサーが複雑になり・・・って
そこまでするほどのメリットなのかそれ？

156:デフォルトの名無しさん
05/05/13 03:19:51
パーサーじゃなくてスキャナだな・・・orz

157:デフォルトの名無しさん
05/05/13 04:45:37
粘着してる奴が粘着されてるとか言ってりゃ世話ないな。

158:デフォルトの名無しさん
05/05/13 07:00:58
lex、yaccに手を入れるより新しく作った方がいいんじゃないかと誰も言わないのはなぜ？

159:デフォルトの名無しさん
05/05/13 07:04:32
それ以前の問題だからじゃないか？

160:デフォルトの名無しさん
05/05/13 11:12:25
>>158
何が不満だ？

161:デフォルトの名無しさん
05/05/13 11:50:49
>>160
不満じゃなくてな、変数隠蔽とか以前の時代のソフトに今時の概念入れろとか言うのって不毛じゃないのかって事
そんなメンテナが泣きそうな事するくらいならいっそ１から作るとしたらどうするかって話する方がよかないか？

最近の処理系ならちゃんと備わってたりするし（メジャーじゃないけどさ）

162:デフォルトの名無しさん
05/05/13 12:28:46
なぜかRubyばかり槍玉にあげられてるけど、
Perlのlexer/parserってあんな言語でも実は綺麗なの？

>>155
もちろん主観の問題だけど、Rubyの1ユーザとしては
引数が0個か1個の場合は括弧省略したいかな。
ary.sortとかary.push 1とか。
あと、a [i]やa +1なんて現実的には書かなくない？

163:デフォルトの名無しさん
05/05/13 12:37:10
>>162
そんなんだったらsmalltalk風の呼び出しの方がきれいだと思う。

164:デフォルトの名無しさん
05/05/13 13:01:14
>>163
smalltalkを知らない俺様にもわかるように
5行で説明してくださいおながいします

165:デフォルトの名無しさん
05/05/13 13:15:39
anObject hoge: arg1 page: arg2 fuga: arg3.

166:デフォルトの名無しさん
05/05/13 13:25:01
>>162
>Perlのlexer/parserってあんな言語でも実は綺麗なの？

知らないけどPerlが汚いからといってRubyが汚くないという話にはならないでしょ

>もちろん主観の問題だけど、Rubyの1ユーザとしては
(中略)
>あと、a [i]やa +1なんて現実的には書かなくない？

いや、だからメソッドの括弧省略のために作者自らわざわざスキャナを複雑にしてるんだよね、
それほどまでにメソッドの括弧省略にメリットがあるのかなと思ってさ・・・
あと現実には書かなくてもやっぱりスペースの位置だけで動きが変わるのは混乱の元だと思う。

167:デフォルトの名無しさん
05/05/13 13:36:47
>>165
セレクタとかある時点で比較対象になってなくない？

>>166
なんでRubyばっかり槍玉にあがるのかな、って。
RubyがRubyが言ってるのみると、
アンチRuby厨の戯れ言にみえてしょうがないんだよね。

メリットがあるかどうかはやっぱり主観によるけど、
混乱の元だと思う人がいるのは理解はできる。

168:デフォルトの名無しさん
05/05/13 13:59:34
>>167
そんなにRubyの話ばかりされるのが嫌なら他の話題を振ればいい

169:デフォルトの名無しさん
05/05/13 14:38:09
>>167
lexとyaccが協調動作することの是非や方法の話題はおもしろいのに
いちいちRubyの場合ばかり持ってきてRubyを叩くアンチがうざいのには同意。
そしてそれにいちいち反応するRuby信者もうざいぞ。

170:デフォルトの名無しさん
05/05/13 14:50:12
つか、TMTOWTDIを目指してる言語の字句構文解析が複雑なんて
神が文法設計しないかぎり、当たり前じゃないの？

171:デフォルトの名無しさん
05/05/13 17:55:12
>>164
嫌です

172:デフォルトの名無しさん
05/05/13 18:31:44
>>162
> あと、a [i]やa +1なんて現実的には書かなくない？
ギャハハ、腹痛ぇｗ

173:デフォルトの名無しさん
05/05/13 18:56:53
なんか先日の重複スレ以来あれてるなぁ。

174:デフォルトの名無しさん
05/05/13 19:12:20
なんかこの分野の議論ってすぐ「勝負」になるんだよね。

「俺の方が深く理解してるぜ。お前は全然分かってない。大馬鹿野郎だ」

みたいな。仲良くやっていきたいものだが。

175:デフォルトの名無しさん
05/05/13 19:15:15
>>174
2ちゃんねらって、誇れるものをあまり持たない人が多いような気がします。
だから、そうなるのでしょうね。

176:デフォルトの名無しさん
05/05/13 19:36:23
結果として複雑になったのならともかく自らわざわざ複雑にしてしかもそれに見合うメリットが見当たらないのはどうかと

177:42
05/05/13 20:46:09
>>162
>Perlのlexer/parserってあんな言語でも実は綺麗なの？

最初にRubyを出したのは俺だけど、Perlを出さなかったのは、Perlは
あまりにソースが読みにくくて読むのを断念したからだ w
だから、parserがlexerにどれくらいちょっかい出してるのかも知らない。
「Rubyソースコード完全解説」に相当する日本語解説もないしね。

別にアンチRubyってわけじゃないよ。>>150だって、推測だけどたぶん
ふだんはCとかJavaとかC++とかC#とか使ってて、たまたま>>126のリンク見て
びっくり仰天なんじゃこりゃ、と思っただけだと思うよ。
なんでもかんでもアンチだの信者だのにしたがる方こそ病んでないか。

ところで、メソッド呼び出しの括弧が省略できるのは、
「引数がひとつもないとき」は明らかなメリットがあるよな。
ひとつでも引数があるのなら、括弧ぐらいつけりゃいいじゃん、と
俺は思うけど。文末のセミコロンもね。

>>174
というわけで俺はアホだから、>>47の
>むしろ変数で情報を渡すよりカプセル化に有益なんでは。
>それ以後%startと整合性をとる必要を生じる

という発言の趣旨を>>52以来ずーっと教えて欲しいと思ってるんだが。

178:デフォルトの名無しさん
05/05/13 21:11:42
俺も括弧くらい付けりゃ良いじゃんと思う

文法は厳格かつ単純な方が好きだな
if-then-else の else が省略出来ないとか、四則演算に優先順位が無いとかでも問題無し

179:デフォルトの名無しさん
05/05/13 21:54:46
LISPがオススメ
究極の汎用プログラミング言語

180:デフォルトの名無しさん
05/05/13 22:00:28
もうお前ら、forth でも使ってりゃいいよｗ

181:デフォルトの名無しさん
05/05/13 23:32:47
括弧を省略できるってのは結構大きいよ。

>>178
単純で、四則演算に優先順位が無くてもOK

あなたにオススメの言語はHSPです。よかったね。

182:デフォルトの名無しさん
05/05/13 23:33:32
HSPは言語ではありません。
以後、HSPの話題はゲ製板で行ってください。

183:デフォルトの名無しさん
05/05/13 23:36:34
HSPに対する反応はぇぇぇぇぇぇぇぇぇ！

>>182

そんなあなたにオススメの言語はHSP3です。

コレは優先順位つくらしいよ。よかったね。

184:デフォルトの名無しさん
05/05/13 23:36:55
言語といえば、LISPりんごですよ！

185:デフォルトの名無しさん
05/05/13 23:41:33
LISP も HSP も大して変わらないよ。

ものは試しに、
LISP
↑この横棒を少し上に持ち上げてご覧

直ぐに HSP に変わるから。

186:デフォルトの名無しさん
05/05/13 23:45:57
文法の話とかしだすと宗教戦争になるから駄目だな(わら

187:デフォルトの名無しさん
05/05/14 00:16:37
評価するならヒューマンインターフェース的な評価手法を採るべきだ

188:デフォルトの名無しさん
05/05/14 06:23:37
日本語で懇切丁寧に解説してあるのを読んで「ソースコードを読んだ」と威張り、
ソースコードを読めないとコーディングの汚さのせいにし、
Rubyを読んだ程度でさも様々な言語のソースコードを読んだように振舞う42の
いるスレはここですか?

189:デフォルトの名無しさん
05/05/14 06:57:53
Rubyのソースが糞なのは、言語仕様側も少なからず影響してるからなあ・・

190:デフォルトの名無しさん
05/05/14 06:58:42
あ、すまん。
糞なのは、は言い過ぎた。
汚く見えるのは、に読み替えてね。
つい本音が出てしまった。

191:デフォルトの名無しさん
05/05/14 07:06:35
Rubyは入門者用のソースの解説本があるから、ソースを覗いた人は一番多いんじゃないかい。
悪口いいっぱはともかく、言語の規模考えても、準拠ポイントとしてはちょうどいいんじゃないか。

192:デフォルトの名無しさん
05/05/14 07:19:18
なんでわざわざ入門者用に糞ソース読む本が出たんだろうね。
本という形態だとすでにバージョン的に無意味になってる部分も多いだろうし。
Rubyの動作原理ならともかく、糞ソース読む練習に良いとか？

193:デフォルトの名無しさん
05/05/14 07:23:59
>括弧を省略できるってのは結構大きいよ。

なんつーか、ad hoc 感ブリバリで好きになれないな

194:デフォルトの名無しさん
05/05/14 07:53:49
現実問題、実用レベルに達した処理系で
「ソースが糞」じゃないプロジェクトなんてあるの？

195:デフォルトの名無しさん
05/05/14 07:55:25
>>192
> Rubyの動作原理ならともかく、糞ソース読む練習に良いとか？

あの本、能書きにはそれっぽく書いてある。だけど実際の本文は
「わかった奴が教えを垂れる」スタイルなんで、あんまり
ソースの読み方の参考というのにはならない。

前提となる知識が先に書いてあるのは別にいいんだが、何をとばして何を読む
ってのが説明の都合で決まりすぎで、ソースの読み手から見た判断という視点
じゃない。

196:デフォルトの名無しさん
05/05/14 10:40:28
>>185
ﾎﾝﾄﾀﾞw
I-I S P

197:デフォルトの名無しさん
05/05/14 10:41:29
偶然の一致がこれほど恐ろしいとは

198:42
05/05/14 12:19:46
念のため書いとくけど、Rubyのソースが全編糞とは俺は思ってないからね。
eval.cのsetjmp/longjmpの乱用と、parserとlexerがグローバル変数で
状態を共有してるのがひどいと言ってるだけ。他はまあ、普通のCソースだと思う。

>>188
>ソースコードを読めないとコーディングの汚さのせいにし、

Perlのソース読んだことあるかい?

199:42
05/05/14 12:39:23
補遺：
setjmp/longjmpの乱用についても、実行形態を考えるとやむを得ないところは
あるんだよな。
いっそバイトコードインタプリタにでもした方がよかったんじゃないかとも
思う。そうするとGCも今のコンサバGCじゃなくなって、もはや原型をとどめなく
なりそうだが。

200:デフォルトの名無しさん
05/05/14 15:42:13
ﾌﾟﾌﾟﾌﾟﾌﾟﾌﾟこのスレおもしれー。
Perlのソースコードが汚いって?
少なくともRubyが***自力で***読めてPerlが読めない理由はねえよ。
てめえのおつむが足りないってことを精一杯開陳しつつしかも自分では
認めないって、最悪じゃね?

しかもいっちょまえに批評家気取って、はーｹﾞﾗｹﾞﾗｹﾞﾗ
しかもえらそうなくせに何言ってるかわかってなさげなﾄﾝﾁﾝｶﾝぶりがﾗﾌﾞﾘｰ

201:デフォルトの名無しさん
05/05/14 15:44:11
>>200
ソースは汚いと思わないが、build課程はかなりひどい物の一つだと思うぞ。

202:デフォルトの名無しさん
05/05/14 17:01:52
Perlのは暗号だからな、読む気にもならん

203:42
05/05/14 19:50:57
そもそも俺は自分はアホだと再三言ってるんだがねえ。
何がそんなに気に入らないんだか。

>少なくともRubyが***自力で***読めてPerlが読めない理由はねえよ。

へえ。

Rubyのソースが間違いなく***自力で***読める人のご意見。

URLﾘﾝｸ(jp.rubyist.net)
| Perl のソースコードは印象的だよね。すごい。読めない。
| マクロの嵐で、よくわからない識別子が山のように出てきて、
| いったい何？　みたいな、すごい略語でさぁ。ほんとに、名前重要。]
| この識別子は、何を表しているのか、何をしようとしているのか、
| わかんないんだよ。

204:デフォルトの名無しさん
05/05/14 20:02:36
そりゃ自分で書いたコードなんだから読めるだろ。
それが論拠になると本気で思ってる? 痛い奴。

205:デフォルトの名無しさん
05/05/14 20:20:43
>>203
>>53

206:デフォルトの名無しさん
05/05/14 22:53:41
>>194
その通り！
めずらしく、いい書き込みだなw

207:デフォルトの名無しさん
05/05/14 23:33:01
だから、Perlが汚いからといってRubyが汚くないという話にはならないの
ことあるごとにPerlをもちだしてくる信者はいい加減にしろ

208:デフォルトの名無しさん
05/05/14 23:44:40
Ocamlのソースは綺麗だったよ
実用レベルなのか知らないけど

209:デフォルトの名無しさん
05/05/15 00:04:59
>>208
高速な事は事実。

210:デフォルトの名無しさん
05/05/15 01:17:27
OCamlのソースはコアのインタプリタ以外OCamlで書かれてるからね。
Cで処理系書いてる限りソースが糞になるのはやっぱり避けられないのかも？

211:デフォルトの名無しさん
05/05/15 01:22:45
LISPも、というか関数型言語は綺麗なソースが多い気がする。
それぞれの言語自身で記述する風習みたいなのがあるからかね。

212:デフォルトの名無しさん
05/05/15 02:02:08
関数型言語に限らずbootstrapしてない言語処理系なんて
表現能力のなさを露呈してるようなもんじゃないかな。
WindowsをUnixで作ってるみたいな。
SubversionのソースをCVSで管理してるみたいな。
もちろんスクリプト言語のように目指すところが違えば話は別だけど。

213:デフォルトの名無しさん
05/05/15 03:37:32
>>211
SBCL は C の部分が汚くて悶絶した

214:デフォルトの名無しさん
05/05/15 03:45:28
そうか? 普通に読めたけどなあ。SBCL。

215:デフォルトの名無しさん
05/05/15 03:59:02
読めるけど、エラー処理省いてたり、マジック文字列埋め込んでたり、バータリ的な所が
けっこうあったよ。-Wall 付けてビルドするとやたら Warning が出るし。
たまにクリーンアップのパッチが提出されてるけど、マージされてるのか疑問。

216:デフォルトの名無しさん
05/05/15 07:41:04
すれ違いですまんが、「バータリ的」って何？

217:デフォルトの名無しさん
05/05/15 07:44:34
場当たり的

218:デフォルトの名無しさん
05/05/15 08:24:59
>>217
サンクス。

人の名前かと思ったんでﾜｹﾜｶﾗﾝ様になってた。

219:デフォルトの名無しさん
05/05/15 11:39:02
>>212
ブートストラップの意味おしえて

220:デフォルトの名無しさん
05/05/15 11:40:28
>>219
ストローストラップの弟

221:デフォルトの名無しさん
05/05/15 13:08:41
コンパイラ業界でのbootstrapは、
コンパイラが自分自身のソースをコンパイルすること。
(だよね？

222:デフォルトの名無しさん
05/05/15 13:38:45
話の流れを折ってすいませんが、
Engineering a Compiler
URLﾘﾝｸ(www.amazon.com)
ってどんなもんでしょうね?

223:デフォルトの名無しさん
05/05/15 14:56:04
>>222
☆☆☆☆★
初学者はドラゴンブック嫁って事になってるの？メリケンでもいまだに。ちょっと安心していい？

224:219
05/05/15 17:24:53
>>221
TNX!

225:デフォルトの名無しさん
05/05/15 17:38:46
ネタにマジレスかもしれないが、ストローストラップって誰？
ひょっとしてストラウストラップのこと？
ストローストラップって発音することがあるの？

226:デフォルトの名無しさん
05/05/15 17:44:52
アメリカ<=>イギリス

227:デフォルトの名無しさん
05/05/15 17:45:00
URLﾘﾝｸ(www.research.att.com)

228:デフォルトの名無しさん
05/05/15 18:05:33
ステューステュオップ

229:デフォルトの名無しさん
05/05/15 18:08:30
いい声してるなあ

230:デフォルトの名無しさん
05/05/15 18:11:32
>>228
耳腐ってんのか？

ステゥーステュオァプ

231:デフォルトの名無しさん
05/05/15 18:21:41
「C++でお勧めの本ありますか？」
「ステゥーステュオァプでも読んどけ」
「……宇宙人？」

232:デフォルトの名無しさん
05/05/19 14:36:35
練習で、生成系を使わずにCのプリコンパイラを作ろうと思っているのですが、
ソースコードの意味解析をやる必要があるかどうかが直感的にわからなくなってしまいました。
#define文は型検査をする必要はないので、いわゆる意味解析の必要ってない気もするのですが、
プリコンパイルはそれはそれで一つの言語であるので、どこかで意味解析が必要になりそうな気もします。

実際に必要なのかどうなのか、簡単な理由と共に教えてもらえないでしょうか？
どうぞよろしくお願いします。

233:232
05/05/19 15:30:19
プリコンパイラってなんだ…プリプロセッサですね…

234:デフォルトの名無しさん
05/05/19 16:26:45
なんで既存のプリプロセッサを読まないんだろう……

235:デフォルトの名無しさん
05/05/19 16:30:36
俺様と同じように言葉だけ覚えてほとんど理解できてない感じのレスだな。
そんな俺様が勘で答えてやろう。

C言語本体としての意味解析はいらない(と思う、というか構文解析もできないだろう)。
マクロ言語としての意味解析はいるかもしれない。
ただ、Cのマクロ言語は本当に簡単な言語なので、
構文解析まで通れば意味解析はほとんど何もすることが
ないかもしれない。ひょっとしたらあるかもしれない。

236:235
05/05/19 16:32:40
あ、あれ？既存のプリプロセッサを読めとか
そういうレベルの話なの？
やっぱり全然見当違いのレスしちゃったかも。
ごめん、なかったことにしてくれ。

237:232
05/05/19 17:22:08
>>234
直感ですが、cppやgccのpre-processorのコードは高速化のために最適化されていて、
私みたいな知識のない人間が追うには辛いのではないかと思っていました。
反省して読んでみることにします。

>>235
まさにそういう感じです＜言葉だけ覚えてほとんど理解できてない。
理解するために簡単そうに見えるプリプロセッサを作ろうと思ったのですが、
作る前に色々と考えていたら意味解析のセクションが必要なのかどうかがわからなくなって…
とりあえず、プリプロセッサの意味規則がどんなものかを考えることが重要なのですね。

まだ紙の上で考えている状態なので、具体的にどのような構文木を出せばよいのか、
そこのところで悩んでいる途中で出た疑問でした。
わかっていない私にわかりやすく説明してくれてありがとうございました。

238:デフォルトの名無しさん
05/05/19 21:07:54
情処かどっかで
世の中のCのプリプロセッサはバグだらけ
みたいな論文を見たような気がする。

239:232
05/05/19 21:50:18
仕様はかなり細かいみたいですね＜プリプロセッサ
（あくまで参考として：URLﾘﾝｸ(www.sra.co.jp)）

240:デフォルトの名無しさん
05/05/19 22:15:21
>>232
小さいCPP（１ファイルに収まるくらいのやつ）が入ってるよ
URLﾘﾝｸ(www.lsi-j.co.jp)

241:デフォルトの名無しさん
05/05/20 02:20:54
このスレにはソースを読めばなんでもわかると思ってるやつしかおらんのか。

242:デフォルトの名無しさん
05/05/20 03:23:19
ソース読まない奴は無能

243:デフォルトの名無しさん
05/05/20 05:55:55
仕様書にはいつもソース読めと書いてます。
結局ソース見るのが一番早い。

244:デフォルトの名無しさん
05/05/20 09:44:15
>>243
10行くらいならね。

245:デフォルトの名無しさん
05/05/20 17:22:18
JavaやVBAのパーサを書いて見たいんですが、どっかにgrammarでも落ちていないですか？

246:デフォルトの名無しさん
05/05/20 17:44:30
Javaならあるよ。VBAは知らない。
URLﾘﾝｸ(java.sun.com)

247:デフォルトの名無しさん
05/05/20 18:57:23
レスサンクスです。
早速構文チェッカーでも書いてみます。
やはりC++より構文規則は見た目きれいですね。
C++の構文はどこもかしこもオプションだらけでよくJavaプログラマが汚いという意味がよくわかりました。
私もC++パーサを書いたあと、しばらくはC++でプログラムしなくなりました。

248:デフォルトの名無しさん
05/05/20 21:23:32
>>238
たぶんこれだろ。
URLﾘﾝｸ(lc.linux.or.jp)
URLﾘﾝｸ(www.ipa.go.jp)

249:デフォルトの名無しさん
05/05/20 22:49:23
>>247
その意見には激しく同意した上で、なおかつC++が最高の言語だと思う自分がいる

250:デフォルトの名無しさん
05/05/20 23:17:35
なんか、俺はプログラミングするたびに違う言語使ってる気がする。
統一したほうがいいのだろうか。

251:デフォルトの名無しさん
05/05/20 23:24:33
またScheme処理系作っちまった
やめられない

252:デフォルトの名無しさん
05/05/20 23:27:55
同じ物ばかりつくって飽きないの？

253:デフォルトの名無しさん
05/05/20 23:35:07
もうとまらねーよ

254:デフォルトの名無しさん
05/05/20 23:39:04
>>252
Scheme処理系は何個あっても困らないからねえ

255:デフォルトの名無しさん
05/05/21 00:54:16
JVMで動くCOBOLを作ってみてくれ。

256:デフォルトの名無しさん
05/05/21 00:55:17
お前ら、もっと斬新なことしてくれよ
実装なんか興味ないからさ。

257:デフォルトの名無しさん
05/05/21 01:18:36
タガログ語プログラミング言語とか。

258:デフォルトの名無しさん
05/05/21 01:33:11
>>251
公開キボンヌ

259:デフォルトの名無しさん
05/05/21 01:33:48
面白いこと＝トロイ
な頭の俺をどうにかしてください

260:デフォルトの名無しさん
05/05/21 01:35:50
>>256
そんなあなたに「りんg（ry」

261:デフォルトの名無しさん
05/05/21 01:50:59
プログラムを2つ与えると、その実行結果が等価になるか判断する処理系作って。
用途は、たとえば自分でソートのプログラムを作ったけど正しいか自信が無いときに、
単純で遅いが明らかに正しいソートプログラムと比較させる。
全自動は無理だと思うから、人間が色々手伝ってもかまわない。
「入力の長さnの帰納法」とかヒントをあげると、少なくてもn=1のときは
単純にn=1が保証されるものとして最適化するだけで判定できそうな気がする。

262:デフォルトの名無しさん
05/05/21 01:54:55
>>261
どうやらスレ違いぽいな

完璧なプログラム
ｽﾚﾘﾝｸ(tech板)

263:デフォルトの名無しさん
05/05/21 09:35:34
>>251さん、リクエストします。
JavaScriptでScheme処理系を書いてください

264:デフォルトの名無しさん
05/05/21 10:38:57
>>261
しかも、内容が馬鹿っぽいｗ

265:デフォルトの名無しさん
05/05/21 10:59:05
一般的にはムリって
計算論で結論出てなかったっけ？

266:デフォルトの名無しさん
05/05/21 11:05:29
>>261
少なくとも、理論上無理。そんなことができるなら、世の中もっと幸せになってる。

267:デフォルトの名無しさん
05/05/21 11:51:13
>>251
>>263をR5RS準拠でﾖﾛｽｸ

268:デフォルトの名無しさん
05/05/21 14:49:33
プログラムが停止するかどうかすら判定できない、じゃなかったかなあ。

269:デフォルトの名無しさん
05/05/21 15:08:56
>>268
「有限時間内で」が大事。

270:デフォルトの名無しさん
05/05/21 15:25:18
>>261は最初から「全自動では無理」と言ってるんだが…
理論上無理とか言ってるやつは
proof assistantというものが存在することすら知らんのだろうな。
いずれにせよ>>262の言うとおりスレ違いだろう。

271:デフォルトの名無しさん
05/05/21 16:19:22
>>251 氏
後学の為に是非公開してくださいませんか。宜しくお願いします。

272:デフォルトの名無しさん
05/05/22 00:51:20
schemeの処理系なんて、重厚長大で完璧めざしてるR5RS準拠から
読みやすさ重視orお遊びのトイプロジェクトまで、山ほどあるぞ。

273:デフォルトの名無しさん
05/05/22 07:48:12
>>271
R5RS規格書は50ページ程度と言われてるけど内容濃いしね
省かれた暗黙仕様もあるから準拠しようとすればそれなりに工数掛かる

>>267
おれが今回作ったのは継続もなくスタックベースでそもそもRxRS前提に書いてない
throwみたいに親側へ飛ぶだけだし、スタックオーバーフローもする
ちゃんとしたのは別にあるんだけど、デカくなりすぎた
そこそこの速度で動く＆俺言語やアプリへの組み込みが目的だった
俺言語2k行ぐらいで最低限の最適化だけやったいい加減なやつ
速度はguile1.7.2と同じぐらい。。。guileは速度捨ててるね

274:デフォルトの名無しさん
05/05/22 08:52:51
>>273
おー、俺言語大好き人間って結構いるんだな
俺はSelf系つかprototype系好きなんで何個も作ったけど、Schemeは一度も作ったコトないや

275:デフォルトの名無しさん
05/05/22 16:33:47
俺言語への組み込みScheme？
どんなものか想像できない。

276:デフォルトの名無しさん
05/05/22 16:49:51
よくあるパターンは、scheme式をbuiltin型として使えるというものかな。
prologを組み込むと時々便利。

277:デフォルトの名無しさん
05/05/23 16:39:26
Scheme in javascriptやin rubyを作ってるんだけど、
何かの仕様に準拠しないと達成感がない。

でもRxRSの複素数とかくだらないの実装するのは面倒くさい上に、
母言語(javascriptとか)の数値表現がそのまま使えなくなって
滅多に使わないのに全体的に遅くなりそうなあげく、利便性まで下がる。

同じことで悩んだor悩んでるやついる？

278:デフォルトの名無しさん
05/05/23 18:49:26
>>277
つcoercion semantics

279:デフォルトの名無しさん
05/05/23 19:22:56
Coercin semantics？ってsubtypeに基づく変換とかのアレですよね。
Schemeに型はないんですが、soft-typingしろってことでしょうか。

誤解があったかもしれないので捕捉。
Scheme in javascriptってjavascriptで書かれたScheme実行エンジンを意図してました。
i = scheme_eval("(+ 1 2)");
みたいに実行できるようなの。これでiには普通の3が代入されるか、
自分で定義したclass SchemeNumberのインスタンスが入るか、が問題です。
前者が嬉しいけど、複素数とかの対応はどうするべきかな、と。

280:デフォルトの名無しさん
05/05/23 22:06:51
>>275
俺言語との通信やプリプロセッサの拡張とか
funclist.scm：((f 1) (g 2) (h 3))
俺言語：
#s (define func-list (with-input-from-file "funclist.scm" read))
#s(for-each (lambda(x) (puts x "() { printf(\"myname:" (car x)
"\\n\"); return " (cadr x) "; }")) func-list)
register_func() {
#s(for-each (lambda(x) (puts "scm_add_proc(\""(car x)"\", (scm_proc_t)"(car x)", 0);"
" printf(\"defined:"(car x)"\\n\");")) func-list)}
main() {
register_func();scm_write(scm_eval_string(#ss`(+ ,@(map(lambda(x)(list(car x))) func-list))));;scm_newline();}
↓
f() { printf("myname: f \n"); return 1; }
g() { printf("myname: g \n"); return 2; }
h() { printf("myname: h \n"); return 3; }
register_func() {
scm_add_proc("f", (scm_proc_t)f, 0); printf("function defined:f\n");
scm_add_proc("g", (scm_proc_t)g, 0); printf("function defined:g\n");
scm_add_proc("h", (scm_proc_t)h, 0); printf("function defined:h\n");
}
main() {
register_func();scm_write(scm_eval_string("(+ (f) (g) (h))"));scm_newline();}
↓
function defined:f
function defined:g
function defined:h
myname: h
myname: g
myname: f
6

281:デフォルトの名無しさん
05/05/23 22:09:36
>>279
おれだったらevalの結果をそのままwriteできるようにする。
結果が数値だけとは限らないので。
scheme_write(scheme_eval(scheme_read()));
もしくは
scheme_write(scheme_eval_string("(+ 1 2)"));
経験的に特に明示しない限りschemeならschemeの型で持ちまわる方が都合良い。

282:デフォルトの名無しさん
05/05/23 23:45:06
>>280
イラネw

283:デフォルトの名無しさん
05/05/23 23:50:14
綾本って思いっきり中田さんの授業配布プリントに
説明を加えただけにしか見えないのだが。

284:デフォルトの名無しさん
05/05/23 23:55:31
そう言われても俺には確かめようが無い

でも中田先生の教科書は(・∀・)ｲｲ!!

285:デフォルトの名無しさん
05/05/24 00:41:48
>>281
>schemeならschemeの型で持ちまわる方が都合良い。
処理系の作成者としては当然その通りで、気持ちもわかるんだけど、
処理系のユーザとしては不便だと思うんだよね。
いちいちscheme_number_from_javascript_number(1)とかしなきゃならんのは。
どうにかならんかな、みんなどうしてるかな、って疑問でした。

次ページ