Dorai Sitaram <ds26@bunny.gte.com> wrote:
+---------------
| Bijan Parsia <bparsia@email.unc.edu> wrote:
| >Latte (<http://www.zanshin.com/latte/home.html>), OTOH, seems to be
| >basically scheme embedded in the text stream with TeXish delimiters
| >(i.e., '{}' instead of '()', and \ to mark variables & functions). Why
| >it isn't written *in* a Scheme, I'm not sure :)
...
| Thanks for the pointer. Latte looks very interesting indeed. I've been
| toying with the idea of using (actual) Scheme to dictate the way a text is
| transformed into another text, somewhat in the manner of TeX...
| (http://www.cs.rice.edu/~dorai/mistie/mistie.html).
+---------------
Thanks to both of you for the pointers!!
I've been using Scheme to generate HTML, too, but both Latte & Mistie
look much more thought-out than my one-afternoon "xi2html" hack, which
was basically just a filter with hard-coded TeX-like escape sequences
to call Scheme procedures.
Its default behavior is to copy input to output, but any backslash
causes a Scheme (eval (read)) [well, after checking for comments].
If the result is a string or a list of strings, it's just queued for
later output. If it's a procedure, zero or more {}-bracketed args
are gathered (depending on the arity of the procedure), the procedure
is called, and its value is queued. A tree-walk & display of the queued
stuff is done at the end. Somewhat like Dorai's Mistie, everything else
is done by defining Scheme procedures.
[Note: The motivation for queueing the output was to allow "outer"
tag-like procedures to post-process the output from "inner" procedures,
allowing some context-sensitivity (that I've never used yet). Also,
it made the argument-gathering a little easier.]
Unfortunately, this naive approach to generating HTML (i.e., modeling
HTML tags one-for-one with Scheme procedures) ended up with way too many
brackets for my taste, and resulted in a disappointingly small increase
in clarity compared to the HTML it generates:
% cat foo.xi
\html{\head{\title{My Test Document}}
\body{
\h1{My Test Document}
\h3{Testing One's Documents }
\p{
The SGI\tm Origin\reg server
family runs test documents really fast.
\; it's probably best to put procedure defs in a separate file, but
\; you *can* put them in-line, if you like.
\(define (simple-table . x)
(list "<TABLE>" (map simple-table-row x) "</TABLE>"))
\(define (simple-table-row x)
(list "<TR><TD>Item: " x "</TD></TR>" #\newline))
\simple-table{123}{45}{987}
...blah blah blah...
}
\p{
Another paragraph here.
}}}
% xi2html < foo.xi
<HTML><HEAD><TITLE>My Test Document</TITLE></HEAD>
<BODY>
<H1>My Test Document</H1>
<H3>Testing One's Documents </H3>
<P>
The SGI<font size="-1"><sup>TM</sup></font> Origin® server
family runs test documents really fast.
<TABLE><TR><TD>Item: 123</TD></TR>
<TR><TD>Item: 45</TD></TR>
<TR><TD>Item: 987</TD></TR>
</TABLE>
...blah blah blah...
</P>
<P>
Another paragraph here.
</P></BODY></HTML>
%
Making blank lines be significant, as in Latte & Mistie (& TeX),
would help reduce the bracket count, I suspect. And since "xi2html"
already does some ad-hoc character lookahead anyway (to pick up Scheme
comments before doing a "read"), it shouldn't be too hard to add
[though the generality of Dorai's "defchar" is more elegant].
-Rob
-----
Rob Warnock, 8L-846 rpw3@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA