Mon, 3 Oct 2005 00:00:00 UT

Fifth issue of The Monad.Reader, Haskell Web Dev framework

Issue Five of The Monad.Reader is online now. Check it out!

The band 1881 has a tasty track called Takin' Over. It's good music for unicycling!

The Haskell web dev idea from yesterday made some progress today. I spoke to Dominic Fox about it today on #haskell. I believe the central point is:

<poetix> Having a data model for all the pieces of your system is very powerful, and being able to do graph-traversals and transformations on that model - if it is graph-shaped - is important (and is also where SQL DBMSs tend to fall down)

Here's the conversation:
<shapr> poetix: Was talking to pesco and Malcolm, Malcolm mentioned that Haskell2Xml is the ShowXml I've been wishing for, and pesco talked about a graph structure to automatically build navigation.
<poetix> That sounds promising
<shapr> I like the idea of Haskell2Xml for the 'Naked Datatypes' approach.
<shapr> musasabi's hswebforms does something like this already, automatically deriving edit/view forms from HaskellDB database tables/rows.
<poetix> Would you output XHTML directly, or pass XML to XSLT to generate pages?
<shapr> the latter
<shapr> Ok, so assuming this idea will really work, how do you change the Graph?
<poetix> You have some serialized representation of it stored somewhere, presumably
<shapr> I'm just trying to figure out how to get all of today's webapp server features with this sort of Haskell-esque approach.
<poetix> I like the idea of having a purely functional implementation of the sitemap, such that old values are still accessible
<poetix> So you can roll forward and roll back between versions of the site
<poetix> Ditto for content - every page has a history of diffs, like a wiki page
<shapr> poetix: Or just make darcs part of the framework..
<KrispyKringle> shapr: You don't really need to use something as big as darcs, though. You aren't going to have any branching, presumably. You could just keep a list of diffs for a page.
<shapr> You will have branching.
<poetix> I think darcs makes the pure functional approach to data explicit - it's the kind of VCC a Haskell programmer would create
<KrispyKringle> Why would you have branching?
<shapr> Because, development versions of websites happen all the time.
<shapr> Zope/Plone each have their own support for 'versions' where you can sort of not commit a bunch of changes.
<poetix> But you typically have development, staging and production on separate servers
<shapr> poetix: Only in a 'real' development environment.
<poetix> Or at least sandboxed from each other
<shapr> My clients have trouble scraping up a single 600MHz server.
<KrispyKringle> Not to allow development to be done on the production machine.
<shapr> KrispyKringle: Sanity dictates that development not happen on the production machine. Clients are often insane.
<shapr> I asked Malcolm about using 'subDTDs' for 'typechecking' something like TAL. He said that was a planned feature of HaXml, but the funding ran out.
<shapr> poetix: So how do you build a CMS with this structure?
<poetix> Well, versioning is a major feature of CMSes, and versioning happens to be something that a pure semantics supports very nicely
<poetix> The more I think about it, the more I like the idea of multiple branches also
<poetix> One site customised for multiple purposes
<poetix> I don't think the details of serving HTTP requests or building web pages are the interesting design areas here - I think it's the data model that wants thinking about
<poetix> Can you have a datatype that represents a site at times T1...n, for users U1...n
<shapr> Crazy as it sounds, I think Oleg's transactional subcontinuation zippers are a good approach here.
<shapr> poetix: subcont zipper is sort of like multiple futures.
<poetix> Having a data model for all the pieces of your system is very powerful, and being able to do graph-traversals and transformations on that model - if it is graph-shaped - is important (and is also where SQL DBMSs tend to fall down)
<poetix> Yes, it seems like a theory of patches for data
<poetix> How would you persist a "zipped" data structure mid-"zip", along with details of the "zipping" in progress?
<poetix> It seems to me that the zipper gives you a very rich and powerful semantics for all the transitional states between one definite version of a data structure and another definite version.
<shapr> poetix: The way I understand it, the subcont zipper is such that each node is a continuation/cursor (database-cursor style) to a possible future.
<poetix> shapr: Right. So how do you persist something like that?
<poetix> shapr: If I could figure out a representation of the Zipper in terms of, say, relations and operations on those relations - export it from the Haskell type system, and express it in terms that an RDBMS can work with, then that would be a major result.
<poetix> shapr: Yes, I think what we need is inside understanding of what the Haskell version of Oleg's Zipper actually represents - then we can work out how to create a serialized representation of it.

So now I just need to read up on this enough to make it happen.

Speaking of which, I don't think I ever mentioned the second part of Oleg's Zippers on my blog. The third part is ZFS, Zipper-based file server/OS.