Re: patch applied (packages/HaXml): Use ByteString for output (contributed by Jason Dagit, with modifications)

newer
Data.List.join

older
Re: darcs patch: forkChild,...

Malcolm Wallace

14 Nov 2006 14 Nov '06

12:49 p.m.

[moved from cvs-libraries to reach a wider audience] Ian Lynagh wrote:

...

On Mon, Nov 13, 2006 at 10:46:14AM -0800, Malcolm Wallace wrote:

...
* Use ByteString for output (contributed by Jason Dagit, with modifications) There are some new signatures in Text.XML.HaXml.XmlContent: fpsShowXml fpsWriteXml fpsHPutXml

I think bs* would make more sense than fps*,

OK, I can see your reasoning. Are there any other good suggestions out there? Normally, Data.ByteString users tend to put their operations in a separate module altogether, with the same function names as the normal String-based ops. Then it is easy to distinguish them by simple module import/qualification. In fact, that is how Jason originally implemented it - but I was unhappy about the huge amount of code duplication involved, which is why I choose a different route. I am open to further ideas about how to best achieve a similar effect (i.e. ByteString ops available, but minimal code duplication). Regards, Malcolm

Show replies by date

Bulat Ziganshin

14 Nov 14 Nov

1:32 p.m.

New subject: Re[2]: patch applied (packages/HaXml): Use ByteString for output (contributed by Jason Dagit, with modifications)

Hello Malcolm, Tuesday, November 14, 2006, 8:49:31 PM, you wrote:

...

involved, which is why I choose a different route. I am open to further ideas about how to best achieve a similar effect (i.e. ByteString ops available, but minimal code duplication).

use Stringable class from fps-soc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Jason Dagit

5:53 p.m.

New subject: Re[2]: patch applied (packages/HaXml): Use ByteString for output (contributed by Jason Dagit, with modifications)

On 11/14/06, Bulat Ziganshin wrote:

...

Hello Malcolm,

Tuesday, November 14, 2006, 8:49:31 PM, you wrote:

...
involved, which is why I choose a different route. I am open to further ideas about how to best achieve a similar effect (i.e. ByteString ops available, but minimal code duplication).

use Stringable class from fps-soc

...

From my point of view, I don't think I would have needed to write any code when I modified HaXml if the pretty printer provided a lazy bytestring version. Maybe the more fundamental solution here would be to create a lazy bytestring version of the pretty printer?

It would also be nice if the pretty printer came with a version that runs in instances of MonadIO so that they write their output eagerly instead of lazily. My experience with haskell tells me that laziness is wonderful, especially when you can separate the concerns of computation and IO. But, sometimes it seems that when you move to the optimization phase of a project that, that same approach becomes a problem and sometimes you end up needing to do your IO as soon/often as you can to keep from having poor space behavior. HTH, Jason

Duncan Coutts

7:21 p.m.

New subject: Re[2]: patch applied (packages/HaXml): Use ByteString for output (contributed by Jason Dagit, with modifications)

On Tue, 2006-11-14 at 14:53 -0800, Jason Dagit wrote:

...

On 11/14/06, Bulat Ziganshin wrote:

...
Hello Malcolm,

Tuesday, November 14, 2006, 8:49:31 PM, you wrote:

...
involved, which is why I choose a different route. I am open to further ideas about how to best achieve a similar effect (i.e. ByteString ops available, but minimal code duplication).

For minimal code duplication make it generate ByteString internally and have the String version just call pack/unpack. If I remember correctly, unpack is lazy (and if it isn't, it should be).

...

It would also be nice if the pretty printer came with a version that runs in instances of MonadIO so that they write their output eagerly instead of lazily. My experience with haskell tells me that laziness is wonderful, especially when you can separate the concerns of computation and IO. But, sometimes it seems that when you move to the optimization phase of a project that, that same approach becomes a problem and sometimes you end up needing to do your IO as soon/often as you can to keep from having poor space behavior.

The Text.PrettyPrint.HughesPJ module can output to various targets using the fullRender function: fullRender :: Mode Rendering mode -> Int Line length -> Float Ribbons per line -> (TextDetails -> a -> a) What to do with text -> a What to do at the end -> Doc The document -> a So you can produce String, ByteString, do IO directly etc. Note how it doesn't need MonadIO or anything, it's a pure function. So for example: hRender :: Handle -> Doc -> IO () hRender h = fullRender blah blah blah hPut where hPut (Chr c) next = hPutChar h c hPut (Str c) next = hPutStr h s Note that Text.PrettyPrint.HughesPJ originally envisaged optionally using a packed string type: the TextDetails has a PStr constructor for a packed string type. However at the moment that's also just String, perhaps we should change that to Data.PackedString once the new implementation of PackedString is available. Duncan

Takano Akio

15 Nov 15 Nov

4:47 a.m.

New subject: Re[2]: patch applied (packages/HaXml): Use ByteString for output (contributed by Jason Dagit, with modifications)

On Wed, 15 Nov 2006 00:21:55 +0000 Duncan Coutts wrote:

...

On Tue, 2006-11-14 at 14:53 -0800, Jason Dagit wrote:

...
On 11/14/06, Bulat Ziganshin wrote:

...
Hello Malcolm,

Tuesday, November 14, 2006, 8:49:31 PM, you wrote:

...
involved, which is why I choose a different route. I am open to further ideas about how to best achieve a similar effect (i.e. ByteString ops available, but minimal code duplication).

For minimal code duplication make it generate ByteString internally and have the String version just call pack/unpack. If I remember correctly, unpack is lazy (and if it isn't, it should be).

That way, I'm afraid you lose the ability to handle characters outside Latin-1. Regards, Takano Akio

Duncan Coutts

8:08 a.m.

New subject: Re[2]: patch applied (packages/HaXml): Use ByteString for output (contributed by Jason Dagit, with modifications)

On Wed, 2006-11-15 at 18:47 +0900, Takano Akio wrote:

...

On Wed, 15 Nov 2006 00:21:55 +0000 Duncan Coutts wrote:

...
On Tue, 2006-11-14 at 14:53 -0800, Jason Dagit wrote:

...
On 11/14/06, Bulat Ziganshin wrote:

...
Hello Malcolm,

Tuesday, November 14, 2006, 8:49:31 PM, you wrote:

...
involved, which is why I choose a different route. I am open to further ideas about how to best achieve a similar effect (i.e. ByteString ops available, but minimal code duplication).

For minimal code duplication make it generate ByteString internally and have the String version just call pack/unpack. If I remember correctly, unpack is lazy (and if it isn't, it should be).

That way, I'm afraid you lose the ability to handle characters outside Latin-1.

Then wait until we have the new ByteString-based Data.PackedString which will handle full Unicode. Duncan

6761

Age (days ago)

6762

Last active (days ago)

List overview

Download

5 comments

5 participants

participants (5)

Bulat Ziganshin
Duncan Coutts
Jason Dagit
Malcolm Wallace
Takano Akio