【数学者】Haskellはクソ言語【オナニー】

【数学者】Haskellは� ..

166:デフォルトの名無しさん
06/06/03 18:55:27
Haskellって、アルゴリズムを書くには便利そうだけど、
それだけで完結するようなプログラムもありえないので、
ビジネスロジックだけをこれで書いて、ほかの言語から
呼び出せってモノなんでしょ？

もっといえば、ストアドみたいな。

167:デフォルトの名無しさん
06/06/03 19:43:52
>>166
そういう使いかたもあるけど、そのための言語と言う訳ではない。
宣伝文句は「general purpose programming language」だし、
ライブラリの整備もかなりの部分は「全部Haskellで書く」方向に向かっている。

そもそも、なんでロジック以外を書くにはHaskellは不便だと思うんだ？

168:167
06/06/03 19:46:36
自己レス

>そもそも、なんでロジック以外を書くにはHaskellは不便だと思うんだ？
いや、実際不便なんだが、それは主にライブラリの不備のせいであって、
言語がそっちを指向してる訳じゃないと思うがどうよ。

169:デフォルトの名無しさん
06/06/03 20:44:04
>>165
はーい＾＾

170:デフォルトの名無しさん
06/06/04 00:48:32
>168
簡単な解説ページしかみてないので今ひとつ自信はないんだけど、
I/O関係でムリを通そうとしてる雰囲気がほのかに・・・。

そんなんだったら、ほかの言語から呼び出すのにとどめたほうが、
みんな幸せになれそう。

正規表現を拡張して独立したプログラム言語にしようとしてるような、
ミョーな意固地さを感じる・・・。

171:デフォルトの名無しさん
06/06/04 01:59:34
Haskell.NETで何とかならんかな、その辺は。

172:デフォルトの名無しさん
06/06/04 02:13:40
Haskell.NETは間違いなくベーパーウェアのまま終わる

173:デフォルトの名無しさん
06/06/04 16:13:06
C++のメソッドに対するconstってあるでしょ。
あれは、オブジェクトの状態を変えないって意味がある(実際はちょっと違うけど)
SICPにもあるけど、副作用や参照のせいで出てくるバグ(side-effect bug)も、
結構無視できない。

私の場合だけど、
副作用がある部分と、副作用が無い部分を切り分けられないかと思い
様々な言語を探していたらHaskellとかCleanとか(*)に突き当たった。

そのように見れば、IOモナドで副作用を切り分けるのもそんなに違和感が無いんじゃないかな。

(*)研究用の(実用的でない)言語なら他にもあるみたい。
URLﾘﾝｸ(computing-dictionary.thefreedictionary.com)

174:デフォルトの名無しさん
06/06/04 18:11:25
はやくおまいら実用的なライブラリこさえてください。

175:デフォルトの名無しさん
06/06/04 18:47:20
GHCはOpenGL+GLUTがついてるぜ
サンプルコードぐぐってやる気なくしたけど

176:デフォルトの名無しさん
06/06/04 20:12:00
>>170
たぶんIOモナドの事を言ってるんだと思うが、IOをモナドで表すのは
どっちかというと言語の詳細であって、それほどプログラミングのスタイルが
影響を受ける訳じゃない。
たとえ内部が正規表現で出来ていようと、その上で普通にコードがかけるなら
問題ないんじゃないだろうか。

という訳で、別に無理をしていても良いと思うんだが、個人的には
HaskellのIOがすごく無理をしているようには感じられない。うまく言えないけど。

177:デフォルトの名無しさん
06/06/04 20:26:01
しかし、純粋関数的に書いていたコードに副作用を加えたい場合、
let x = ...を
x <- ...
に書き換えたり、
戻り型を a から IO a や State s a に書き換えなければならない事を思うと、
Haskellで書いたプログラムのモジュール性が低いと言えなくもない。

ただ、元々副作用無しで書こうと思っていたコードに、
副作用を加えるというのは、そもそも設計段階で間違っていたとも言える。

ここで言う副作用の例は、性能評価コードや、ロギング等のための、
呼び出しカウント、ファイル出力などを考えている。
でもこういうのは他の代替可能な手段があるかもしれない。

始めからIdモナドで書けばいい、と言ってしまえばそれまでだけど。
この辺の議論ってどっかに書いてないかな。

178:デフォルトの名無しさん
06/06/12 06:41:11
諸君、さらに議論を続けたまえ。

179:デフォルトの名無しさん
06/06/12 07:32:33
そうやって話の腰を揉むのはよせ

180:デフォルトの名無しさん
06/06/12 07:56:57
俺のおっぱい揉んでよ。

181:デフォルトの名無しさん
06/06/12 07:59:16
氏ねデブ

182:デフォルトの名無しさん
06/06/12 11:30:40
議論を再会したまえ。

183:デフォルトの名無しさん
06/06/12 19:07:16
お前ら面白すぎ

184:デフォルトの名無しさん
06/06/13 14:00:58
べつに面白くはないでしょ

185:デフォルトの名無しさん
06/06/14 21:56:33
議論を展開したまえ。

186:デフォルトの名無しさん
06/06/15 22:47:18
おっぱいもまれたい男はデブかどうか。

ピザには間違いない。

187:デフォルトの名無しさん
06/06/17 07:48:34
その議論は終了したまえ。

188:デフォルトの名無しさん
06/06/17 09:40:35
学者様は議論の開始・展開・終了がノンコストで行われると考えてるらしい。
実際の開発では、プログラムの開始・展開・終了の間で
作業者間でのコミュニケーションが行われ、そこのコストがもっとも大きいというのに。

189:デフォルトの名無しさん
06/06/17 13:19:08
じゃあトップが一人で全部設計してあとはコーディングだけすれば
ノンコストだろ。コミュニケーションにコストがかかるとか言ってる
>>188方がDQNだろ

190:デフォルトの名無しさん
06/06/17 14:25:09
>>187
したまえ

191:デフォルトの名無しさん
06/06/17 20:41:33
>>189
俺にはこのボケに対するうまいツッコミが思いつかない

192:デフォルトの名無しさん
06/06/18 09:54:29
今北んだが、何でコミュニケーションのコストの話になったんだ？
誰が学者様なんだ？

コミュニケーションにコストがかかるのは承知だが、
なんでそれをHaskellのスレで議論する必要が？
もっとテクニカルな話しようや

193:デフォルトの名無しさん
06/06/18 10:01:35
俺はテクニックの話はどうでもいい。
研究的内容について議論してくれ。

194:デフォルトの名無しさん
06/06/18 11:58:33
研究的内容って？何を求めているの？

195:デフォルトの名無しさん
06/06/18 15:41:09
>>194
「新規性」だよ

196:デフォルトの名無しさん
06/06/18 23:12:56
このスレで？w
んな高尚なもの求められても。。そういうのは大学のお友達とたっぷり議論するといいよ。

197:デフォルトの名無しさん
06/06/18 23:15:25
第一こんな所に降りてくるネタなんぞに新規なものなど存在しない。
何かHaskellの新しい機能を触ろう、ってんならagreeだが。

198:デフォルトの名無しさん
06/06/19 17:24:47
arrowってモナドと何が違うの？

199:デフォルトの名無しさん
06/06/19 17:34:25
やっとアローズまでたどり着いたか。遅かったね。

200:デフォルトの名無しさん
06/06/19 23:18:19
頭の回転の速さよりもセレンディピティの方が重要だと思う。

201:デフォルトの名無しさん
06/06/21 01:36:11
クソスレでまじめな議論に飢える情報弱者ｗｗｗ

202:デフォルトの名無しさん
06/06/22 06:15:11
新しいものとか、テクニカルなもの、セレンディピティはおおいに結構。
Haskellの超絶技巧なテクニックだとか、こんなアプリをHaskellで書いた！とか、
こんな新しいプログラムの書き方がある！とか
そういう内容でいいんじゃないの

203:デフォルトの名無しさん
06/06/23 00:00:10
>>202
お前このスレ立てただろ。文体からすぐわかんだよ。
自分ひとり選民意識でいるんじゃねぇよ。
↓↓↓

プログラム板から来ました
ｽﾚﾘﾝｸ(php板)

204:デフォルトの名無しさん
06/06/24 15:40:43
議論をレジュームしたまえ。

205:デフォルトの名無しさん
06/06/27 21:48:43
Haskell使える人ってこれからどんどん増えて行くというのに、選民もクソもないでしょ。

206:デフォルトの名無しさん
06/06/28 01:51:37
Haskellは流行りません。研究者の一人として断言します。

207:デフォルトの名無しさん
06/06/28 02:26:49
>>206
理由をぜひ聞きたかったりするんだが…。
これから勉強しようかと思ってるけど、ひょっとして無駄？

208:デフォルトの名無しさん
06/06/28 06:23:53
>>207
自分の「ものの考え方」のバリエーションが広がるだけでも
全く無駄ではないよ

209:207
06/06/28 08:35:59
>>208
あっ、いや、ある程度はもう知ってるのだけど、
Haskellは実用的にも使えるのではないかと思って
標準的な関数の使い方を全て勉強しようかという
矢先に >>206 を見たので…。

210:デフォルトの名無しさん
06/06/28 17:52:27
Haskell は面白いけど、あんまり実用的ではないように見えるなあ。
それほど効率が求められないものや、
あるいはそれほど効率に影響のないプログラムなら問題ないけど、
効率上、副作用は必要悪だと思うなあ。

211:デフォルトの名無しさん
06/06/28 18:10:21
Haskellが遅いのは遅延評価のせいであって、副作用は関係ないだろ。

212:デフォルトの名無しさん
06/06/28 23:24:57
別に商用になるかどうかと流行るかどうかは関係ないでしょ。
書籍も出たことだし、Smalltalkやlisp/schemeに迫る程度には「流行る」かと。
あまり理由も示さずに間抜けな断言をするのは研究者としてどうなんだろう。

あと、副作用があれば参照が使えるので例えば再帰の代わりにforループが書ける。
Cみたいなクイックソートが書ける。副作用は、Haskell自体の遅さというより、
効率的なプログラムが書けるかどうかに掛かってくる、ということを>>210は言いたかったんでは。

213:デフォルトの名無しさん
06/06/28 23:33:02
「Haskellは流行りません」って、Haskellを知らずに言ってるならただの馬鹿だし、
Haskellの利点を踏まえた上でそんなことを軽々しく断言されても…ちょっとアレな人な気がする
どこの馬の骨ともわからん(プログラミング言語の?)研究者が何と言おうと、流行るもんは流行るし。

214:デフォルトの名無しさん
06/06/28 23:55:56
俺も馬の骨だが、Haskell は一般向けには流行らないと思うなぁ。
そもそも流行っている事が最も重要な人は使っていないんじゃないかな。

215:デフォルトの名無しさん
06/06/29 00:12:06
流行らないと「思う」には同意。ただ断言できるほど物を知らないorz

>そもそも流行っている事が最も重要な人は使っていない
これの日本語的な意味がわからん。読めん。

216:デフォルトの名無しさん
06/06/29 01:13:18
「はやっている　＝＝　もっとも　じゅうようなこと」だと　かんがえる　ひとは　つかっていないんじゃないかな。

217:デフォルトの名無しさん
06/06/29 02:45:50
絶対流行らない。
仕様を理解してもらえないと思う。

218:デフォルトの名無しさん
06/06/29 03:20:34
でもさ、むかし、Lispすげー流行ったじゃん？

219:デフォルトの名無しさん
06/06/29 05:28:17
>>212
forループと(効率的に)同等なものは破壊的代入を使わなくても書ける。
Haskellでも破壊的クイックソートは書ける。
リストに対しては書けないけど、これはむしろ当然だろう。

副作用があることと、代入スタイルのプログラミングができることを混同しているように見える。
「必要悪」とされるべきは代入スタイルのプログラミング。
Haskellには副作用は無いけど、代入スタイルのプログラミングをサポートしているから、
これをHaskellが遅い理由にするのはおかしい。

220:デフォルトの名無しさん
06/06/29 05:52:08
便乗質問で申し訳ないんですが、
100MB を超えるような巨大配列を取り扱うような
科学技術計算でも大丈夫ですか？
参照透明性ということで、配列要素を一部分変更するたび毎に
配列の全コピーし直してるのかと思っているのですが大きな誤解ですか？
どうしても副作用のあるコードを書きたくなってしまいます。

221:デフォルトの名無しさん
06/06/29 06:12:19
>>220
Haskellの配列は二系統あって、一つが変更毎に完全なコピーを作るIArrayインタフェースで、
もう一つがコピーなしで破壊的操作ができる代わりにモナドを通した操作しか認めないMArrayインタフェース。
だから、この点に関しては問題ない。科学技術計算をする上で他に障害が無いかは保障しかねるけど。

