On Fri, May 9, 2014 at 3:15 AM, Tobias Dammers
You can do similar things with Haskell EDSL-style template systems such as Blaze, except that Haskell is not an OOP language, so you will be using different abstractions instead.
All true, and things like Blaze are much nicer than most template systems. I've even got a Python templating system using an architecture similar to blaze (html tags are composeable functions) that fit in between the two. However, that's about the syntax for creating templates, not their fundamental nature. And of course this would use different abstractions. What's interesting isn't the abstractions, it's that they're obtained by moving templates into the type system. To take a step back: In most template systems (including Blaze), "template" is a type provided by the system, and you create an element of that type which you can then combine in some way with data to render, creating something that can be sent to a web browser. Exactly how "render" is implemented varies from system to system: methods on the template class, macros, and functions you pass a template to have all been used. In Cheetah, template is an abstract base class (typeclass being the closest Haskell analogue). A template is a class that implements that ABC (a datatype that's an instance of the typeclass in Haskell). You can treat it just like any other class. That includes creating an instance of the class (an element of the datatype) that can then be combined with data and rendered.
Still, the big picture with these is that template building blocks are language elements, and template code and regular code can be mixed freely.
And the big picture for Cheetah is that the template building blocks are TYPE elements. That's what's interesting. The functionality that falls out of it naturally depends on the type system, and is generally uninteresting. The questions I'd actually like answered is whether any Haskell template system uses a similar architecture, and whether doing so provides any interesting functionality.
If you want something that behaves more like inheritance,
I don't. As stated above, that's uninteresting. I doubt if a web app developer ever wanted inheritance. Or a monad. Any more than a carpenter ever wanted a 10mm drill bit.
Now if MarkupM were implemented as a monad transformer, we could even stack it on top of a MonadReader TemplateBlocks to avoid passing the tb parameter explicitly, and lensify the whole thing, but oh well. (BTW, is anyone aware of any efforts in making Blaze into a transformer?)
And if MarkupM were a typeclass, and your templates a datatype, then
you could think about implementing your templates as monad
transformers, instead of needing it to be done in MarkupM.
Thanks,