LSP - http://www.cliki.net/LSP
LSP for Hunchentoot - http://common-lisp.net/pipermail/tbnl-devel/2007-May/001324.html
XLMP - http://sourceforge.net/projects/lsp
CLHP - http://common-lisp.net/project/clhp/

I've also come across ALP [1] which is a research paper but no code.
CL-EMB [2] supports the "server pages" style, but requires passing an
"environment" to the evaluation function.  This isn't ideal.

Have I missed any?  Does anyone have experience with the above
libraries?

Thanks,

Walter

..and I think something like CL-WHO is an even better idea yet:
  http://weitz.de/cl-who/

http://opensource.franz.com/aserve/aserve-dist/webactions/doc/webacti...

I've been very happy with this combination with CL-SQL under
SBCL/Linux. However, this is probably not the most popular combination
as it seems like a lot of people adopt to Hunchentoot these days.

Thanks,

Thanks,

Walter

Whatever you choose, Terence Parr makes a good argument for functional
template design.  In a nutshell, the output is a simple cross product
of the template format and the specific data.  Mixing fancier code in
with the templates tends to be bad.

I recommend reading a couple of his papers before getting started.

http://www.stringtemplate.org/about.html

Yes, CL-WHO & HTOUT & HTMLGEN (and others shown on this page
<http://www.cliki.net/Lisp%20Markup%20Languages>) are *extremely*
nice to use, IMHO, mainly because you can nest HTML templates inside
Lisp code inside HTML templates inside Lisp code... as far as you like.

What they lack (of course) is an infrastructure that makes them
easy to use as more-or-less standalone web page source files.
But it's actually very easy to wrap a trivial "defsystem"-like
thing around a LOAD, so that if you haven't LOAD-ed a page before
then do so and "auto-register" it, and if there is a compiled
version then you check to see if the source is newer and if so
recompile/reload that, etc. That's what I did back circa 2002
[as part of *my* first major production use of CL], and came up
with my LHP ("Lisp-Handled Pages") format, of which you can see
samples here:

    http://rpw3.org/hacks/lisp/minimal.lhp
    http://rpw3.org/hacks/lisp/appsrv-demo.lhp

[LHP currently uses HTOUT, though it could easily be converted
to CL-WHO or others.]

+---------------
| The Lisp-in-data would be only one of the tools in my toolbox -
| albeit a necessary one.
+---------------

Well, "necessary" might be a bit strong, since even if using CL-WHO
(or something like it) one can add an extended string readmacro
(typically #"..."#) to allow large quantities of text or HTML to
be included, including unescaped double-quotes.

But if you absolutely insist on having a "raw text" format that uses
angle brackets the way HTML/XML do, like ASP or PHP, well, people have
done that, too. Possibly the simplest version is the one I first heard
of from Erik Naggum, who called it Enamel or NML, which was later
refined by Tim Bradshaw into TML (Trivial Markup Language) and then
DTML ("TML with macros", sayeth Tim). See the following for more
details than I mention below:

    Newsgroups: comp.lang.lisp
    From: Tim Bradshaw <t...@cley.com>
    Subject: Re: Difference between LISP and C++
    Date: 24 Oct 2002 13:47:12 +0100
    Message-ID: <ey3elagc8bz....@cley.com>

Basically, all of {N,T,DT}ML use angle brackets *as* sexp parentheses --
and thus there is no separate closing tag, only a matching right angle
bracket -- but differs from {HT,X}ML in using a lexical marker (the "|"
char, in NML/TML/DTML) separating the tag and attributes (if any) from
the body of the element. In the [D]TML case, the attribute section is
a plist of naked Lisp sexps which *are* evaluated (as in HTOUT & CL-WHO),
and the body section is unevaluated plain text (thus double quotes need
not be escaped) terminated by the matching right angle. E.g., whereas
in CL-WHO or HTOUT (etc.) one might write this:

      (:html
        (:head (:title () title))
        ((:body :bgcolor "#ffffff")
         "Here is some body text, with a quoted \"foo\","
         " and here is the value of FOO: " foo))

in TML it might be written this way:

      <html |
        <head | <title | <lisp :val title |>>>
        <body :bgcolor "#ffffff" |
         Here is some body text, with a quoted "foo",
         and here is the value of FOO: <lisp :val foo |>>>

<aside|At various times, Erik used [...] or {...} to escape back into
  Lisp. I don't actually know what Tim currently uses for that these
  days in [D]TML, but at least the above is clearly feasible.>

One can unambiguously shortcut that into this (and Tim does, IIRC):

      <html<head<title<lisp :var title>>>
        <body :bgcolor "#ffffff" Here is some body text, with a
          quoted "foo", and here is the value of FOO: <lisp :var foo>>>

Parsing {N,T,DT}ML into HTOUT/CL-WHO should be trivial, and is left
as an exercise for the reader...  ;-}

-Rob

On Jan 9, 8:37 pm, r...@rpw3.org (Rob Warnock) wrote:

b) #"<a href="#section2">Go to section 2</a>"#
though I see the read macro point in general.

So...

"Expressiveness", perhaps. But I've always found the *SP approaches
to be *very* ugly & error-prone when it comes to embedding control
structures such as loops, e.g.:

   <html>
   <body>
   Here we have a sequence of numbers:
   <br>
   <?php $i=1; while($i<=5) { ?>
     This is number <?php echo $i; ?>
     <br>
   <?php $i++; }
   ?>
   </body>
   </html>

The fact that you can leave PHP-land (or ASP land, etc.) with a
left bracket unclosed is simply horrifying to me! Now try doing
this with a doubly-nested loop with additional IF-THEN-ELSEs in
them, and things get *really* messy!

And if you want to avoid that, then you have to construct (almost)
*all* of your output *inside* the *SP language [using "Response.Write"
in ASP/VBScript or "echo" in PHP], which makes it equivalent in style
[except worse, IMHO] to the HTOUT/CL-WHO-style methods -- and you're
right back to quoting all your body text & and escaping quotes in text!

    <?php
      echo "<html><body>Here we have a sequence of numbers:<br>";
      $i=1;
      while($i<=5) {
        echo "This is number " . $i . "<br />";
        $i++;
      }
      echo "</body></html>";
     ?>

+---------------
| What do the CL-WHO-esque approaches really buy someone?
+---------------

1. No such dangling brackets as above.

2. Can do everything in a natural Lisp environment, e.g.:

     (with-html-output (s *standard-output*)
       (:html
         (:body
           "Here we have a sequence of numbers:" :br
           (dotimes (i 5)
             (htm "This is number" i :br)))))

3. Have *all* of Common Lisp available.

+---------------
| > But if you absolutely insist on having a "raw text" format that uses
| > angle brackets [snip]
|
| s/angle brackets/parenthesis/g and back to you.  :)
+---------------

I don't "insist", myself, I just find HTOUT (or CL-WHO, etc.) more
convenient when writing sizable pages with lots of control flow.
E.g., a *small* example:

    http://rpw3.org/hacks/lisp/appsrv-demo.lhp

[I would show you much bigger examples with lots of tables
with variously-formatted outputs from SQL database queries,
but unfortunately they're part of clients' proprietary apps.]

-Rob

Giving a hierarchical structure to text is a long way from having a
rich data notation.

In XML, you can't for instance distinguish symbols, numbers, strings,
lists, vectors.  Not without embedding some convention for this which
requires additional parsing that is outside of XML.

What is the XML notation for a double-precision floating point number?

Complex number?

What if I want to put the 255 into XML using hex? I'm writing a Lisp
program, so I think I will pick #xFF.  The XML parser will pull that out
as a string, and we can use READ-FROM-STRING to finish the job.

Of course, a C++ programmer will pick 0xFF. Oops!

Other standards.. XML-RPC, SOAP, XQuery, XPath, XSS, SVG...
The general idea is you define a XML language and then define the sematics  
which is persumably written in something else.

On Jan 11, 3:20 am, r...@rpw3.org (Rob Warnock) wrote:

LSP (http://www.cliki.net/LSP) seems to fit the bill.  Thanks to
everyone for their input.

There are some more hacks, notably a special case syntax which looks
like <|x ... x|> where x is any character: typically this was used for
literal sections which the TML parser ignored, using |: <||html-stuff-
here-gets-passed-through||>, but in fact you could register completely
general handlers for characters this allowing embedding of completely
general things.

There was more, but I have forgotten it now - 5 years is a long
time...

I didn't mean that the ancestry was direct, only that Erik had been
talking about the defects in where SGML/HTML/XML ended up for what
seemed like "forever" (though the earliest bits I have saved are
from mid-1998), and then in August 2001 he presented Enamel/NML
(in response to a comment by *you* about using HTOUT format to
write documents instead of XML), and then you presented TML in
December 2001 ["PROGN for *ML?", about the problems of "tocify"].
From my outside perspective, the similarity was that both of you
had chosen to use "|" as the <tag|contents> separator, and that
TML looked more refined (has progressed further) than what Erik
had done, that's all. Sorry if I implied anything more.

+---------------
| > ...and then DTML ("TML with macros", sayeth Tim).
|
| DTML was Dynamic TML.
+---------------

Yes, I knew that, but in this article, you said:

    From: tfb+goo...@tfeb.org (Tim Bradshaw)
    Newsgroups: comp.lang.lisp
    Subject: Re: Be afraid of XML
    Date: 15 Mar 2004 12:04:40 -0800
    Message-ID: <fbc0f5d1.0403151204.47798...@posting.google.com>
    ...
    r...@rpw3.org (Rob Warnock) wrote:
    > Google in the c.l.l. archives for "TML", a format Tim Bradshaw
    > uses that was inspired by some postings by Erik Naggum. In TML,
    > the above would be:
    >     <operator|Ten pages of text>

    For what it's worth, we've now used TML (in its incarnation as DTML,
    which is TML with a macro system) for pretty substantial documents ...

I think that's where I must have gotten the idea that the
"dynamic" part was mainly the macros.

+---------------
| There are some more hacks, notably a special case syntax which looks
| like <|x ... x|> where x is any character: typically this was used for
| literal sections which the TML parser ignored, using |: <||html-stuff-
| here-gets-passed-through||>, but in fact you could register completely
| general handlers for characters this allowing embedding of completely
| general things.
+---------------

Neat! Thanks for the additional details.

-Rob

Sigh, one day I may have time to revive all this stuff.  Probably when
I've retired.

Sample usage:

Which leads to predictable output. I made it so i wouldn't have to
escape every single user-supplied string, forget some cases and get
bitten by cross-site scripting a year later.

The reader hack even works with paredit and emacs' paren-matching. Yay!

</shameless-plug>