[Haskell-cafe] Templates as typeclasses?

[Mike Meyer]

On Fri, May 9, 2014 at 3:15 AM, Tobias Dammers <tdammers at gmail.com> wrote:
> 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,
      <mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140509/43790693/attachment.html>