Thanks. i understand that a2ps is rather for printing. What I had in mind what to pp my own programs, to clean the source layout, rather. The process i used in other context is to hack , without really taking care of the layout ( say getting distracted by) , and once i got a resonalble level of stability, i cleaned the program, using a pp; ideally in haskell, this would add the typing for me, also. ( still havent made my religion if that's cool to have the typing on top of the definition, or not, but at least for doc generation purpose, that's good.) feedback on that ? so the two gain i was expecting were : - cleaning the layout, after i removed all the debugging code - generating the type but i understood from Per from that the parser would not take care of the comments. ( not take care, or remove , btw ?). 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 wonder what am i missing ? what is different in the process of creation so that this need did not arised already? i should admint i'm puzzled, given the facilities at hand...
Alle 16:05, marted� 23 settembre 2003, Luc Taesch ha scritto:
are there any facility to pretty print an haskell program ?
If what you need is an external program and not a library, have a look at GNU a2ps.
Vincenzo
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Hi all, I'm not sure I'll answer the question properly, but I think it raises an interesting issue, regarding the state of Haskell front ends.
What I had in mind what to pp my own programs, to clean the source layout, rather.
so the two gain i was expecting were : - cleaning the layout, after i removed all the debugging code - generating the type
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 wonder what am i missing ? what is different in the process of creation so that this need did not arised already? i should admint i'm puzzled, given the facilities at hand...
Is this what you are after? A tool to read in Haskell source, and then print it out (to file or screen) in a pretty printed manner. It should retain comments from the source. And possibly add type annotations. Such a tool would be very nice indeed. Though I do not think such a thing exists at the moment. Why not? Good question. One thing that Haskell is really lacking (IMO) is a common front end. Something that can lex, parse, type check ... do all the things that a compiler or interpreter would do before it starts to generate code. Such a thing would be great for many people. It would help define the language. It would help implementors and researchers. It would probably even serve as a good source of example Haskell code for those looking to study the language. And, importantly, it would enable Haskell specific editors, refactorers, pretty printers and so on. Some work has been done towards this, including the hsparser library and supporting material that comes with GHC these days. I have been a very happy client of that parser for a long time now (sorry about the pun). At the recent Haskell workshop I saw a presentation about the nice tools that the Programatica group are working on. This seems to include most of the front end of a Haskell system. http://www.cse.ogi.edu/PacSoft/projects/programatica/ It appears that binary forms of their programs are available: http://www.cse.ogi.edu/~hallgren/Programatica/download/ Alas, I could not find a source distribution and I'm not sure if one exists. One problem I see is that it is hard to justify the large amount of work that is required to implement such a thing when it might not be regarded as research worthy. Though, in the long run I think the research community is being held back because we must continually re-implement the front end of Haskell, and often we only get part way through it before we run out of steam (see Hatchet for example, I'm a guilty party...). We owe it to ourselves to implement a front end. Though I fully appreciate the difficulty of the task, and I'm not putting my hand up to do it at the moment (grumble, thesis writing, grumble). Perhaps there are some keen Haskell hackers out there who are itching for a nice project? And by the way, I don't want to sound like I'm complaining too much, because, as I said, I've been using the hsparser and pretty printer extensively, and I failed to finish Hatchet. Cheers, Bernie.
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 wonder what am i missing ? what is different in the process of creation so that this need did not arised already? i should admint i'm puzzled, given the facilities at hand...
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. The problem I was solving in that was paper was how to pretty-print *data-structures* from inside a program. That includes abstract syntax trees in compilers -- in fact, that's maybe the most important application. The library is used in GHC, for example, to pretty-print programs at various stages, after varying degrees of transformation. You the user can see what the compiler has produced after each phase, and you see it laid out in a readable format. Pretty-printing data-structures is quite different from pretty-printing *programs* -- we should have two different words for it, really! When you pretty-print a program, you just want to change the layout in an existing text, and comments etc. ought to be preserved and appear in sensible places afterwards. When we pretty-print programs, there is an input (the program as you wrote it) to take into account. When you pretty-print a data-structure, you're just trying to output something produced by a program... there is no "input" it was produced from which the pretty-printed output ought to resemble. So, if you want to see what GHC has produced after phase X, then the pretty-printing library is appropriate. Of course, if there were comments in the program you wrote, then you ought to realise the compiler discarded them early, and you should not expect them to appear in the result of various transformations/optimisations. But if you want to standardise the layout of a program you wrote, then this is no good. The pretty-printing library is not sufficient to do this by itself... it solves a different problem. It is possible to BUILD a program pretty-printer using the library (although this is not the only possible approach), but it requires combining the library with a parser which loses no information, in particular including comments at the appropriate places in abstract syntax trees, so that they are a part of the data structure being pretty-printed. The problem is that parsers in compilers don't keep track of comments... instead they discard them at the first opportunity (during lexing). Thus such a parser, combined with a pretty-printer, cannot solve the *program pretty-printing* problem. What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree. Figuring out what a comment is really commenting is probably extremely hard... But without an AST with attached comments in the right places, my pretty-printing library, and Simon PJ's extension, are useless. That said, maybe it is surprising that no good Haskell pretty-printer has appeared yet, especially given the importance of layout in the language. Why not write one? I dare say there would be many users, and no doubt you could publish a paper at the Haskell Workshop... John Hughes
On woensdag, sep 24, 2003, at 17:46 Europe/Amsterdam, John Hughes wrote:
What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree. Figuring out what a comment is really commenting is probably extremely hard...
The commenting conventions of Haddock serve this purpose pretty well. And Haddock's parser must hold onto the comments to do its job. Maybe that's a good place to start on a Haskell pretty-printer. Regards, Frank
John Hughes <rjmh@cs.chalmers.se> writes:
The problem is that parsers in compilers don't keep track of comments. Instead they discard them at the first opportunity (during lexing). ... What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree.
Fortunately, there *is* one Haskell parser already which preserves comments in the source code and links them properly to the surrounding program structure, namely Haddock, the automatic-documentation generator. I expect Haddock would be a good place to start if one wanted to develop a program re-formatter. (Furthermore, if one were to add a type inference engine that could fill-in missing type signatures in a program, that would be highly useful for both Haddock and the hypothetical re-formatter.) Regards, Malcolm
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-)
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@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 | ==================================================
Am Mittwoch, 24. September 2003, 18:01 schrieb Keith Wansbrough:
[...]
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.
Let me add that there are situations where you don't want the most general type (which is yielded by type inference) as the type of a specific variable (which can be a function, of course). One reason might be that the most general type doesn't fit your idea about what the variable (function) shall describe. You could, for example, describe mappings from keys to values as lists of key value pairs. An empty mapping would be implemented as []. The type of this would be infered as [a] but what you want is [(a,b)]. Another reason for giving a type signature with a restricted type is that you want to enforce certain constraints by the type system. A good example is Peter Thiemanns handling of HTML documents in his WASH/CGI software. Note also that the asTypeOf function from the prelude is essentially the const function; the only difference is the type. It's the restricted type of asTypeOf that lets this function fulfill its purpose.
Hope this helps..
--KW 8-)
Wolfgang
participants (8)
-
Bernard James POPE -
Frank Atanassow -
Iavor Diatchki -
John Hughes -
Keith Wansbrough -
Luc Taesch -
Malcolm Wallace -
Wolfgang Jeltsch