222:デフォルトの名無しさん
06/06/29 06:40:16
>>221
MArray インターフェースですか。
そういうのが有ったんですね。それで勇気が出ました。とっても重要な情報です。

多分、他には根源的な支障はないと思います。
あともう一つ高速化手法として
最近流行の並列プログラミングもしたいのですが、
こっちは Haskell ではまだまだの段階なのかな？と勝手に思っています。

223:デフォルトの名無しさん
06/06/29 08:38:35
>副作用があることと、代入スタイルのプログラミングができることを混同しているように見える。
IORef等への参照セルへの代入は「副作用」として知られていますが何か？
少なくとも空間効率を意識したプログラミングは副作用がないとできない。と思う。
時間効率についてはオーダーの議論で逃げればいいけど。

224:デフォルトの名無しさん
06/06/29 08:43:28
>絶対流行らない。
>仕様を理解してもらえないと思う。
C++のバッドノウハウ集や、Javaの複雑なgenericsを理解できるなら、
Haskellの多相型や型クラスを理解するのはそう難しくはないでしょ。
GoFのVisitorやMementoパターンが理解できるなら、高階関数を使いこなすのも特に問題ないかと。
どれも一時期流行したもの。

Haskellが凡人に理解できないと思うのは、それこそ選民意識じゃない？

225:デフォルトの名無しさん
06/06/29 09:11:42
>IORef等への参照セルへの代入は「副作用」として知られていますが何か？
言葉遣いの問題だが、副作用ってのは「関数適用や式の評価に際して計算以外のことを行うこと」
であって、IORefの操作はこの定義に当てはまらないので副作用とはいえないと思う。
そのためにわざわざ「代入的プログラミング」という言い方をしたんだが。

>少なくとも空間効率を意識したプログラミングは副作用がないとできない。と思う。
>時間効率についてはオーダーの議論で逃げればいいけど。
言葉の問題を除いて、同意。

226:デフォルトの名無しさん
06/06/29 15:06:19
IORef とかって、IORef とかを取り除く時にコピーが発生するんじゃないの？

227:デフォルトの名無しさん
06/06/30 01:40:42
でもまあ、Haskellで科学技術計算なんてCに比べると10倍以上遅いんで、
する気にならないですけどね。

228:デフォルトの名無しさん
06/06/30 05:45:34
>>227
あ～。いいんですよ。とりあえず速度は。
最終的にどんな感じのプログラムになるか実際に見てみたいんですから。
それに計算対象や入力によって速度をそれほど気にしない場合もありますし。

229:デフォルトの名無しさん
06/06/30 08:10:05
C言語でカリカリにチューニングした速い実装を書いて、
Haskellでさくっとかいた実装の出力と比較して検算する (Nバージョンプログラミング)
というのはアリかもしれないね。

230:デフォルトの名無しさん
06/06/30 08:26:59
>言葉遣いの問題だが、副作用ってのは「関数適用や式の評価に際して計算以外のことを行うこと」であって、
わざわざ反論するのも面倒だけど、言葉使いの話をするならば、反論させてもらう。
何度も書くが、副作用(side effect)ってのはIORefへの代入も含むと一般に考えられている。
例えばSICPで、Schemeに代入の機能を入れる所で、side effect bugという言葉が出てくるし、
何より IORefを扱うモナド IOモナドは「副作用」を扱うモナドじゃないか。
IOモナドやState使わないと代入は純粋関数的に書けないでしょ。

適当にぐぐっただけでも(Cleanのマニュアルだが)
URLﾘﾝｸ(sky.zero.ad.jp)～zaa54437/programming/concepts/index3.htm#a6
>代入は、純粋な関数型言語では排除されている。というのも、代入演算子は副作用(side effect)を
>伴う為、参照透明性(referential transparency)が破壊されてしまうからである。

「狭義の副作用」という言葉があるのかどうかは知らないが、一般には代入も副作用と考えられている。

231:デフォルトの名無しさん
06/06/30 09:46:16
>>230
誤解を招く言い方だったが、俺が指摘したかったのはそこじゃない。
>何より IORefを扱うモナド IOモナドは「副作用」を扱うモナドじゃないか。
違う。「入出力」を「副作用なしで」扱うモナドだ。
ここで言う「入出力」にはIORefの操作なんかも含める。

なんでこの区別にこだわるかというと、
・>>210は「Haskellに副作用が無い」という前提で話している。
　だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。
・unsafePerformIOなどによって導入される本物の副作用との区別ができたほうが良い。
という理由から。

232:デフォルトの名無しさん
06/06/30 12:27:10
ああ、言いたいことは分かったよ。

IOモナドは副作用を陽に扱わない。
Haskellは、副作用を表現するIOモナドを純粋関数的に「繋いで」、mainとして定義するスタイル。
繋いだアクションが逐次実行されることで、実行形式は副作用を伴うプログラムとして動作する。
一方、unsafePerformIO はIOモナドとは違い、Haskellの遅延評価のステップの途中で
本当に「副作用的に」評価される(純粋関数の枠を壊している)。
それを言いたいのは分かった。

>・>>210は「Haskellに副作用が無い」という前提で話している。
>　だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。
どうしてその前提が読み取れるのか分からんけど。
というか明らかに IOモナドを副作用を扱うモナドでそ。unsafePerformIOと区別したいのは分かったが。
Haskellで副作用を表現できることはもはや常識なわけで、
「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか？」
という風に読んだ。

233:とおりすがり
06/06/30 22:38:41
・形式的にはHaskellのソースコードの中に副作用を伴う要素は無いものとみなせる。

・副作用をいわば「ランタイム側に追い出す」ための仕組みがIOモナド。
　そういう意味でIOは副作用を扱っているといえる。

（・でも本当に副作用を持つ禁断の関数も実はある。）

ってことでFA?

状態機械の仕様をフローチャート的にではなく構成的に
定義できるのってキモチイイな
do構文使ってると普通の逐次処理言語とあまり変わらないけど。
まあ気分の問題で。

234:デフォルトの名無しさん
06/06/30 23:03:53
>do構文使ってると普通の逐次処理言語とあまり変わらないけど。
そう。というかlet文も考えようによっては逐次型っぽい。

for文やwhile文がなくて、オブジェクトのアップデートができない事を除けば、
手続き型言語も関数型言語もそんなに変わらない。
更にHaskellは純粋関数的なので順序を気にしなくていいんだけどね。

