Beautifying Haskell programs

[Iavor Diatchki]

hello,
i also like pretty for simple pretty priniting tasks, but i think it is 
a bit low level.  for example, the cominators could be parameterised by 
a monad, so that one can have different printing styles, and also deal 
nicely with precedences.  one can build that functionality on top of the 
library pretty and this was done for the pretty printing component of 
the programatica project mentioned in one of the other posts.
bye
iavor



Keith Wansbrough wrote:
> John Huges wrote:
> 
> 
>>On Wed, 24 Sep 2003, Luc Taesch wrote:
>>
>>
>>>alos, Im surprised that this bland issue has not already been solved (PP
>>>lib paper looks dated 96). no offence intended, but aas im newbie, i
> 
> [..]
> 
>>As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or
>>at least explain what it offers, and what it does not.
> 
> 
> I think the reason it "looks dated" is that it pretty much solved the
> problem it was addressing.  For pretty-printing data structures, the
> solution given in that paper does a rather good job, is configurable
> in the ways you might want to configure it, and is fairly easy to use
> and understand.  No one has needed to invent a new way of doing it
> since.
> 
> 
> Regarding beautifying Haskell programs: as John says, it's not
> straightforward.  But I think the reason that there isn't such a thing
> is that most people don't need it.  We mostly use editors that allow
> us to get the indentation right, automatically, as we type the source
> in, and we take care to preserve it as we edit, because it makes the
> code easier to understand.
> 
> (note that there *are* tools for producing beautified documentation:
> Haddock lists exports, type definitions, type signatures, and argument
> and function documentation in HTML format, but it doesn't deal with
> actual code).
> 
> And your other point, Luc, about generating type signatures
> automatically, shows up something about your approach to debugging
> code.  You should always put the type signatures in as you go -
> preferably, before you write the function!  This is not just good
> design practice and good documentation, it helps you debug the
> function.  With type signatures, the compiler can see what you
> intended to write, and verify that what you did write matches it.
> Without type signatures, all it can see is that two things don't match
> - it has no idea what you meant to type.  Try it: try putting in type
> signatures, and see how much better the compiler's error messages
> become.
> 
> Hope this helps..
> 
> --KW 8-)
> 
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
> 


-- 
==================================================
| Iavor S. Diatchki, Ph.D. student               |
| Department of Computer Science and Engineering |
| School of OGI at OHSU                          |
| http://www.cse.ogi.edu/~diatchki               |
==================================================