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
tsutsui
masatoshiitoh
hitsuji1991
skanehira
marcustung
rdmueller
kishida
parttimenerd
afilina
atinfinity
texmeijin
okuramasafumi
tanoku
carmenintech
searls
sugarenia
brad_frost
wjessup
jlugia
paigeccino
ddemaree
schacon
hursman
chrislema