Repository : ssh://darcs.haskell.org//srv/darcs/packages/pretty On branch : master
http://hackage.haskell.org/trac/ghc/changeset/caf486c09bac785ac78118d9c54f1de69fbc16c2 >--------------------------------------------------------------- commit caf486c09bac785ac78118d9c54f1de69fbc16c2 Author: David Terei <[email protected]> Date: Thu Aug 25 13:49:10 2011 -0700 Add IRC convo with Duncan >--------------------------------------------------------------- TODO | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 75 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index 60e7a2b..5781b90 100644 --- a/TODO +++ b/TODO @@ -18,3 +18,78 @@ though which is a problem: Also would be useful to provide render functions to produce Bytestring / Text builders. +=========================================================== + +dcoutts davidt_: are you sure that using a typeclass is faster than TextDetails? + +dcoutts davidt_: why not just add PStr back in? + +dcoutts davidt_: you can already generate different output types by using the fold (TextDetails -> a -> a) + +dcoutts e.g. using the Text builder or the new bytestring builder + +davidt_ dcoutts: So far it seems as fast but I need to do more testing, hence I haven't pushed anything yet + +davidt_ dcoutts: Yes adding PStr back in is one option but I also need to change LItString in GHC then to be backed by a bytestring which is a decent amount of work on a area thats already very boring + +davidt_ dcoutts: as long as speed isn't lost I still feel a type class is better, you can generate different outputs yes but a fixed TextDetails still fixes the storage which isn't as nice as a type class imho + +dcoutts davidt_: the problem with the typeclass is the leakage + +dcoutts that extra type param leaks out into everything + +dcoutts davidt_: and it doesn't mean you have to change LItString to be a ByteString + +dcoutts davidt_: it just means you need a conversion function, it doesn't imply any copying either since it's lazy, it'll do the conversion during the fullRender + +davidt_ yes i guess so, there are a few options here. What is the issue with the leakage though? It sounds bad but how is it practically a bad thing? I quite like the type class design + +dcoutts I think we overuse typeclasses + +dcoutts davidt_: it means your pretty printing function producing a Doc will not be compatible with mine + +dcoutts davidt_: since you'll use GDoc This and I'll use GDoc That... + +dcoutts and in this case it is for variation that isn't really needed +dcoutts it's to cope with the proliferation of string types +dcoutts when we should just not have so many string types +dcoutts davidt_: so how about using TextDetails with constructors for Char, String, Text and ByteString + +davidt_ Hmm I'll look into it I guess. + +davidt_ But I think what I want to do is a pretty simple and 'good' thing to do. I want to abstract pretty from the underlying storage of strings. As far as I can tell type classes is the best way to do this. + +davidt_ but I agree that we have too many string types + +davidt_ so I am tempted by that argument not to encourage it further + +dcoutts davidt_: btw, I expect you can convert a ghc LItString into a ByteString quite easily and cheaply + +dcoutts davidt_: or are they unpinned ByteArr#s? + +davidt_ dcoutts: Yes you probably can. Had a brief discussion about this with Simon Marlow. + +dcoutts davidt_: so there's a couple other options here + +dcoutts davidt_: you can fix the output type and allow any input string type that can be converted into it + +dcoutts davidt_: or you can fix the set of primitive input string types (ie Char, String, etc) and allow any kind of output type that can be constructed from those + +dcoutts davidt_: but allowing both means that the internal type arg has to become visible (which is the bad option imho) + +dcoutts davidt_: e.g. suppose we said that the output type should just always be a Text builder, or perhaps a ByteString builder, then we could allow primitive strings of any type that can be converted to a bytestring builder + +dcoutts ptext :: (a -> Builder) -> a -> doc + +dcoutts davidt_: in practice I bet fullRender is only used for two types: IO to write out to a handle directly, and some builder monoid + +dcoutts and the IO case is only an illusion of performance, the builder monoid will be a lot faster + +dcoutts davidt_: because a builder monoid is writing directly into a buffer too, but unlike an IO handle, there's no MVar locking overhead + +dcoutts davidt_: whichever way you do go, it'd be nice to provide render functions to produce bytestring / text builders, since people will generally not be aware that that's possible via fullRender + +dcoutts davidt_: the next bytestring release will have a fast builder monoid + +dcoutts davidt_: and text has one already + _______________________________________________ Cvs-libraries mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-libraries