235:とおりすがり１
06/06/30 23:52:32
fib = 1:1:zipWith (+) fib (tail fib)
= 1:1:2:3:5:8:12 ....

これはおなじみHaskell版フィボナッチ数列
遅延評価の例として一度はお目にかかるという。

これはリストのある要素の値を
遅延評価を利用して
同じリストの手前の要素から構成しているのがミソ。

#解説は「フィボナッチ Haskell」でググるといっぱいでてくるので略

236:とおりすがり２
06/06/30 23:55:06
で話かわってmain関数の値の話。

これって要するに最終的には

main = (IO a) >>= (IO b) >>= (IO c) >>= (IO d) ......

というふうに(IO x)を>>=でつないだ数珠繋がりに簡約されるわけで。

(IO x)中にはキー入力とか、画面出力とか、メモリの上書きとか
逐次処理言語の命令コードやサブルーチンのようなものが詰まってる。

>>232とかで言ってるアクションてやつ
ちなみに(return x)で作った(IO x)はNOP（何もしない）が入ってるとみなす。

237:とおりすがり３
06/06/30 23:59:14
>>236のミソは
ループや分岐に相当する(IO x)は無いってこと。

なぜそれでこまらないのかというと、

フィボナッチ数列のときに
ある要素を決定するのにそれより前の要素の値を利用したように

条件分岐で次の処理として(IO y)を繋げようか(IO z)を繋げようか決めるのに
それより前の(IO x)の値をみて決める事ができるから。
あるいはそこで打ち切ってプログラムを終了してもいい。

つまり、Haskellで副作用のあるプログラムを書くってことは

フィボナッチ数列を定義するように
コマンド列を定義しているようなもの

238:とおりすがり４
06/07/01 00:03:08
とまあ
そういう風にオイラは理解したわけです。

239:デフォルトの名無しさん
06/07/01 06:11:52
合ってると思うっす。

240:デフォルトの名無しさん
06/07/01 06:30:18
>>232
>どうしてその前提が読み取れるのか分からんけど。

>「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか？」
>という風に読んだ。

そう読めるのに気付かなかった。

入出力のことを副作用と呼んでるようだが、副作用とは式の簡約の過程で入出力を行うことであって、
入出力そのもののことではないだろ。
それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか？

多くの言語では、入出力を扱う唯一の方法が副作用なわけで、入出力と副作用を混同してもさして問題はないだろうが、
そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。

>というか明らかに IOモナドを副作用を扱うモナドでそ。
>>231に書いたように「副作用なしで」IOを扱うためのモナド、とするのが普通だと思う。
How to declare an imperativeから引用
>This section relates the monad approach to input-output to four other widely used
>approaches: synchronised streams, as used in earlier versions of Haskell; continua-
>tions, as used in Hope; linear types, as used in Clean; and side effects, as used in
>SML.

241:デフォルトの名無しさん
06/07/01 08:52:27
手続き型言語の代入でも、裏で全メモリの値を渡してると考えれば副作用ではないな

242:デフォルトの名無しさん
06/07/02 00:07:46
>そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。
なるほど、完全に同意しましたです。すまない。

更に How to declare an imperative の文がとてもわかりやすい。ありがとう。
入出力、といえば副作用と思っていたけど、同期ストリームもそうだよな。
自分ではhGetContentsくらいしか使わないけど。
linear typeで入出力ができるのもCleanのマニュアルの序章で分かる(world as value)。
しかし。。。continuationでどうやって入出力するのか??

>それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか？
あなたが言うように、副作用と入出力を混同していた。典拠はない。

243:242
06/07/02 00:15:21
誤解を招くと悪いので少し書くと、hGetContents自体の型は Handle -> IO StringなのでIOモナド。

ただ、hGetContentsから得たStringは遅延評価の度にファイルやネットワークデバイスから読み出される。
(データがなければブロックする)
この「遅延読みString」を処理する部分は旧来のストリーム・プログラミングっぽい（よね？

244:デフォルトの名無しさん
06/07/06 22:15:48
C言語だと言語仕様として再帰は32回までしか保証しない(だっけ)とかだから、
再帰による33回目の関数呼び出しとそうでない呼び出しで意味が大きく変わってくる。

245:デフォルトの名無しさん
06/07/06 23:06:29
>>244
うそつけ。Cの仕様書にそんなこと書いてないぞ。

246:デフォルトの名無しさん
06/07/07 04:38:43
何かそういう類いのあった気がするよ。
for のネストの回数とか意外なものに、
最低保証回数が仕様として決められている。

247:デフォルトの名無しさん
06/07/07 06:46:28
つ[5.2.4 Environmental limits]
だが、再帰回数はない。

248:デフォルトの名無しさん
06/07/07 08:25:32
そうなのか。

249:デフォルトの名無しさん
06/07/07 08:32:38
>>244
少し考えれば、再帰を32回まで完全保証する事が不可能だって分かるだろ。

250:デフォルトの名無しさん
06/07/08 09:19:47
へ？不可能なの？スタックさえ確保しておけばいいんじゃねーの？

251:デフォルトの名無しさん
06/07/08 09:22:30
>>249
ああ、確かにそうだな。

252:デフォルトの名無しさん
06/07/09 01:07:02
>>250
ローカル変数がスタックに取得される仕様だと
消費されるスタックの量が予測できないだろ。

ローカル変数と配列の最大数×配列サイズの制限？から再帰の
最大数を決めてもあまり意味があるとも思えない。

ローカル変数をスタックに取らないといけない決まりも無いけど
ほとんどの実装で受け入れられないモノを標準仕様を
するわけにはいかなかったんだろう。

ってスレ違いごめん

253:デフォルトの名無しさん
06/07/09 20:45:30
ローカル変数のスタック上のサイズは固定でしょ。言語にもよるけどCやC++ならそう。
そんなことも分からんやつしか居ないの？

254:デフォルトの名無しさん
06/07/09 21:39:50
もっと優しく言ってくれ

255:デフォルトの名無しさん
06/07/09 21:49:20
おれにはツンデレでお願い

256:デフォルトの名無しさん
06/07/09 22:30:35
し、Cの言語仕様にスタックなんて概念は規定されてないんだからねっ！

257:デフォルトの名無しさん
06/07/09 22:34:52
>>244-256
スレ違いの議論はこの辺で終了して下さい

