SML dynamic web site tools (fwd)

---------- Forwarded message ----------
From: Adam Chlipala <[email protected]>
Newsgroups: comp.lang.ml
Date: Wed, 29 Sep 2004 20:01:47 +0000 (UTC)
Subject: Announce: SML dynamic web site tools
Organization: http://groups.google.com

I've released a beta version of a set of tools for developing dynamic
web sites using Standard ML. You can find them at:
	http://smlweb.sourceforge.net/

With these tools, you can develop dynamic web sites in much the same
style that PHP has popularized. You can create dynamic pages as simply
as:

* Choose a directory to contain your source files.
* Edit a configuration file to indicate where to publish the output.
* Create a few files that look like HTML with embedded bits of what is
  essentially a subset of SML.
* Run a single command-line program with no arguments.
* If any compilation errors are reported, fix them and repeat the last
  step until all is well.

There is also a set of signatures describing SQL database clients, as
well as a PostgreSQL implementation that uses the SML/NJ NLFFI. (The
feel of the interface is based on SMLserver's, though my versions are
usable apart from a web server.)


The project web site should contain enough information to learn more
about the specifics and how to use these tools. Here I'll summarize
some particular aspects, especially as they relate to reasons why I
created this when SMLserver (http://www.smlserver.org/) already
exists.

The current mlt tool produces CGI scripts as its final output. This
means that you can use it with pretty much any web server. SMLserver
uses an add-on for an unpopular web server (AOLserver). This makes
page execution more efficient, but it's a pain if, for example, you
don't have permission to install a web server or web server add-on on
the server where you want to host a site. I've experimented with a
persistent version of these tools that serves all page requests from a
single process for which the main web server acts as a proxy, making
it easier to pass information between invocations of page
templates. It's not too hard to do, so with a little work this should
be doable for cases where it's allowed.

SMLserver is specific to the ML Kit and uses its bytecode
interpreter. Naturally, this is inconvenient when you'd rather use
another SML compiler or when you want the performance benefits of
native execution. My tools _almost_ solve the compiler specificity
problem: mlt currently requires SML/NJ, since it type checks templates
by asking SML/NJ to elaborate the SML files it uses and then grabs the
resulting environment using an SML/NJ-specific mechanism. However,
this only matters during compilation. The output of the tool should
work with any SML compiler with a tiny bit of work that I haven't
expended yet. If there is ever some sort of SML elaboration library
that works in multiple compilers, the remaining restriction might also
be eliminated. It's also worth noting that nothing about the approach
is terribly specific to SML, so, in particular, an OCaml version would
probably also be worthwhile.

My template language is designed to be a true template language and
not just SML re-packaged. It doesn't provide any way to introduce
non-termination, for instance. I've tried to keep it as simple as
possible, since it ought to be used just for presentation of
computations performed by real SML modules. This has meant avoiding a
literal transplanting of many SML language features, since they would
require a small constant factor of "boilerplate" code that I feel
would just distract from the real task. For instance:

mlt provides a facility for maintaining a mapping from types to
printer functions. When an expression is embedded in HTML, it is
printed using that function, instead of requiring potentially verbose
coercions to string type sprinkled throughout code.

In place of use of higher-order functions for iteration, I include a
single "foreach" construct for iterating over lists. The idea is that
SML code uses whatever fancy procedure it wants for producing some
data to be shown, in a linear form, and then the template performs the
simple task of translating it into HTML.

The template language has separate statement and expression
sublanguages. This might seem a step back from the simplicity of ML,
but it seems necessary to me if the language should be both simple and
admit efficient execution. The most straightforward semantics for a
template language like this is to evaluate its fragments in order,
printing each as it is evaluated. If everything is an expression, then
it would seem that we need an operator for combining expressions. Then
we can think of template execution as evaluating a single expression
and printing its result. However, with naive execution, this leads to
a quadratic factor from string concatenation, or extra complexity from
making a page result a tree of strings, or something similar to
that. Monads as in Haskell might provide a way to handle this, but
Haskell introduces some syntactic sugar to make monadic programming
easier, which is essentially what I have done with a statement
sublanguage! In any case, none of the details of the language are the
result of intense thinking sessions, so I welcome any alternate
suggestions.

One clear benefit of using such a limited template language is that it
is possible to allow untrusted people to develop templates, as long as
you limit the accessible SML environment appropriately. I have used
systems like this in the past quite successfully. You can also switch
from a "security" to a "reliability" viewpoint and see the template
language as a good way to allow web designers who have never heard of
functional programming to maintain the presentation of results from
backends that you implement in your favorite language.