Rename todo document
[packages/pretty.git] / docs / new-pretty.md
1 1. I want to eliminate the duplicate of this library in
2 GHC. The underlying TextDetails store types are different
3 though which is a problem:
4
5  -> Use type classes (see new-pretty branch).
6     [Duncan not a fan.]
7          [Make sure performance not lost.]
8
9  -> Use a better underlying storage type.
10     [Say add bytestring and text to TextDetails.]
11
12  -> Use a fixed underlying storage type like
13     Builder from Text or Bytestring but allow
14          input functions to take any type that can be
15          converted into one.
16          [ptext :: (a -> Builder) -> a -> Doc
17
18 Also would be useful to provide render functions to produce
19 Bytestring / Text builders.
20
21 2. Add monadic wrapper (check out haskell-src-exts for example although maybe
22 use a transformer monand...)
23
24 ===========================================================
25
26 dcoutts         davidt_: are you sure that using a typeclass is faster than TextDetails?
27
28 dcoutts         davidt_: why not just add PStr back in?
29
30 dcoutts         davidt_: you can already generate different output types by using the fold (TextDetails -> a -> a)
31
32 dcoutts e.g. using the Text builder or the new bytestring builder
33
34 davidt_ dcoutts: So far it seems as fast but I need to do more testing, hence I haven't pushed anything yet
35
36 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
37
38 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
39
40 dcoutts         davidt_: the problem with the typeclass is the leakage
41
42 dcoutts that extra type param leaks out into everything
43
44 dcoutts         davidt_: and it doesn't mean you have to change LItString to be a ByteString
45
46 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
47
48 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
49
50 dcoutts I think we overuse typeclasses 
51
52 dcoutts         davidt_: it means your pretty printing function producing a Doc will not be compatible with mine
53
54 dcoutts         davidt_: since you'll use GDoc This and I'll use GDoc That...
55
56 dcoutts and in this case it is for variation that isn't really needed
57 dcoutts it's to cope with the proliferation of string types
58 dcoutts when we should just not have so many string types
59 dcoutts         davidt_: so how about using TextDetails with constructors for Char, String, Text and ByteString
60
61 davidt_ Hmm I'll look into it I guess.
62
63 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.
64
65 davidt_ but I agree that we have too many string types
66
67 davidt_ so I am tempted by that argument not to encourage it further
68
69 dcoutts         davidt_: btw, I expect you can convert a ghc LItString into a ByteString quite easily and cheaply
70
71 dcoutts         davidt_: or are they unpinned ByteArr#s?
72
73 davidt_ dcoutts: Yes you probably can. Had a brief discussion about this with Simon Marlow.
74
75 dcoutts         davidt_: so there's a couple other options here
76
77 dcoutts         davidt_: you can fix the output type and allow any input string type that can be converted into it
78
79 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
80
81 dcoutts         davidt_: but allowing both means that the internal type arg has to become visible (which is the bad option imho)
82
83 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
84
85 dcoutts ptext :: (a -> Builder) -> a -> doc
86
87 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
88
89 dcoutts and the IO case is only an illusion of performance, the builder monoid will be a lot faster
90
91 dcoutts         davidt_: because a builder monoid is writing directly into a buffer too, but unlike an IO handle, there's no MVar locking overhead
92
93 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
94
95 dcoutts         davidt_: the next bytestring release will have a fast builder monoid
96
97 dcoutts         davidt_: and text has one already
98