258:デフォルトの名無しさん
06/07/10 00:31:31
>>253
だからその固定の変数を最大いくつ宣言できるか判らないでしょ

259:デフォルトの名無しさん
06/07/10 02:01:36
さらにC99だとスタック上の配列のサイズは実行時に決定できる。
すれ違いなのでこの辺までにしとこう。

260:デフォルトの名無しさん
06/07/10 06:35:50
>>259
>>256

261:デフォルトの名無しさん
06/07/10 12:53:18
>>259
偉そうに大嘘で締めないように。無能はしゃしゃり出ちゃいやん。

ま、スレ違いだからやめとくか。

262:デフォルトの名無しさん
06/07/10 13:38:02
ここは一応 Haskell 本スレじゃないから、
少々脱線した所でどうでもいい気もするけどね。

263:デフォルトの名無しさん
06/07/10 13:52:49
少々なら良いけど3日も続くとね…。
面白い話でもないしw

264:デフォルトの名無しさん
06/07/10 22:01:26
>>260
細かいな。記憶クラスが auto の配列って言えばいいのか？

>>261
C99のマニュアル読んでね。

265:デフォルトの名無しさん
06/07/10 22:17:04
げ。知らなかった。
int a[hoge()];
なんてやっても動くじゃん。
いままで関数内で捨てちゃう配列にmalloc使っていたのは無駄だったのか。

HaskellとRubyばっかり使っていたせいで、Cはメモリ管理がめんどくさい言語
だとばかり思っててちゃんと調べてなかった。

266:デフォルトの名無しさん
06/07/10 22:31:16
C99 じゃないと無理だけどな。

267:デフォルトの名無しさん
06/07/10 22:34:35
Cは99なのにHaskellはまだ98なのかー

268:デフォルトの名無しさん
06/07/10 22:46:53
>>264
しかしそう言い直した途端にスタックの話じゃなくなる罠。

いつまでもひきずってもつまらんので、Haskellの豆知識でも。

GHCでコンパイルされたプログラムがスタックをどのように使うかはわかりにくい。
再帰呼び出しでスタックが深くなっているようにも見えないのにオーバーフローを起こしたりする。
これは、スタックの消費が、呼び出しの深さではなく正格な関数の適用のネストの深さに比例するためだ。
例えばg x = x + 1 - 1 + 1 - ..たくさん.. - 1という関数を定義すると、呼び出しの深さは一であるにも関わらず
スタックを大量に消費する。正格な関数である(+)と(-)の適用が深くネストされているからである。

269:デフォルトの名無しさん
06/07/11 09:42:39
スタックが足りなくなったら適当に評価を行って遅延してるのを減らすとか
できないの?

270:デフォルトの名無しさん
06/07/11 11:27:31
>>264
嘘を拡大するためだけに前言撤回で復活しなくてよろしい。

271:デフォルトの名無しさん
06/07/11 19:11:00
>>269
未評価の式はヒープに保存されているので、それ自身はスタックを消費しない。
スタックが溢れるのは式を評価しようとしたとき。

272:デフォルトの名無しさん
06/07/14 00:15:50
>>271 スタックあふれた時はヒープ上にスタックを移動して計算したりできないの？

273:デフォルトの名無しさん
06/07/14 01:15:45
>>272
なんで俺らがそこまでしなきゃいけないわけ？お前何か勘違いしてない？

274:デフォルトの名無しさん
06/07/14 01:28:55
スタックが溢れそうなのにヒープに余裕があるなどと思ってる素人はモノ喋んな。

275:デフォルトの名無しさん
06/07/14 03:16:34
・・・

276:デフォルトの名無しさん
06/07/14 11:25:17
頭が良くない人ほどすぐ怒る

277:デフォルトの名無しさん
06/07/14 17:56:55
>274は50年前の世界からやってきた時空の旅人

278:デフォルトの名無しさん
06/07/15 19:52:26
>>277
♪ぼくらは　たびびと
　ときの　たびびと♪

279:デフォルトの名無しさん
06/07/16 04:35:58
Haskellは、お利口さんに見られたいけど誰もそう見てくれない
哀れな人たちの嫉妬を一身に買って出てるよね。

280:デフォルトの名無しさん
06/07/16 14:04:58
嫉妬というか、そういう奴らがすがるための言語。
知的な奴は、そういうことを考えずに自己拡張しまくりのLispを使う。

281:デフォルトの名無しさん
06/07/18 13:14:51
諸君議論しているかね？

282:デフォルトの名無しさん
06/07/19 01:50:46
Haskell 面白そうなので調べていたら、Clean にたどり着いた。
両方とも、ちょっとしか解ってないが、現時点ではClean の方が良さげに思える。
でも、一般的にはHaskell の方が流行ってるみたい…。
なぜなんでしょう？

Haskell の方が良い！という人の意見が聞きたいです。

283:デフォルトの名無しさん
06/07/19 02:56:48
URLﾘﾝｸ(groups.google.com.au)
個人的にはCleanって閉鎖的な印象を受けるからHaskellに流れてるだけ。
どっちも元はMirandaだからCommon LispとSchemeくらいにしか違わないんじゃないの？と
ろくすっぽCleanを知らないで書いてみる。

284:デフォルトの名無しさん
06/07/19 03:02:04
ま、素人はそう考えるわな。

285:デフォルトの名無しさん
06/07/19 03:58:51
最新ニュース　【教育】国際数学オリンピック　中国が全員金メダルで3年連続世界1位　2位ロシア、3位韓国　日本は7位も過去最高成績
1 ：ネットナンパ師φ ★ ：2006/07/19(水) 02:23:23 ID:???0
URLﾘﾝｸ(news.searchina.ne.jp)
URLﾘﾝｸ(imo2006.dmfa.si) によると、順位は　1中国　2ロシア　3韓国
4ドイツ　5アメリカ　6ルーマニア　7日本　8イラン　9モルドバ　10台湾　11ポーランド　12イタリア
13ベトナム　14香港　15カナダ　16タイ　17ハンガリー　18スロバキア　19トルコ　20イギリス
【ニュー速＋】ｽﾚﾘﾝｸ(newsplus板)

（以下参考情報）
インド人は、あんだけ人間いて夏季オリンピックで銅1個しか取れない劣等民族。
自慢の理系でも数学オリンピックは毎年中国が優勝。アメリカが2位。この2国が指定席で、インドなんてランク外。
Wikipedia項目ﾘﾝｸ
数学オリンピックの日本の輝かしい成績
1995年：1位-中国、2位-ルーマニア、3位-ロシア、4位－ベトナム、5位-ハンガリー
1996年：1位-ルーマニア、2位-アメリカ、3位-ハンガリー、4位-ロシア、5位-イギリス
1997年：1位-中国、2位-ハンガリー、3位-イラン、4位-ロシア、アメリカ
1998年：1位-イラン、2位-ブルガリア、3位-アメリカ、ハンガリー、5位-台湾
1999年：1位-中国・ロシア、3位-ベトナム、4位-ルーマニア、5位-ブルガリア
2000年：1位-中国、2位-ロシア、3位-アメリカ、4位-韓国、5位-ブルガリア、ベトナム
2001年：1位-中国、2位-アメリカ、ロシア、4位-ブルガリア、韓国
2002年：1位-中国、2位-ロシア、3位-アメリカ、4位-ブルガリア、5位-ベトナム
2003年：1位-ブルガリア、2位-中国、3位-アメリカ、4位-ベトナム、5位-ロシア
2004年：1位-中国、2位-アメリカ、3位-ロシア、4位-ベトナム、5位-ブルガリア
2005年：1位-中国、2位-アメリカ、3位-ロシア、4位-イラン、5位-韓国

なお参加資格は高校生までです。今すぐではなく次世代、次次世代に効いて来るものです。
それが教育の深さ、恐ろしさ。

286:デフォルトの名無しさん
06/07/19 05:09:41
みなさんやっぱり頭がいいんですね。

287:デフォルトの名無しさん
06/07/19 05:20:57
>>285
数学オリンピックでは中国とか凄いんだけどねえ。
なぜか欧米の方が偉大な数学者は多いよね。
インドだってラマヌジャンっていう大天才がいたし。

288:デフォルトの名無しさん
06/07/19 10:28:12
だって数学オリンピックって数時間で処理できるような、簡単な問題を
いかに処理しきるかっていう官僚的作業だろ？
それでも俺には逆立しても解けないが。

ノーベル賞フィールズ賞取る様な何年もかけて倒す仕事とはスケールが違い過ぎるから

1kmレースを3速ギアでトップで駆け抜けたからといって
そのマシンが300kmレースを6･7速ギアでトップでゴールできるわけじゃない。

289:デフォルトの名無しさん
06/07/19 10:57:38
>> 284
非素人の見解披露希望。

290:282
06/07/20 02:58:24
>>283
英語、苦手でして…。
単語を拾い読みしてみましたが、Haskell は研究用で Clean は実用言語という所でしょうか？

>>284
ぜひ、具体的意見をお聞かせ下さい。

291:デフォルトの名無しさん
06/07/20 20:36:18
Cleanは実行速度速いよ
メモリも食わない
Haskellは遅い

292:デフォルトの名無しさん
06/07/21 00:42:59
Cleanで
echo 'main = readFile "b.txt" >>= putStr . show . (\x->x*x*x) . read'> c.hs && echo 4 > b.txt && runghc.exe c.hs
これと同じことやってみ。

293:デフォルトの名無しさん
06/07/21 09:36:40
>>288
は、数学オリンピックについて何も知らない。

294:デフォルトの名無しさん
06/07/21 09:39:46
Microsoftが開発中の新しいシェル「Windows PowerShell」は、RC1版以前は
「Microsoft Command Shell（開発コード名：Monad）」という名称が付けられていた。

295:デフォルトの名無しさん
06/07/21 09:48:28
英語が苦手だとHaskellやCleanの新しい機能をすぐに使えないので楽しさ半減だろうと思う。
nobsunみたいに和訳してくれる人は普通とても少ないし。

296:282
06/07/22 03:36:21
>>292
なる程、Haskell の利点としては
①スクリプト言語的な使い方ができる
②IOモナドだと簡潔に書ける
といった所でしょうか。

①の使い方は面白いかもしれませんね。

②はどうなんでしょう？
エラー処理とかを考慮したプログラムも簡潔に書けるのでしょうか？

297:282
06/07/22 03:38:17
>>295
今の所、基本的な事を覚えるだけで、アップアップですw

298:デフォルトの名無しさん
06/07/22 05:01:32
Haskell
　関数型言語のスタンダードという役割を担うために作られた言語。
　だから、関わっている人が多いし、ライブラリも多い。

Clean
　関わっている人が少なく、ライブラリも少ない。
　異端であるがゆえに、最新の話題がCleanから出てくることはほとんどない。

という違いもある。
勉強目的ならHaskellだな。

Haskellといえばモナドだけど、Cleanでも同じようなロジックで書ける。
両者の違いは構文糖衣的な違いで、中身は似たようなもの。
Cleanで書くと、たらい回す変数を山のように書いて、文字数が2倍ぐらいになる。
Haskellはプログラムが美しい、Cleanは実行速度が速い、と言える。

299:デフォルトの名無しさん
06/07/23 00:13:15
もっと最適化しろよハスクル

300:デフォルトの名無しさん
06/07/23 00:15:44
カレー食いたくなった

301:デフォルトの名無しさん
06/07/23 00:52:36
コンパイル時間をもっと短くしろよハスクル

302:デフォルトの名無しさん
06/07/23 01:34:55
あらいぐまハスクル

303:282
06/07/23 02:53:12
>>298
なるほど…。
なぜ、Haskell の方が一般的なのか、解ったような気がします。
ありがとうございました。

304:デフォルトの名無しさん
06/07/30 10:30:01
ヒアドキュメント無いんだったらクソ認定

305:デフォルトの名無しさん
06/07/30 10:58:56
確かに欠陥だ。
次版で入らんかな。

306:デフォルトの名無しさん
06/07/31 18:40:18
自己記述してるからコンパイラが低速なんだろ？

307:デフォルトの名無しさん
06/08/02 17:42:50
諸君議論したまえ

308:デフォルトの名無しさん
06/08/03 20:24:15
諸君怠けてはいないか？

309:デフォルトの名無しさん
06/08/04 16:48:43
諸君夏休みかね

310:デフォルトの名無しさん
06/08/05 13:39:27
本物のプログラマはHaskellを使う
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

記事のタイトル、センス無い

311:デフォルトの名無しさん
06/08/05 15:42:44
>　最後にこの連載のタイトルの由来を紹介しておきましょう。
> 「本物のプログラマはHaskellを使う」というタイトルは
> 「本物のプログラマはFORTRANを使う」や「本物のプログラマはPascalを使わない」
> といった有名なフレーズをもじったものです。

