Re: [Haskell-cafe] ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell

Graham, I'm sort of playing fast and loose with referential transparency here, as I actually am with stringTemplateFileGroup as well. They both use unsafeIO to do what they want, and in corner cases could give silly, though not dangerous results (i.e., in the sense of being hazardous to your program, these calls are substantially less worrisome than head). stringTemplateFileGroup could conceivably be in IO, if it was strict in reading all the files in the directory it was passed, but cacheSTGroup would force every access to a group to take place in IO, which would make the library somewhat of a pain to work with. My semi-justification for this is that its referentially- transparent-enough for most use cases, in that just about the only thing one would be doing with a StringTemplate result would be outputting it again in some form anyway. In my experience, being able to "hot-edit" templates for a live app is a key benefit of a templating system, and forcing everything into IO to get that seems like an undue burden on end-users. On the other hand, I'm also open to implementing an IO API that's safe and renaming the current functions to something somewhat scarier, or moving both them and their IO equivs to distinct modules so that end users could choose which to import. A number of options seem reasonable here. --Sterl. (btw, I fixed the typo you emailed me about in the repo, and also made a few other changes I documented at http:// fmapfixreturn.wordpress.com/) On Jan 16, 2008, at 8:19 PM, Graham Fawcett wrote:

On Jan 14, 2008 2:47 AM, Sterling Clover wrote:

...

HStringTemplate is a port of Terrence Parr's lovely StringTemplate (http://www.stringtemplate.org) engine to Haskell.

This is very cool.

Your docs describe a function, cacheSTGroup:

cacheSTGroup :: Int -> STGen a -> STGen a Given an integral amount of seconds and a group, returns a group cached for that span of time. Does not cache "misses."

How does this work without breaking referential transparency? Shouldn't it be in the IO monad if it is time-dependent?

Graham