Talk:How to write a Haskell program

How do people feel about

#!/usr/bin/env runhaskell
\begin{code}
import Distribution.Simple
main = defaultMain
\end{code}

instead of

#!/usr/bin/env runhaskell

> import Distribution.Simple
> main = defaultMain

dons 07:59, 31 October 2006 (UTC)In fact, just this works:

#!/usr/bin/env runhaskell
import Distribution.Simple
main = defaultMain

which is simplest of all

Directory structure

Shouldn't the advise be to let all the source code be collected under src/ and the testing under test/ extra scripts under scripts/ etc.?

Thanks!

I was putting off (and meaning to get around to) cabalising my software until I saw how easy it was on this page. BTW, I kinda like the birdtracks as is -- kowey 09:20, 31 October 2006 (UTC)

Imported to the wikibook

I'm using this tutorial to bootstrap a the Haskell wikibook Packaging chapter. The wikibook version diverges somewhat in that it ignores the Haskell community stuff, and (one day) tries to flow with the rest of the book. -- EricKow 15:33, 10 January 2007 (UTC)

Error message about license field

Just as a heads up, I'm getting this error message after creating a project with mkcabal:

$ runhaskell Setup.lhs configure
Setup.lhs: testing.cabal:4: Parse of field 'license' failed:

Upon inspection, it seems that it doesn't like 'GPL2' or 'GPL3'. I manually changed it to 'GPL', as shown in the wiki page, and it worked. I tested this on ghc 6.6 and ghc 6.6.1. --tanimoto

Perhaps submit a patch to add support for other licenses? dons 09:25, 12 July 2007 (UTC)

Thanks, dons, but let me check to see if this is actually due to the fact that I'm using an older version of Cabal. tanimoto

ghci :module

There is a line like this

Prelude> :m + Data.LTree

This didn't work form me since :m isn't specific enough for ghci. There is also a :main command (I guess :main is new). It should be changed to either :mo or :module

"Literate programming"

As a long-time imperative-language programmer new to Haskell, I would like to encourage the use of "literate programming" (writing programs to be read and understood by humans, not just computers) in Haskell. Donald Knuth's arguments for literate programming in imperative languages apply even more strongly to functional languages due to their terseness. Therefore, I suggest that literate programming be encouraged as a best practice along with all the other practices in this excellent article.

My experience so far is that I attempt to skim Haskell code as if it were Python and (of course) I can't do this. While I (as reader) need to slow down, I believe that my skimming approach will be repeated by others coming to Haskell from imperative languages. To me, this points to the benefit of the Haskell programmer using the literate style to inform the reader of the essence of the functions and assist the reader in understanding the code. I believe this will enhance both the understanding of particular programs and the adoption of functional programming languages in general. -- HowardBGolden 07:54, 2 January 2008 (UTC)