って書いてあるじゃんか。自分が知らない読んでない理解できないからって
不当に他人を卑しめるのは止めような。

312:デフォルトの名無しさん
06/08/05 16:30:56
そういうもじりが安直だって言ってんじゃないの？

313:デフォルトの名無しさん
06/08/05 16:53:19
そんなに悪いとは思わないけどな…
「本物のプログラマはHaskellを使わない」のほうがしっくりくると言われればそうかもしれないが。

314:デフォルトの名無しさん
06/08/05 17:45:17
「本物のプログラマはPascalを使わない」で語られる本物は、
決してHaskellなどという"軟弱な"言語なぞ使わんと思うんだが？

315:デフォルトの名無しさん
06/08/05 20:09:59
310のリンク先の情報処理学会のページ、おもろいな
まだ少ししか読めてないけど

316:デフォルトの名無しさん
06/08/05 20:33:27
本物のプログラマはPASCALを使わない

参考
Wikipedia項目ﾘﾝｸ
URLﾘﾝｸ(www.genpaku.org)

317:デフォルトの名無しさん
06/08/06 00:46:32
この人のサイトが痛いのは本人の趣味嗜好の問題だから放っておくとして、
一昔前のgauche-devel-jpでのshiroタンとのやりとりを見る限りコンピュータの
アーキテクチャの根本が理解できていない人としか思えなかったんだが。
まぁHaskellと戯れているうちはデータがメモリ上でどう表現されているかなんて
知らなくても生きていけるってことかな。

318:デフォルトの名無しさん
06/08/06 01:08:00
ハードに近いことは良くわかってないけど何となくプログラミングできている、ってのは文系出プログラマの得意技。

319:デフォルトの名無しさん
06/08/06 09:28:30
Haskellの美しさにあてられら未熟な若者だ。
優しく見守ってやれ。

320:デフォルトの名無しさん
06/08/06 16:03:48
>>317
似た名前だと思っていたら、あれと同一人物なのかよ……。

321:デフォルトの名無しさん
06/08/07 00:56:53
同一人物、なんだろうねぇ…。
偶然一致するようなハンドル名なのかどうか判断できないから確証はないけど。
未踏にも顔出してたと思ったけど、どんな成果だったのかな。

322:デフォルトの名無しさん
06/08/09 18:27:04
何これ？あわててブラウザを閉じたぜ。
URLﾘﾝｸ(page.freett.com)

323:デフォルトの名無しさん
06/08/10 09:03:14
だれかヒアドキュメントの機能をcommitしてきてください。

324:デフォルトの名無しさん
06/08/10 18:39:34
グラスゴウスケールって医療用語であるけど
グラスゴウハスケルと似てるね

325:デフォルトの名無しさん
06/08/11 01:41:09
>>324
うわぁっ、すごぉっ、すげぇー！って、日常用語にあるけど、
グラスゴウスケールと似てるね。

326:デフォルトの名無しさん
06/08/11 07:51:06
ということは
うわぁっ、すごぉっ、すげぇー！
と
グラスゴウハスケルは似てるわけか

327:デフォルトの名無しさん
06/08/16 20:04:53
問１

「うわぁっ、すごぉっ、すげぇー！」を使って
長文を作りなさい

328:デフォルトの名無しさん
06/08/17 05:51:34
それを見て、あるいは、変なものだ。うわぁっ、すごぉっ、すげぇー！
むやが及ん、すべてが、と思った。うわぁっ、すごぉっ、すげぇー！
不要なら、それが、それを出してきたところでもないのなのだ。うわぁっ、すごぉっ、すげぇー！
まだ比べできて、この本にもある。うわぁっ、すごぉっ、すげぇー！
すでに、人を手をするのを出している、バカな気が、この本のせいと、一歩だと思うんだ。うわぁっ、すごぉっ、すげぇー！
0001200-ROM人は、もう一つの問題になるので、ついにこれには、ホントには、下の時代にはその時のせいをつくるなものを読んでいるのも、それはそれを92020202/1創作連中所持とかの時代にもある。うわぁっ、すごぉっ、すげぇー！
あるいは物語もあった。うわぁっ、すごぉっ、すげぇー！
なお、その号のこともずっとさておきけれど、感じ。うわぁっ、すごぉっ、すげぇー！
プロットをすると、という感じ。うわぁっ、すごぉっ、すげぇー！
で、すでにシャープに、ほとんど無節操ないのかな。うわぁっ、すごぉっ、すげぇー！
短距離では、その戦時のお解釈年前の大解決冷や汗指標はほとんど開かかとかを手をもらった芸ばかり。うわぁっ、すごぉっ、すげぇー！

329:デフォルトの名無しさん
06/08/17 10:12:37
ちょｗｗｗ

330:デフォルトの名無しさん
06/08/17 22:03:17
>>328
日本語による近代美術だ

331:デフォルトの名無しさん
06/08/18 17:06:46
解読できたらごほうびをあげるわ

332:デフォルトの名無しさん
06/08/19 05:42:40
諸君そろそろ議論に戻りたまえ。

