##次は vector 化ですね。(その前に、今回の変更で生じた bytestirng と vector-bytestring の間の API のギャップを埋める必要がありますが。)
#作者の Simon 自身が言っていましたが、Handle のバッファーに直接書き込めるようになるようです。
#vector 化というのがイマイチ分かっていないんですが、Vector 上に ByteString を実装するという話でしょうか? もしそうなら、何が嬉しいのですか?
##Vector 化で目的としているのは、(Lazy Bytestirng に対する)Builder と同じく、Bytestirng に対する処理のコストを減らすことです。
#Vector で ByteString の実装を置き換えれば、ByteString の参照透過な配列としての性質を保ったまま、融合変換によって更新コストを減らすことができるはずなので。 http://t.co/0nMuTFpF #(ただし、現在の Vector の実装にはまだまだ改良の余地があるようですが。)
#なるほど! ありがとうございます。
#Text は Array を使ってますが、Vector は使ってませんよね。独自に fusion を書いているってことですかね? Vector の上に、ByteString と Text が実装され、Vector を鍛えれば、ByteString と Text も速くなるという世界が美しいのかな?
#なんか、曖昧な文章だった。Text は Vector ではなく Array を使ってますよね。と、いいたかったのです。
#foo [] = undefined
#foo [x] = undefined
#foo xs = undefined
#これを、ByteString で書き直すと、length が O(1) なので
#foo bs
| BS.null bs = undefined
| BS.length bs == 1 && = undefined
| otherwise = undefined
#と書けるんですが、Text の場合はどうすればいいですか?
#length が O(n) なんですが。
#上の && はゴミです。すいません。
#はい。text は vector とは別に独自に fusion (Recycling は持たず Stream Fusion のみ)を書いています。
#Array といっても array パッケージのものではなく、ByteArray# や MutableByteArray# の上に独自に定義した Array 型を text では使っていますね。
http://t.co/m1FaCdk3
#null . tailでは?
#text の開発を始めた頃はまだ vector も少しずつ実装を進めている段階で、そもそも vector をバックエンドとして使うという選択肢を考慮する状況ではなかった、という歴史的な理由で vector を使わない実装になっているのだと思います。
#そうですね。 > ByteString と Text が実装され、Vector を鍛えれば、ByteString と Text も速くなるという世界が美しいのかな?
#ただ、text は内部表現に UTF-16 を使っている関係で vector の Recycling を使う旨みがなさそうなので、Recycling に伴うオーバーヘッドを減らすのが text を vector 化する時の課題になりそうですね。
#あと、単純に ByteString と Text を Vector の上に実装するだけではなく、List の融合変換も Stream Fusion 化して [http://t.co/S2H5Ttnu ]、 #Stream Fusion や Recycling のためのフレームワークを base で提供できたりすると良いかもしれません。
#すると、[x,y] とかになると、null、null.tail、null.tail.tail を書き連ねるんですか? View パターンを使うと、奇麗に書けますか?
#あっ、 s/ByteString と Text が実装され/Vector の上に、ByteString と Text が実装され/
#説明ありがとうございます。 > shelarcy さん
#どういたしまして。
#あっ、リンク間違えてました。List の Stream Fusion 化はこっちの Ticket です。 http://t.co/d0gWOhtQ