1) Lazy IO ● 良いところ ○ 単純でわかりやすい ● 悪いところ ○ 純粋な関数で例外が起こる ■ r e a d F i l e で読んだファイルに不正なバイト列が含まれていた場合は例外が起こり ます 。 そして、Haskell は遅延評価なので、 値は必要になった時に評価され、 例 1 外は評価時に発生します。 つまり、 評価されるまで例外は発生しないのです！ こ の性質により、 なんと純粋な関数で例外が起こることがあります。 これのデバッ グは非常に難しいです。 ○ いつ、 どれだけファイルが開かれ、 開放されるか予測しにくい ■ 上記と同じ理由でファイルが開放されるタイミングも単純には予測できません 。 2 大量のファイルが同時に開かれてしまう場合もあります。 1 上記のコー ドの場合、 L T . f i l t e r で不正なバイト列が評価される時に発生します。 2 s e q や B a n g P a t t e r n s を使ってサンクを潰して回る羽目になります。
3) iostreams ● 良い所 ○ ハイレベルでコンポー ザブル ■ ストリー ム自体の扱いはiostreams が隠蔽しています。 ■ ストリー ムを受け取る関数を、Unix のパイプのように > > = で処理を繋ぎます。 繋 がれたそれぞれ処理は抜き差しがしやすいので 、 部品化も簡単です。 4 ○ 安全な例外 ■ それぞれの部品は I O ( I n p u t S t r e a m a ) を返すので、 b r a c k e t で例外を捕捉でき ます。 ○ 少ないメモリ使用量 ■ iostreams が面倒見てくれます。 ● 悪いところ ○ ＼(^o^)／ ない 4 iostreams で入力を処理する場合、 I n p u t S t r e a m a ‐ > I O ( I n p u t S t r e a m a ) を繋いでいくことになります。
fujimura
speed1313
fendo181
weddingpark
dicoding
suzuki
mpyw
microcms
koluku
leichteckig
alli83
fabpot
yutootsuka
sonatard
soudai
holman
addyosmani
gr2m
jmmastey
chriscoyier
dougneiner
philhawksworth
phodgson
aki_iinuma