333:デフォルトの名無しさん
06/08/21 20:21:49
　　　　|┃三　　　　　　　　　　　　＿＿＿＿＿＿＿＿＿
　　　　|┃　　　　　　　　　　　／
　　　　|┃　≡　　　_、_　　　＜　話は全部聞かせて貰ったぞ！
＿＿__.|ミ＼＿＿_（　<_,`　） _　＼
　　　　|┃=＿＿＿　　　　＼　　　￣￣￣￣￣￣￣￣￣
　　　　|┃　≡　　　）　　　人＼ガラッ

334:デフォルトの名無しさん
06/08/27 11:24:42
入門Haskellの１章目で既に挫折しそうなわけだが。
やはり、アホな俺にはjavaが似合ってるのかもしれん。

335:デフォルトの名無しさん
06/08/27 12:05:04
>>334
一章からわりと技巧的なことをやっているので無理もないと思う。
とにかく慣れが重要なので、サンプルコードをコピペしていじりながら
慣れるのが良いんじゃないか。
意味の分からないところは2chで聞けばいいし。

336:デフォルトの名無しさん
06/08/27 14:42:25
>>335
アドバイスありがと。
とにかく触りながら地道にやってみるか。

337:デフォルトの名無しさん
06/08/27 16:36:09
ふつけるのほうが
入門書としては
出来がいいようなキガスルな

338:デフォルトの名無しさん
06/08/27 19:10:52
>>328
うわぁっ、すごぉっ、すげぇー！

339:デフォルトの名無しさん
06/08/27 20:34:23
だまれカス

340:デフォルトの名無しさん
06/08/27 23:24:04
カスケル

341:デフォルトの名無しさん
06/09/03 11:37:28
URLﾘﾝｸ(www.youtube.com)
みんな本当にこう感じてるのか？

342:デフォルトの名無しさん
06/09/03 16:18:31
>>341
ｶｺｲｲ

343:デフォルトの名無しさん
06/09/03 17:38:49
>>341
すげー
Haskoreってやつを使っているのかな。

344:デフォルトの名無しさん
06/09/03 17:51:04
>>341
最後の別のムービー紹介で
リーリ・カル・マジーロがトップに来てるのにﾜﾛﾀw

345:デフォルトの名無しさん
06/09/03 17:55:45
>> 341,342,343
いまサウンドボードがイカれてて何がおもしろいのかサーッパリわからなかったんで
何を紹介しているムービーなのか解説してもらえないでせうか。

346:デフォルトの名無しさん
06/09/03 18:12:03
>>345
音楽のリズムパート(って正しい表現？)を記述したHaskellのコードがあって、それがBGMとして流れている。
コードを編集してロードしなおすとそれに連動して音楽も変わる。

347:デフォルトの名無しさん
06/09/04 08:14:34
よく考えればMMLとあんまりは変わらないとも言えるけど…

348:345
06/09/05 01:10:24
>> 346
遅ればせながらサンクス。週末にでもサウンドボード調達してこよ。

349:345
06/09/14 00:06:08
音付きで拝見しました。あまりよく知らないんだけどあんなのもHaskellが標準で
持ってる範囲内での記述なんですか？Lisp屋さんだとそれ専用のミニ言語平気で
作っちゃったりしてるけど似たようなものなのかな。

350:デフォルトの名無しさん
06/09/14 01:16:32
328はpseudo-yamagata

351:デフォルトの名無しさん
06/09/14 02:12:13
>>343
URLﾘﾝｸ(en.wikipedia.org)
こんなものがあったとは。。

352:デフォルトの名無しさん
06/09/19 23:56:56
このスレにはイスラエルの工作員が紛れ込んでると聞きましたが。

353:デフォルトの名無しさん
06/09/20 00:02:58
オッス　オラモサド

354:デフォルトの名無しさん
06/09/20 00:28:57
祖国がやべえ状態だってのに
なんだかすっげえワクワクしてきたぞ！

355:デフォルトの名無しさん
06/09/29 08:34:08
>>272
URLﾘﾝｸ(www.haskell.org)
GHCのマニュアルによると、スタックはヒープ上に取られ、必要に応じて伸長する。
ヒープを使いきっていないのにスタックオーバーフローが起こるのは、無限ループに陥ったときに
メモリを使い尽くさないように上限を定めているだけで、

# スタックの大きさの上限を40億バイトにする
./a.out +RTS -K4G

のように上書きできる。

356:デフォルトの名無しさん
06/10/06 17:47:48
syntax sugar

cons :: a -> [a] -> [a]
cons a b = a : b

357:デフォルトの名無しさん
06/10/07 23:18:37
諸君、議論したまえ。(ﾌﾟﾋｮｹﾞﾗ)

358:デフォルトの名無しさん
06/10/08 09:08:42
闇夜に仕事人の目がギロンギロン

359:デフォルトの名無しさん
06/10/21 02:35:42

　ありがとーおー　ぼくのー　とーもだちー
　
　　　ハスカｧール　にー　あわせてー　くぅー　れー　ぇーてぇー

360:デフォルトの名無しさん
06/10/21 18:26:29
良スレage

361:デフォルトの名無しさん
06/10/21 18:55:02
なにこの流れｗ

362:デフォルトの名無しさん
06/10/21 19:09:55
次スレこれでいこうぜ

【Haskell】あらいぐまハスケル【関数型言語】

363:デフォルトの名無しさん
06/10/24 00:08:44
この言語は何で人気なの？

364:デフォルトの名無しさん
06/10/24 00:13:15
別に大して人気はないと思う。
単に話題になることが多いだけじゃないかと。

365:デフォルトの名無しさん
06/10/24 00:35:18
ネタにし易いからかな。

366:デフォルトの名無しさん
06/10/24 22:24:58
ｽﾚﾘﾝｸ(tech板:909番)
飽きるまでなら付き合おう。
で、どこまで理解してる？

367:デフォルトの名無しさん
06/10/24 22:35:23
module Qsort where
qsort _ [] = []
qsort f (x:xs) = before ++ (x : after)
　　where before = qsort f $ filter (not . (f x)) xs
　　after = qsort f $ filter (f x) xs

moduleってなによ
whereってなによ

368:デフォルトの名無しさん
06/10/24 22:52:17
module Qsort where
ってのは、これからQsortという名前のモジュールを定義する、
詳細は以下である、と言う意味。（whereは「ただし」とでも読むべし）
モジュールというのは、おおざっぱに言うと、
一つのファイル中で定義されたものたちをひとまとめにして名前をつけたもの。
この場合はQsortモジュールはただ一個の定義(qsort)だけからなる。
プログラムの他の部分からqsortを使いたいときは、
import Qsort
として、Qsortモジュールの定義を使うことを宣言する。

369:初心者A
06/10/24 23:03:51
モジュール・・・機能単位、交換可能な構成部分という意味の英単語(e-wordより)

なるほど。Javaでいうところのクラスみたいな感じか
import文もJavaといっしょだな
モジュール　≒　Javaのパッケージ
定義　　　　　≒　Javaのクラス
関数　　　　　＝　Javaのメソッド

ここで疑問点が発生
下のような2行だけ書いたファイルでもOKのはずだけど
これはなんで module とか where　とか定義名がいらないの？

foo x y = x + y
hoge = 2

370:デフォルトの名無しさん
06/10/24 23:09:22
>>369
>これはなんで module とか where　とか定義名がいらないの？
module ... whereの部分は省略することができて、その場合
module Main(main) where
と書かれているとみなされる。
(main)という括弧書きは、モジュール中の定義のうち、mainだけを外部に公開する、
という意味。括弧書きがないときは、全ての定義が公開される。

次ページ