From: Tim Bradshaw
Subject: PROGN for *ML?
Date: 
Message-ID: <fbc0f5d1.0111130436.aed3b07@posting.google.com>
This is not really a Lisp question but (as usual) I suspect I'm more
likely to get a sane answer here than anywhere else.

I have a system which takes a parse tree from a markup language (TML,
which is sort of like XML with sane syntax and most of the gratuitous
complexity excised) and rewrites it under the control of Lisp code,
typically resulting in something I can emit as HTML.

One sample of this is a thing called TOCIFY, which generates a TOC. 
At the parse-tree level:

   (tocify ()
     ...
     (h1 () "head")
     ...
     (h2 () ...)
     ...)

expands to something like this

   (ul ... toc here ...)
   ...
   (h1 () (a (:name "TOC0") "head"))
   ...

And this demonstrates the problem: TOCIFY needs to produce *several*
results - the UL and then all the stuff in the body with headers
rewritten to have As inside.  If this was a Lisp macro it would expand
to PROGN:

  (defmacro defun-verbosely (fname args &body body)
    `(progn
       (print ',fname)
       (defun ,fname ,args ,@body)))

But, as far as I'm *aware* this is not possible in HTML - there's no
element you can wrap around any other set of elements in the way you
can with PROGN in Lisp.  So instead I have to support `splicing'
macros, which work OK but complexify the implementation somewhat and
(worse) make various things I want to be able to do hard.

So I have two questions:

1. Am I right to think there is no general PROGN-type element in HTML?
 (I realise that most browsers will just ignore elements they don't
know, so I could simply invent PROGN and it would `work', but I'd like
not to do that.)

2. I suspect that it might be very hard to define such an element in
an SGML/XML DTD at all, without huge work.  Basically as far as I can
see this would have to work by saying that if any element had content
model x, then it could also have a content model of PROGN, and somehow
the PROGN would then have a content model of x.  But I'm by no means
an SGML/XML expert and I could be just confused about this.  But if
I'm right, then I need splicing. So, does anyone know if this is
correct?

Thanks,

--tim

From: Erik Naggum
Subject: Re: PROGN for *ML?
Date: 
Message-ID: <3214652776114128@naggum.net>
* Tim Bradshaw
| 1. Am I right to think there is no general PROGN-type element in HTML?

  You could probably get away with using SPAN.

| 2. I suspect that it might be very hard to define such an element in an
| SGML/XML DTD at all, without huge work.  Basically as far as I can see
| this would have to work by saying that if any element had content model
| x, then it could also have a content model of PROGN, and somehow the
| PROGN would then have a content model of x.

  This is done by faking it.  ANY is a valid content model.  Then you write
  up a "semantic contraints" paragraph in your "specification" that burdens
  your implementation with what the *ML "validator" should have done.

///
-- 
  Norway is now run by a priest from the fundamentalist Christian People's
  Party, the fifth largest party representing one eighth of the electorate.
-- 
  Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
From: Tim Bradshaw
Subject: Re: PROGN for *ML?
Date: 
Message-ID: <fbc0f5d1.0111140327.28756a6b@posting.google.com>
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> 
>   This is done by faking it.  ANY is a valid content model.  Then you write
>   up a "semantic contraints" paragraph in your "specification" that burdens
>   your implementation with what the *ML "validator" should have done.

Thanks. I think I need splicing macros...

--tim
From: Arthur Lemmens
Subject: Re: PROGN for *ML?
Date: 
Message-ID: <3BF2A3B4.69988E9@xs4all.nl>
Tim Bradshaw wrote:

> But, as far as I'm *aware* this is not possible in HTML - there's no
> element you can wrap around any other set of elements in the way you
> can with PROGN in Lisp.  

I think it doesn't really matter if it's possible in HTML, as long
as it's possible in the datastructures you're using to _represent_
the HTML. Using your example, you could rewrite

   (tocify ()
     ...
     (h1 () "head")
     ...
     (h2 () ...)
     ...)

to something like

   (sequence ()      ;; <-- Just define a new kind of parse tree node.
     ...
     (ul ... toc here ...)
     ...
     (h1 () (a (:name "TOC0") "head"))
     ...)

When you generate the actual HTML stuff, you have to walk your parse
tree anyway. Whenever you see a SEQUENCE node, you just walk its child
nodes sequentially. For the kind of parse trees in your example, you'd
get something like this:

(defun generate-html (node)
  (destructuring-bind (tag (&rest attributes) (&rest children))
      node
    (case tag
      (SEQUENCE
       (mapc #'generate-html children))
      (OTHERWISE
       ;; Do whatever you normally do.
       ))))


This way, you don't need any splicing macros.
Or am I missing something?

Arthur Lemmens
From: Marc Battyani
Subject: Re: PROGN for *ML?
Date: 
Message-ID: <50B9F1752B905AE6.3F4257C00A4BB45B.D272DFF8FEFDBC90@lp.airnews.net>
"Tim Bradshaw" <··········@tfeb.org> wrote
> This is not really a Lisp question but (as usual) I suspect I'm more
> likely to get a sane answer here than anywhere else.
>
> I have a system which takes a parse tree from a markup language (TML,
> which is sort of like XML with sane syntax and most of the gratuitous
> complexity excised) and rewrites it under the control of Lisp code,
> typically resulting in something I can emit as HTML.
>
> One sample of this is a thing called TOCIFY, which generates a TOC.
> At the parse-tree level:
>
>    (tocify ()
>      ...
>      (h1 () "head")
>      ...
>      (h2 () ...)
>      ...)
>
> expands to something like this
>
>    (ul ... toc here ...)
>    ...
>    (h1 () (a (:name "TOC0") "head"))
>    ...
>
> And this demonstrates the problem: TOCIFY needs to produce *several*
> results - the UL and then all the stuff in the body with headers
> rewritten to have As inside.  If this was a Lisp macro it would expand
> to PROGN:
>
>   (defmacro defun-verbosely (fname args &body body)
>     `(progn
>        (print ',fname)
>        (defun ,fname ,args ,@body)))
>
> But, as far as I'm *aware* this is not possible in HTML - there's no
> element you can wrap around any other set of elements in the way you
> can with PROGN in Lisp.  So instead I have to support `splicing'
> macros, which work OK but complexify the implementation somewhat and
> (worse) make various things I want to be able to do hard.

Can't you use tags without HTML output ?
You probably already have tags without closing tags like <br> or <input>.
You could have internal tags without printed representation but with the
internal content of the tag processed anyway. It's the inverse of the tags
like <br> that have a printed representation but the internal content of the
tag is ignored if there is one.

Marc
From: Tim Bradshaw
Subject: Re: PROGN for *ML?
Date: 
Message-ID: <fbc0f5d1.0111150803.5149715d@posting.google.com>
"Marc Battyani" <·············@fractalconcept.com> wrote in message news:<··················································@lp.airnews.net>...
> 
> Can't you use tags without HTML output ?
> You probably already have tags without closing tags like <br> or <input>.
> You could have internal tags without printed representation but with the
> internal content of the tag processed anyway. It's the inverse of the tags
> like <br> that have a printed representation but the internal content of the
> tag is ignored if there is one.
> 

Yes, I can.  But at the moment the output-generating code is
essentially trivial - it has no special cases at all (other than a
single `language' flag which is meant to be able to distinguish things
like XML and SGML syntaxes (I kind of avoid this stuff other than as
output, but I think XML does empty elements differently than `vanilla'
SGML for a suitable definition of vanilla) and later other, more
useful syntaxes.

Empty elements are not really a special case for me because they are
unambiguous in the source - the parse of an empty element is (br
(...)) while an element which just happens to have nothing in its body
is (p (...) ""), so the outpug-generator just checks for nullness of
the body.

I think that on balance I will live with splicing.  Most of the
ugliness is that before I had splicing I had ignoring, and now I have
both, while I reall yjust need spling and returning NIL.  Removing
this redundancy will probably make things sufficiently better.

--tim