Graham Klyne wrote:
S. Alexander Jacobson wrote:
Has anyone written a pure haskell xslt interpreter? If not, how difficult would it be to do so?
(Ah, another cool project idea that fell by the wayside <sigh>!)
Back when I was doing more web work in Haskell, inventing a translation of XSLT into Haskell was one of the ideas I was gestating. Unfortunately (or not), a day job came along and distracted me from that.
...
Without reading in detail, I notice subsequent debate about how to write a pure function that deals with XML constructs that might perform IO. This was one of the problems I encountered when working on HaXML: I wanted to have options to use use the parser in "pure" mode (String -> XML), but also to be able to support full XML that may require I/O (XML defines an internal subset that doesn't require processors to perform I/O). In the event, I cheated and used unsafePerformIO. But it did occur to me that by parameterizing the XML processing function with a polymorphic function to turn an entity declaration into a string, like this:
getEntityString :: Monad m => decl -> m String
then the dependency on IO could itself be parameterized. For "pure" use, an identity monad could be used, which the calling program could safely unwrap. But if external entity support is required, then the type 'm' must be (or incorporate) an IO, so the value returned to the calling program would only be accessible within an IO monad.
I feel sure this must be a known Haskell idiom for this kind of problem, but I can't say that I've noticed it anywhere. Or is there a snag I didn't notice?
#g
The Haskell Zipper-based file server/OS, as discussed at http://lambda-the-ultimate.org/node/1036 does the (Monad m) trick. The processing is largely done without knowing which Monad it is, so IO is impossible. But it can call-out to the controller, requesting an operation that requires IO. The Zipper example uses partial continuations, which may be overkill for the XML processing since you don't have interacting parallel threads.