Yeah, don't worry about that. Now we have a new package to play with! :)
More comments inline below:
On 02/05/2014 11:02 AM, Michael Thompson wrote:
It is probably no good, but I uploaded a version of pipes-text
to hackage -- somewhat accidentally, as I was investigating
what I thought was a defect in my privileges.
http://hackage.haskell.org/package/pipes-text-0.0.0.0
If anyone has a definitely better idea, structurally, then please
overwrite it. Here is what I said about it on the thread about `lens
based
parsing` :
I finished a draft version of pipes-text with
the 'lens' approach.
https://github.com/michaelt/text-pipes/tree/master/Pipes
<https://github.com/michaelt/text-pipes/tree/master/Pipes>
I think I am following
Gabriels advice above, more or less, by
just giving functions like
encodeIso8859_1 :: Monad m
=> Producer Text m r
-> Producer ByteString m (Producer Text
m r)
decodeAscii :: Monad m
=> Producer ByteString m r
-> Producer Text m (Producer ByteString m r)
Yeah, I believe this is the right approach. If people wish to undraw
ISO8859_1-encoded text, then they should explicitly handle potential
errors first by doing the conversion manually and then undrawing the
converted bytes if the conversion succeeds.
in each direction. For utf8 there is a
Lens of the type we wanted
decodeUtf8 :: Monad m
=> Lens' (Producer ByteString m r)
(Producer Text m (Producer
ByteString m r))
At the moment for I am replicating
the method of the enumerator and
conduit packages in defining `Codecs`
`utf16_le` , `utf16_be` , `utf32_le` ,
`utf32_be` and then a function that
makes a Lens' for them
codec :: Monad m
=> Codec
-> Lens' (Producer ByteString m r)
(Producer Text m (Producer ByteString m r))
(there is also such a `Codec` for utf8).
In all cases, we do without the customary
`Text` exception system. When decoding or
encoding of a `Producer ByteString ...` or
`Producer Text ...` goes wrong, we simply
return the remaining Producer we are
encoding or decoding. Or that is what I think
I am doing. I can't tell if it's insane or not.
I was thinking of replacing the `Codecs` with
a series of individual lenses later; I am for
the moment using them to take advantage of
the presumed correctness of the code
I am modifying. (I don't like the way
the original code is written, but no matter for
the moment.)
That's fine with me. Also, people will use `decodeUTF8` most of the
time, so it's okay if the codec stuff is a little slow or messy for now.
I decided that all IO in the module should
be `Pipes.Prelude` -like in character and
that this should be emphasized.
Everything is done on the basis of
things in `Data.Text.IO <http://data.text.io/>` and the like;
it all uses `Text`'s exception machinery
and is a little slow.
So I will advertise that `Pipes.ByteString`
and co. defines the "real" IO operations,
which are about 3 times as fast, and
which we textify with `encodeUtf8`
and `decodeUtf8` and the like.
I was wondering if the 'api' of the `Pipes.Text`
module now seems more or less what is desirable.
(The way some things are implemented
is perhaps objectionable, except where I
am replicating `Pipes.ByteString`)
One thing I might recommend is to take out all the `pipes-safe` stuff.
My plan is to reserve functions similar to `readFile` for a
`pipes-filesystem` package (along with all the original `dirstream`
stuff I worked on) and make that package the primary consumer of
`pipes-safe`.
Also, I would either avoid the `stdinLn` and `stdoutLn` functions or
place a warning in the documentation that they are not idiomatic because
of potentially unbounded memory use and should be avoided for production
code with a brief reference to `Pipes.Text.lines` and
`Pipes.Group.Tutorial`.
So `pipes-bytestring` makes `pack`/`unpack` an `Iso'` but I'm not
actually entirely sure whether or not I made the right call on that
(because using the reverse direction entails a `lens` dependency). So
what I'm doing right now is testing if people complain about the `Iso'`
and if there is any push-back then I might copy you and make them
separate functions.
Other than that, the API looks really great and I'm really happy with
it! Thank you so much for all the hard work you put into this!
yours ever, Michael
--
You received this message because you are subscribed to the Google
Groups "Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
--
You received this message because you are subscribed to the Google Groups "Haskell
Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
