Support for pretty printing in GHC
davidterei at gmail.com
Tue Aug 23 19:18:30 CEST 2011
2011/8/23 Philip Wadler <wadler at inf.ed.ac.uk>:
> Thanks. Razvan had some trouble tracking down the right library, so
> it's good to know which is the correct one to use.
> The library you pointed to has a default style with a line length of
> 100. I think this should be 72 or 80. I rarely use an interface
> where 100 characters fit on a line. Of course, one can use fullRender
> or renderStyle to supply a different line length. But if you are
> going to define a convenience function such as render, please pick a
> line default line length that is convenient for most users. (Or at
> least is convenient for me. :-)
Yes this is worth considering. However its not as simple as saying the
line length is 100 as there is also the ribbon length. I'm not that
familiar with how it works but basically my understanding is that the
line length of 100 is divided by the ribbon ratio (default 1.5) to get
67. The library then tries to put around 67 characters on a line but
allows up to 100. I need to look at the code more to see how and when
it chooses between 100 or 67 though. Perhaps better defaults would be
80 line length and a ribbon ratio to get 72 line length preferred.
> Yours, -- P
> 2011/8/22 David Terei <davidterei at gmail.com>:
>> Philip Wadler <wadler at inf.ed.ac.uk> wrote:
>>> Also, a question about the current pretty printing library.
>>> Razvan built the generic derivation of pretty printers on
>>> top of the current library,
>>> In the course of this, we realised that the library defaults
>>> to a line length of 120, which is not suitable for our
>>> purposes. For 120 to be convenient, one must use a small
>>> font by default---no good for display on an overhead, and no
>>> good for those of us with deteriorating eyesight. A line
>>> length of 72 or 80 seems to work better with most systems,
>>> as well as being a historical default widely used. Is there
>>> any way to change the library? It's rather sad that the
>>> default is hardwired and not easy to customise---this is one
>>> of the few places where I envy OO languages, which are
>>> optimised for this sort of customisation.
>> Doesn't the 'fullRender' function give you the interface you're after?
>> fullRender :: Mode
>> -> Int -- Line length
>> -> Float -- Ribbons per line
>> -> (TextDetails -> a -> a) -- What to do with text
>> -> a -- What to do at the end
>> -> Doc
>> -> a -- Result
>> But I'm not sure what you mean by default here so maybe not. Also
>> where did you find the '120' value? The default in the code seem to me
>> to be 67.
>> Most importantly though, is there a particular reason you used the GHC
>> version of Pretty as opposed to the official version?
>> The proper package already includes the Style stuff you want and you
>> are nesting your package under the same hierarchy as the Pretty
>> package. More importantly I'm currently in the process of pulling the
>> Pretty module out of GHC and having GHC use the Pretty package instead
>> as its very ugly software engineering to have these two nearly
>> identical modules. So in the next release of GHC I'm hoping to have
>> GHC's Pretty module removed.
>> 2011/8/22 Simon Peyton-Jones <simonpj at microsoft.com>:
>>> | Hackage makes it hard to format examples, so we put this information
>>> | in the Readme. Please look there, and let us know what you think is
>>> | missing.
>>> I did look! What I think would be helpful would be an example of use.
>>> | > I believe this is already available, simply by putting stuff in your .ghci file.
>>> | Possibly. Which command allows one to set a pragma? I couldn't spot
>>> :set -XScopedTypeVariables
>>> for example.
>>> | > What GHCi does is to compile (show it), where 'it' is the value just computed. So
>>> | what you want is to be able to say "use the 'show' from my library, rather than using
>>> | GHC.Show.show". Right?
>>> | Close. It may be that the programmer wants both show and the pretty
>>> | printing version (we call this 'pretty') in scope at the same time, so
>>> | perhaps two names are in order. It may also be in order to change
>>> | types: really one wants to provide a document, which is then rendered
>>> | in a specified default style.
>>> I'm not getting this. Perhaps the best thing is for you to propose a design. (For the user interaction, not for the impl.)
>>> | Sorry, I don't see how this helps. I want this to work for all data
>>> | types, not just types defined via newtype, and I don't believe
>>> | standalone deriving supports that.
>>> Again, maybe the easiest thing is to specify precisely what you want, since I'm misunderstanding.
>>> | (Also, did you mean to say
>>> | 'deriving instance' above? I can't find 'deriving' on its own.)
>>> Yes, I did, sorry.
>>> Cvs-ghc mailing list
>>> Cvs-ghc at haskell.org
> .\ Philip Wadler, Professor of Theoretical Computer Science
> ./\ School of Informatics, University of Edinburgh
> / \ http://homepages.inf.ed.ac.uk/wadler/
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
More information about the Cvs-ghc