Donald Bruce Stewart
bayer:
I couldn't find a compile-time here document facility, so I wrote one using Template Haskell:
Very nice! You should wrap it in a little .cabal file, and upload it to hackage.haskell.org, so we don't forget about it.
Details on cabalising and uploading here:
http://haskell.org/haskellwiki/How_to_write_a_Haskell_program http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/11
I was waiting for the other shoe to drop, as usual. I tweaked the code a bit, and I'm getting ready to contribute it to Hackage, as I find it useful. The current source can be found at http://www.math.columbia.edu/~bayer/Haskell/Annote/HereDocs.html Basically, it bothered me that I was using assert to figure out the file name (an idea that others have also had) because asserts disappear under optimization. I looked again at Control.Exception, and I realized that I would be better off catching a pattern-matching exception: $(hereDocs $ let [e] = [] in e) (Can anyone come up with a shorter pattern match failure, that can be used as a value here?) Of course, anything like this is like gas fireplace logs, pointlessly recreating the past. There is little wrong with simply hard-coding the file name; GHC has this nice way of letting me know when code like this gets out of sync: $(hereDocs "Strings.hs") So here is my question:
The source should live under a directory path that fits into the existing module layout guide. http://www.haskell.org/~simonmar/lib-hierarchy.html
A here document is a kind of data, but it is really a language extension, and one that depends on a GHC extension, Template Haskell. I'd go for Data.HereDocs but that doesn't seem quite right. The newbie in me doesn't want to park my car in your living room, so to speak. What's the right place for this?