From oleg@pobox.com Wed Mar 8 20:38:25 2006
From: oleg@pobox.com
To: haskell@haskell.org
Subject: [Haskell] Non-trivial transformations from the Haskell markup
Date: Wed, 08 Mar 2006 17:37:43 -0800
Message-ID: <20060309013743.42C1FA9D0@Adric.metnet.navy.mil>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0929948750270160595=="
--===============0929948750270160595==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
The earlier message showed that Haskell as it is can represent
semi-structured data with reasonable syntax, extensible set of `tags',
and statically enforced content restrictions. This follow-up
demonstrates non-trivial transformations of so marked-up data --
rendering data in HTML and RSS/XML. The resulting document has the
structure different from that of the original markup: hierarchies may
be flattened, some pieces of data rearranged among elements. Rendering
of a particular markup element may be truly context sensitive, e.g.,
by pulling data from the parent element. Creating an RSS document
further requires `subordinate' HTML rendering. We also demonstrate
markup transformations by successive rewriting (aka, `higher-order
tags') and the easy definition of new tags.
Our running example is rendering change log data in HTML and RSS/XML.=20
This project has been inspired by Shae Matijs Erisson, who suggested
I provide rss.xml feed for my site. You can see the ChangeLog in the
master format and its two renderings at
http://pobox.com/~oleg/ftp/ChangeLog.hs
http://pobox.com/~oleg/ftp/ChangeLog.html
http://pobox.com/~oleg/ftp/rss.xml
The updated archive
http://pobox.com/~oleg/ftp/Haskell/HSXML.tar.gz
has the complete code.
Here's a small example of the marked up semi-structured data/code in
Haskell:
> test_h =3D CLHead=20
> HeadAttrs {
> ha_description =3D "list of updates to this whole site",
> ha_DateRevision =3D (5,February,2006),
> -- snipped
> }
> (updates
> =20
> [update (5,February, 2006)
> [ui (FileURLA "Computation/lambda-calc.html" "switch")
> [[a [[code "switch"]]]] "in lambda-calculus"]
> [ui (FileURLA "Haskell/types.html" "dependently-typed-append")=
=20
> [[a "Dependently-typed" [[code "append"]]]]]
> ]
> )
Our document is made of a (heterogeneous!) sequence of update chunks;
each chunk is a sequence of update elements, which contain the URL and
additional markup. The corresponding HTML document looks like
this
Each 'ui' element turned into the HTML 'li' element. Please note that
the value of the HREF attribute of the 'a' element comes from the URL
attached to the _parent_ element. That is, rendering of the 'a'
element of the original mark-up indeed depends on the context.
The RSS code looks like the following:
<code>switch</code> in lambda-calculus
http://top/Computation/lambda-calc.html#switch
5 Feb 2006 12:00:00 GMTDependently-typed <code>append</code>
http://top/Haskell/types.html#dependently-typed-append
5 Feb 2006 12:00:00 GMT
The 'update' element from the original markup is turned into nothing,
with the update date spliced into each of the 'items'. The body of
the 'description' element contains HTML-rendered (and then encoded)
text.
The HTML transformation is done by the following code:
> toHTML (CLHead attrs updates) =3D
> render (document
> (head
> [title (ha_title attrs)]
> [meta_tag [description (ha_description attrs)]]
> [author_address]
> [meta_tag [pub_date (ha_DateRevision attrs)]]
> [head_link LR_start [href (ha_top attrs)]=20
> [title "All you can find here"]]
> )
> (body
> [h1 "Log of changes on" [[aref (ha_top attrs) "this site"]=
]]
> [p nbsp]
> [updates]
> [change_log_prev (ha_history_first attrs)]
> [change_log_prev (ha_history_last attrs)]
> )
> )
We convert the original markup into another, intermediate markup
(which, in turn, may go through a couple of more stages). It seems
that complex transformations are sometimes easier if represented as a
sequence of simple re-writings.
The RSS rendering is equally simple:
> toRSS (CLHead attrs updates) =3D
> render (as_doc (HW (RSSChannel
> (tdiv
> [title "okmij.org"]
> [GBE_description .=3D "okmij.org"]
> [GBE_language .=3D "en-us"]
> [GBE_ttl .=3D "21600"] -- 15 days
> [GBE_generator .=3D "HSXML->RSS"]
> [pub_date (ha_DateRevision attrs)]
> [rss_link (ha_top attrs)]
> [HW . UpdatesForRSS $ updates]
> )
> )))
This code demonstrates easy extensibility via 'ad-hoc' tags like
GBE_ttl. These tags still have to be declared:
> data GBE_ttl =3D GBE_ttl deriving Show
but that is the only one thing the user has to do for the tag.=20
One could have introduced the notation
["ttl" .=3D "21600"]
However, strings as element names are error prone: if the tag is
mentioned several times in the code, we have to make sure it is
spelled exactly the same way. Requiring a declaration at least
enforces the uniform spelling. Another advantage is that the tag
becomes apparent in the type of the element where it
appears. Therefore, we may do more extensive content model validation.
As mentioned already, writing an RSS document requires `subordinate'
HTML rendering, for the content of the `description' element. In our
framework, that is quite easy to accomplish. The HTML rendering code
is polymorphic over the output monad, MonadOut. To render HTML into a
string, we merely need an appropriate instance of MonadOut:
> newtype ShowMonad a =3D ShowMonad (Writer [String] a)
> deriving (Monad, MonadWriter [String])
> instance MonadOut ShowMonad where
> emit_lit x =3D tell [x]
> runShowMonad (ShowMonad m) =3D let (_,x) =3D runWriter m in x
and so we can write
> render_rss_item date url body =3D=20
> emit_elem "item" [Hint_nl] Nothing
> (Just . render . as_block $
> (tdiv
> [GBE_description .=3D=20
> (concat $ runShowMonad (runHTMLRender (render_inline False body))=
)]
> [rss_link url]
> [pub_date date]))
without any need for unsafePerformIO.
--===============0929948750270160595==--