Re: Beautifying Haskell programs (was: Re: pretty newby )
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Beautifying Haskell programs
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 [EMAIL PROTECTED] 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 | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Beautifying Haskell programs (was: Re: pretty newby )
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
