From: Marc Battyani
Subject: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <blbe87$gei@library2.airnews.net>
The problem when representing text and HTML in sexpr is how to differenciate
attributes from content for the text elements.

There are 5 ways that seem natural:

1) An arg list enclosing the element name:
((table :padding 5 :backgound-color 10) ... content...)))
The classical LHTML representation

2) An arg list after the element name:
(table (:padding 5 :backgound-color 10) ...content...)

3) A separator between args and content
(table :padding 5 :backgound-color 10 :content ...content...)
(the separator can be made more simple like | with a read macro
(Tim Bradshaw uses <table :padding... | ...content...>)

4) Switching from args to content when it's not a keyword anymore
(table :padding 5 :backgound-color 10 non-keyword-content...)
(Suggested by Nick Levine)

5) Switching from args to content when it's not a known attribute keyword
(table :padding 5 :backgound-color 10 non-keyword-content...)
(Suggested by me)

Other ones ?

In my web application framework I use #1
In cl-typesetting I use #2

Obviously this is not a good idea to have different representations. So I
would like your opinion on which one I should use for cl-typesetting (and my
web app framework BTW) for the intermediate sexpr lisp representation.

My present preference would be #3 or #4.

Marc
[also posted in lispweb]

From: Rob Warnock
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <nu6dncUWuMul1-SiXTWc-g@speakeasy.net>
Marc Battyani <·············@fractalconcept.com> wrote:
+---------------
| The problem when representing text and HTML in sexpr is how
| to differenciate attributes from content for the text elements.
| There are 5 ways that seem natural:
| 
| 1) An arg list enclosing the element name:
| ((table :padding 5 :backgound-color 10) ... content...)))
| The classical LHTML representation
| 
| 2) An arg list after the element name:
| (table (:padding 5 :backgound-color 10) ...content...)
+---------------

Tim Bradshaw's HTOUT lets you choose between these two semi-dynamically.
[That is, for any given instance of WITH-HTML-OUTPUT you can choose which
style the body of the macro expects.]

+---------------
| 3) A separator between args and content
| (table :padding 5 :backgound-color 10 :content ...content...)
| (the separator can be made more simple like | with a read macro
| (Tim Bradshaw uses <table :padding... | ...content...>)
+---------------

What he calls "TML", I think. Note that in TML the content doesn't need
to be string-quoted (unlike the other four styles), though < and | and >
do need to be escaped to include them in content.

+---------------
| Other ones ?
+---------------

I've played with several others, but none were better than your #1-4.
But for the record:

6) Attributes only exist if some magic marker that cannot appear in
   normal content introduces [and possibly terminates] them, e.g.:
        (:table ...content...)
   vs:
        (:table (·@ :padding 5 :background-color 10) ...content...)
   or:
        (:table ·@ :padding 5 :background-color 10 ...content...)
   or:
        (:table ·@ :padding 5 :background-color 10 ·@ ...content...)

7) [Really ugly:] Wrap attributes, if any, *around* the thing being
   modified:
	(·@ :padding 5 :background-color 10 (:table ...content...))
   or:
	(·@ :padding 5 (·@ :background-color 10 (:table ...content...)))

   or around the content:
	(:table (·@ :padding 5 (·@ :background-color 10 ...content...)))

As I said, all worse than #1-4.


-Rob

p.s. One thing to consider when choosing a style is how to intermingle
Lisp code for dynamic generation, which is why HTOUT uses keywords
for HTML tags, i.e.:

	(:table (:padding 5 :background-color 10) ...content...)
	 |

Any S-expr with a non-keyword in functional position is taken to be
Lisp executable code which can output [or return, depending on your
infrastructure's style] a sub-element, e.g.:

	(:table (:padding 5 :background-color 10)
          (loop for row in rows do
            (htm (:tr (:align "right")
                   (loop for column in row do
                     (htm (:td (:nowrap) (esc column))))))))

-----
Rob Warnock, PP-ASEL-IA		<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Pascal Costanza
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <blbetk$17ve$1@f1node01.rhrz.uni-bonn.de>
Marc Battyani wrote:
> The problem when representing text and HTML in sexpr is how to differenciate
> attributes from content for the text elements.
> 
> There are 5 ways that seem natural:
> 
> 1) An arg list enclosing the element name:
> ((table :padding 5 :backgound-color 10) ... content...)))
> The classical LHTML representation
> 
> 2) An arg list after the element name:
> (table (:padding 5 :backgound-color 10) ...content...)
> 
> 3) A separator between args and content
> (table :padding 5 :backgound-color 10 :content ...content...)
> (the separator can be made more simple like | with a read macro
> (Tim Bradshaw uses <table :padding... | ...content...>)
> 
> 4) Switching from args to content when it's not a keyword anymore
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by Nick Levine)
> 
> 5) Switching from args to content when it's not a known attribute keyword
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by me)

I think 4 & 5 are pretty bad because of possible typos. 
:background-colour would be accepted as non-keyword-content, for 
example. (Or think about a missing colon.)

What's wrong with 2? It looks similar to PROG. If you want to avoid the 
need to type (table nil ...) you could also provide TABLEN, similar to 
PROGN...

Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Edi Weitz
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <871xtymzck.fsf@bird.agharta.de>
On Tue, 30 Sep 2003 10:29:58 +0200, Pascal Costanza <········@web.de> wrote:

> I think 4 & 5 are pretty bad because of possible
> typos. :background-colour would be accepted as non-keyword-content,
> for example.

No, not in case #4.

Edi.
From: Marc Battyani
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <blbi7v$euf@library2.airnews.net>
"Pascal Costanza" <········@web.de> wrote
> Marc Battyani wrote:
> > The problem when representing text and HTML in sexpr is how to
differenciate
> > attributes from content for the text elements.
> >
> > There are 5 ways that seem natural:
> >
> > 1) An arg list enclosing the element name:
> > ((table :padding 5 :backgound-color 10) ... content...)))
> > The classical LHTML representation
> >
> > 2) An arg list after the element name:
> > (table (:padding 5 :backgound-color 10) ...content...)
> >
> > 3) A separator between args and content
> > (table :padding 5 :backgound-color 10 :content ...content...)
> > (the separator can be made more simple like | with a read macro
> > (Tim Bradshaw uses <table :padding... | ...content...>)
> >
> > 4) Switching from args to content when it's not a keyword anymore
> > (table :padding 5 :backgound-color 10 non-keyword-content...)
> > (Suggested by Nick Levine)
> >
> > 5) Switching from args to content when it's not a known attribute keyword
> > (table :padding 5 :backgound-color 10 non-keyword-content...)
> > (Suggested by me)
>
> I think 4 & 5 are pretty bad because of possible typos.
> :background-colour would be accepted as non-keyword-content, for
> example. (Or think about a missing colon.)
>
> What's wrong with 2? It looks similar to PROG. If you want to avoid the
> need to type (table nil ...) you could also provide TABLEN, similar to
> PROGN...

Nothing, it's what I use in cl-typesetting. But I'm open to better
alternatives.

Marc
From: james anderson
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <3F795150.69E02EF5@setf.de>
the first option is the correct representation. there 
are a number of things which argue for this.

there is a close relation between the intent of markup and annotated 
hypergraphs. the abstract syntax

  exp ::= ( annotation . content )
  annotation ::= name | (name . attributes )
  content ::= (exp | character-data)*
  attributes ::= attribute *
  attribute :: = (name character-data)
     [ or perhaps ( annotation . content )
       which is more general, is amenable to recursive interpretation, 
and indicates the equivalence.]

is useful for both.

the things which are called "args" below are in fact names for annotations 
for the content. it is not clear why the names need always be keyword 
constants.

one does not want to have to examine the values in the expression in 
order to determine its effective form. this inhibits abstract source 
transformations. the effective values for the names may not be available at
that time. it may not even be known which annotations or even whether an
annotation may appear at all at that time.

keywords are not sufficient to describe the name value domain.

there are reasons to include names in the value domain of both 
attribute and element content. look through the xml-dev archives for 
submissions which address "qnames in content" i have posted there 
several examples of how one should be able to operate on and serialize 
universal names in content. it would be difficult to operate abstractly 
on expressions which may incorporate universal names if the abstract 
syntax requires keyword markers.

2 obscures the symmetry between 'table' and the name of any other 
attribute. in the general case 'table' is really (generic-identifier 
"table"). look in the archives for discussions of "enabelling 
architectures" and/or attribute mapping. the authority of a given name 
is an artifact of a point of view. it does not have the same role as a 
common-lisp operator. it reamins to be shown that there is general advantage
to form which take direct advantage of the name==operator duality. any such
operators would have to be defined differently that naive functions in order
to adress deferred evaluation of content. one alternative is to define them as
macros, which means the form is being rewritten anyway. in which case a
general rewriting architecture is much more robust than one which requires
that the application define each operator. which means name==operator is not a requirement.

3 that's what the structure is for. why would one want to parse an 
abstract representation

4 and 5 requires that all names are known and constant.

On Tuesday, Sep 30, 2003, at 10:18 Europe/Berlin, Marc Battyani wrote:

> The problem when representing text and HTML in sexpr is how to 
> differenciate
> attributes from content for the text elements.
>
> There are 5 ways that seem natural:
>
> 1) An arg list enclosing the element name:
> ((table :padding 5 :backgound-color 10) ... content...)))
> The classical LHTML representation
>
> 2) An arg list after the element name:
> (table (:padding 5 :backgound-color 10) ...content...)
>
> 3) A separator between args and content
> (table :padding 5 :backgound-color 10 :content ...content...)
> (the separator can be made more simple like | with a read macro
> (Tim Bradshaw uses <table :padding... | ...content...>)
>
> 4) Switching from args to content when it's not a keyword anymore
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by Nick Levine)
>
> 5) Switching from args to content when it's not a known attribute 
> keyword
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by me)
From: Marc Battyani
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <blbl49$mfq@library2.airnews.net>
"james anderson" <··············@setf.de> wrote

> [similar, but not identical to my c.l.l response]

[replying to the latest version]

> i suggest that the first option is the correct representation. there
> are a number of things which argue for this
>
> there is a close relation between the intent of markup and annotated
> hypergraphs. the abstract syntax
>
>   exp ::= ( annotation . content )
>   annotation ::= name | (name . attributes )
>   content ::= (exp | character-data)*
>   attributes ::= attribute *
>   attribute :: = (name character-data)
>      [ or perhaps ( annotation . content )
>        which is more general, is amenable to recursive interpretation,
> and indicates the equivalence.]
>
> is a very tractable syntax for both.
>
> the things which are called "args" below are in fact named annotations
> for the content. it is not clear why the names need always be keyword
> constants.
>
> one does not want to have to examine the values in the expression in
> order to determine its effective form. this inhibits abstract source
> transformations which may not know whether a constituent at a given
> position will ultimately produce a keyword ( or even a name).
>
> keywords are not sufficient to describe the name value domain.
>
> there are reasons to include names in the value domain of both
> attribute and element content. look through the xml-dev archives for
> submissions which address "qnames in content" i have posted there
> several examples of how one should be able to operate on and serialize
> universal names in content. it would be difficult to operate abstractly
> on expressions which may incorporate universal names if the abstract
> syntax requires keyword markers.

I agree with you in the general SGML/XML case but this does not occurs very
often in the HTML and cl-typesetting case. And for this I use special
keywords like :insert-string that will insert a given string, :execute that
will execute the following form, etc...

> 2 obscures the symmetry between 'table' and the name of any other
> attribute. in the general case 'table' is really (generic-identifier
> "table"). look in the archives for discussions of "enabelling
> architectures" and/or attribute mapping. the authority of a given name
> is an artifact of a point of view. it does not have the same role as a
> common-lisp operator.

OK but in cl-typesetting 'table is a macro so it's not like any other
attribute. In my html gen macro, I also have some tabs that expands to macro
instead of being written.

> 3 that's what the structure is for. why would one want to parse an
> abstract representation
>
> 4 and 5 requires that all names are known and constant.

With 5 yes but not with 4. In 4 you switch from attributes to content when
you don't have a keyword.

What I find annoying with 1 is when you don't have any content you have to
write ((::img :src ...))

Marc

> On Tuesday, Sep 30, 2003, at 10:18 Europe/Berlin, Marc Battyani wrote:
>
> > The problem when representing text and HTML in sexpr is how to
> > differenciate
> > attributes from content for the text elements.
> >
> > There are 5 ways that seem natural:
> >
> > 1) An arg list enclosing the element name:
> > ((table :padding 5 :backgound-color 10) ... content...)))
> > The classical LHTML representation
> >
> > 2) An arg list after the element name:
> > (table (:padding 5 :backgound-color 10) ...content...)
> >
> > 3) A separator between args and content
> > (table :padding 5 :backgound-color 10 :content ...content...)
> > (the separator can be made more simple like | with a read macro
> > (Tim Bradshaw uses <table :padding... | ...content...>)
> >
> > 4) Switching from args to content when it's not a keyword anymore
> > (table :padding 5 :backgound-color 10 non-keyword-content...)
> > (Suggested by Nick Levine)
> >
> > 5) Switching from args to content when it's not a known attribute
> > keyword
> > (table :padding 5 :backgound-color 10 non-keyword-content...)
> > (Suggested by me)
From: Marc Battyani
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <blbn9c$l4h@library2.airnews.net>
"Marc Battyani" <·············@fractalconcept.com> wrote

BTW Sorry for the error in the subject line (corrected)
:(

Marc
[Who is still looking for a new name for cl-typesetting...]
From: Hans-Peter Wickern
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <f9300382.0309301048.63807cba@posting.google.com>
"Marc Battyani" <·············@fractalconcept.com> wrote in message news:<··········@library2.airnews.net>...

> [Who is still looking for a new name for cl-typesetting...]

What about:

CL-PDF-Designer


Will the current CL-PDF-functions completly integrated into the new package?

Hans-Peter
From: Marc Battyani
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <blcl0s$lki@library2.airnews.net>
"Hans-Peter Wickern" <·········@t-online.de> wrote
> "Marc Battyani" <·············@fractalconcept.com> wrote
> > [Who is still looking for a new name for cl-typesetting...]
>
> What about:
>
> CL-PDF-Designer

IMHO CL-PDF-Designer sound more like a drawing program. And it's even longer
than cl-typesetting! ;-)

> Will the current CL-PDF-functions completly integrated into the new
package?

Absolutely. And this is a a really cool feature. The current pdf example make
a lot of use of this. (like the rotated letters in circles and the wavelet
rule)
BTW I will put yet another improved example tonight.

Marc
From: Matthew Danish
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <20030930193933.GD1454@mapcar.org>
On Tue, Sep 30, 2003 at 12:52:25PM +0200, Marc Battyani wrote:
> [Who is still looking for a new name for cl-typesetting...]

TYPesetting In CL.

TYPICL.  (tie-pickle?)

-- 
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Klaus Harbo
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <87isnaoviv.fsf@harbo.net>
Matthew Danish <·······@andrew.cmu.edu> writes:

> On Tue, Sep 30, 2003 at 12:52:25PM +0200, Marc Battyani wrote:
> > [Who is still looking for a new name for cl-typesetting...]
> 
> TYPesetting In CL.
> 
> TYPICL.  (tie-pickle?)
> 

"Typical" ;-)

-K.
From: Matthew Danish
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <20030930213042.GE1454@mapcar.org>
On Tue, Sep 30, 2003 at 10:45:28PM +0200, Klaus Harbo wrote:
> Matthew Danish <·······@andrew.cmu.edu> writes:
> > On Tue, Sep 30, 2003 at 12:52:25PM +0200, Marc Battyani wrote:
> > > [Who is still looking for a new name for cl-typesetting...]
> > TYPesetting In CL.
> > TYPICL.  (tie-pickle?)
> "Typical" ;-)

I figured people would read it as that, but of course we cannot stand
for having an obvious pronounciation, right?

Not to mention, it's typesetting not tip-setting ;-)

-- 
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Marc Battyani
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <bld2t0$3mt@library2.airnews.net>
"Matthew Danish" <·······@andrew.cmu.edu> wrote in message
> On Tue, Sep 30, 2003 at 12:52:25PM +0200, Marc Battyani wrote:
> > [Who is still looking for a new name for cl-typesetting...]
>
> TYPesetting In CL.
>
> TYPICL.  (tie-pickle?)

Why not, maybe not sweet enough... ;-)

Marc
From: Ray Blaak
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <uwubogatt.fsf@STRIPCAPStelus.net>
"Marc Battyani" <·············@fractalconcept.com> writes:
> > > [Who is still looking for a new name for cl-typesetting...]

I suggest "crib", derived from "scribe" (which is really the name I prefer for
any typesetting system, but it's in use at least twice), because "cribe"
doesn't sound right, and the leading "c" gives a hint to the Common Lisp
heritage.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
········@STRIPCAPStelus.net                    The Rhythm has my soul.
From: Christopher C. Stacy
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <ud6dg3cv1.fsf@dtpq.com>
>>>>> On Wed, 01 Oct 2003 16:50:49 GMT, Ray Blaak ("Ray") writes:

 Ray> "Marc Battyani" <·············@fractalconcept.com> writes:
 >> > > [Who is still looking for a new name for cl-typesetting...]

 Ray> I suggest "crib", derived from "scribe" (which is really the name I prefer for
 Ray> any typesetting system, but it's in use at least twice), because "cribe"
 Ray> doesn't sound right, and the leading "c" gives a hint to the Common Lisp
 Ray> heritage.

See Rib.  That's written in C, right?

(Or that "See", a visual programming version of C?)
From: Cor Gest
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <87n0cko9x3.fsf@cleopatra.clsnet.nl>
How about TiCiT :  Typesetting in Cl is Trivial.


It's also a nice recursive.

cor 

-- 
	      SAFE THE INTERNET..................REMOVE WINDOWS
	      http://www.ccianet.org/papers/cyberinsecurity.pdf
  (setq  reply-to (concatenate 'string "Cor Gest "" <cor"'(··@)"clsnet.nl>"))
From: Olivier Drolet
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <599a6555.0310011832.2fe2591e@posting.google.com>
Cor Gest <···@clsnet.nl> wrote in message news:<··············@cleopatra.clsnet.nl>...
> How about TiCiT :  Typesetting in Cl is Trivial.
> 
> 
> It's also a nice recursive.
> 
> cor

I.e., TiCiT in CL is Trivial ?
From: james anderson
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <3F797653.648B665B@setf.de>
Marc Battyani wrote:
> 
> "james anderson" <··············@setf.de> wrote
> 
> > there are reasons to include names in the value domain of both
> > attribute and element content. look through the xml-dev archives for
> > submissions which address "qnames in content" i have posted there
> > several examples of how one should be able to operate on and serialize
> > universal names in content. it would be difficult to operate abstractly
> > on expressions which may incorporate universal names if the abstract
> > syntax requires keyword markers.
> 
> I agree with you in the general SGML/XML case but this does not occurs very
> often in the HTML and cl-typesetting case. And for this I use special
> keywords like :insert-string that will insert a given string, :execute that
> will execute the following form, etc...
> 

if all you need to do is serialize html w/o any namespaces, i would wonder
whether you would be better suited with macros. perhaps that's all you wre
inquiring about. i thought the issue was a general abstract syntax which would
be amenable to other processing as well.

what are you planning to do about switching between the various html forms. or
about including attributes with non-null-namespace names?

>...

> 
> What I find annoying with 1 is when you don't have any content you have to
> write ((::img :src ...))
> 

does it bother you to have to write (return)?

would you rather write

(with-open-file stream (make-a-pathname) :direction :output
	(write stream "i think this would turn into a mess."))

or

(with-open-file (stream (make-a-pathname) :direction :output)
	(write stream "i suspect this is much more usable."))

?

...
From: Marc Battyani
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <blc0dn$t4i@library2.airnews.net>
"james anderson" <··············@setf.de> wrote
> Marc Battyani wrote:
> >
> > "james anderson" <··············@setf.de> wrote
> >
> > > there are reasons to include names in the value domain of both
> > > attribute and element content. look through the xml-dev archives for
> > > submissions which address "qnames in content" i have posted there
> > > several examples of how one should be able to operate on and serialize
> > > universal names in content. it would be difficult to operate abstractly
> > > on expressions which may incorporate universal names if the abstract
> > > syntax requires keyword markers.
> >
> > I agree with you in the general SGML/XML case but this does not occurs
very
> > often in the HTML and cl-typesetting case. And for this I use special
> > keywords like :insert-string that will insert a given string, :execute
that
> > will execute the following form, etc...
> >
>
> if all you need to do is serialize html w/o any namespaces, i would wonder
> whether you would be better suited with macros. perhaps that's all you wre
> inquiring about. i thought the issue was a general abstract syntax which
would
> be amenable to other processing as well.
>
> what are you planning to do about switching between the various html forms.
or
> about including attributes with non-null-namespace names?
>

For now, I don't have any problems as I use the syntax you prefer...
I'm just looking for possible alternatives.

> > What I find annoying with 1 is when you don't have any content you have
to
> > write ((::img :src ...))
> >
>
> does it bother you to have to write (return)?

No. but ((return)) would bother me...

> would you rather write
>
> (with-open-file stream (make-a-pathname) :direction :output
> (write stream "i think this would turn into a mess."))
>
> or
>
> (with-open-file (stream (make-a-pathname) :direction :output)
> (write stream "i suspect this is much more usable."))

This one obviously but it is the syntax #2 and you said that syntax #1 was
better which would give:

((with-open-file stream (make-a-pathname) :direction :output)
 (write stream "i think this would turn into a mess."))

Which I find less readable than the 2 others.

Marc
From: james anderson
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <3F799CD0.40EAF3BA@setf.de>
Marc Battyani wrote:
> 
> 
> > would you rather write
> >
> > (with-open-file stream (make-a-pathname) :direction :output
> > (write stream "i think this would turn into a mess."))
> >
> > or
> >
> > (with-open-file (stream (make-a-pathname) :direction :output)
> > (write stream "i suspect this is much more usable."))
> 
> This one obviously but it is the syntax #2 and you said that syntax #1 was
> better which would give:
> 
> ((with-open-file stream (make-a-pathname) :direction :output)
>  (write stream "i think this would turn into a mess."))
> 
> Which I find less readable than the 2 others.

no, from the point of view of the passage where i distinguished the
exceptional position of the operator in an s-expression from the symmetry
among attributes in an annotated expression / hypergraph the standard
common-lisp exression for with-open-file is is in form 1. the point was that
the constituents which concern the same things are in structurally distinct
positions from other constituents which concern other things. neither the
reader nor the interpreter/compiler needs to examine the values in order to
make the distinction.

i suppose one criteria for me is whether it would be possiible to write
straight-forward destructuring-bind (or similar) based macros based on the
expressions. anything which did not make structural distinctions would be a
mistake in that regard. the macros for form 1, on the other hand, are
straight-forward to write[0]. even including the special-case which i note below.

the annotations as a whole are applied to the content. i suppose a more
obvious analogy would be

(lambda (x) (+ x x) | 1)

or some other abstract syntax which one would need to interrogate, instead of

((lambda (x) (+ x x)) 1)


one can establish the rule the

 (name . content)

is equivalent to

 ((name) . content)

which simplifies expressions for one of the reduced cases.

[0]http://www.cl-xml.org/documentation/howto/asexp-macros.lisp
From: Marc Battyani
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <blca9j$asf@library2.airnews.net>
"james anderson" <··············@setf.de> wrote
>
> Marc Battyani wrote:
> >
> >
> > > would you rather write
> > >
> > > (with-open-file stream (make-a-pathname) :direction :output
> > > (write stream "i think this would turn into a mess."))
> > >
> > > or
> > >
> > > (with-open-file (stream (make-a-pathname) :direction :output)
> > > (write stream "i suspect this is much more usable."))
> >
> > This one obviously but it is the syntax #2 and you said that syntax #1
was
> > better which would give:
> >
> > ((with-open-file stream (make-a-pathname) :direction :output)
> >  (write stream "i think this would turn into a mess."))
> >
> > Which I find less readable than the 2 others.
>
> no, from the point of view of the passage where i distinguished the
> exceptional position of the operator in an s-expression from the symmetry
> among attributes in an annotated expression / hypergraph the standard
> common-lisp exression for with-open-file is is in form 1. the point was
that
> the constituents which concern the same things are in structurally distinct
> positions from other constituents which concern other things. neither the
> reader nor the interpreter/compiler needs to examine the values in order to
> make the distinction.

I agree with you, it's better so this rules out 4 and 5.

> i suppose one criteria for me is whether it would be possiible to write
> straight-forward destructuring-bind (or similar) based macros based on the
> expressions. anything which did not make structural distinctions would be a
> mistake in that regard. the macros for form 1, on the other hand, are
> straight-forward to write[0]. even including the special-case which i note
below.
>
> the annotations as a whole are applied to the content. i suppose a more
> obvious analogy would be
>
> (lambda (x) (+ x x) | 1)

This is syntax 3

> or some other abstract syntax which one would need to interrogate, instead
of
>
> ((lambda (x) (+ x x)) 1)
>
>
> one can establish the rule the
>
>  (name . content)
>
> is equivalent to
>
>  ((name) . content)
>
> which simplifies expressions for one of the reduced cases.
>
> [0]http://www.cl-xml.org/documentation/howto/asexp-macros.lisp

If I understand correctly your arguments, we agree that case 1, 2 and 3 are
different syntaxic flavors of the same expression.

So what is your vote between those 3 ?

Marc
From: Ray Blaak
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <u3ceecjcc.fsf@STRIPCAPStelus.net>
"Marc Battyani" <·············@fractalconcept.com> writes:
> What I find annoying with 1 is when you don't have any content you have to
> write ((::img :src ...))

But remember that if you are "programming to the metal" this is not an issue.

A higher level syntax layer could make things more usable.

At the lower level, concentrate on correctness and clean separation, since
higher layers will need to process the lower one.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
········@STRIPCAPStelus.net                    The Rhythm has my soul.
From: Marc Battyani
Subject: Re: Looking for a better Text and HTML Lisp syntax
Date: 
Message-ID: <blcd01$e05@library2.airnews.net>
"Ray Blaak" <········@STRIPCAPStelus.net> wrote in message
> "Marc Battyani" <·············@fractalconcept.com> writes:
> > What I find annoying with 1 is when you don't have any content you have
to
> > write ((::img :src ...))
>
> But remember that if you are "programming to the metal" this is not an
issue.
>
> A higher level syntax layer could make things more usable.
>
> At the lower level, concentrate on correctness and clean separation, since
> higher layers will need to process the lower one.

Sure, but while I'm waiting for your user friendly syntax (and Thomas's emacs
mode...) I have to use the bare metal one. ;-)
And I want to simplifying the life of those who like you will want to
implement a higher level syntax.

Marc
From: Marc Battyani
Subject: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <blcdtj$f0r@library2.airnews.net>
Conclusion for the syntax choice between those alternatives:

> 1) An arg list enclosing the element name:
> ((table :padding 5 :backgound-color 10) ... content...)))
> The classical LHTML representation
>
> 2) An arg list after the element name:
> (table (:padding 5 :backgound-color 10) ...content...)
>
> 3) A separator between args and content
> (table :padding 5 :backgound-color 10 :content ...content...)
> (the separator can be made more simple like | with a read macro
> (Tim Bradshaw uses <table :padding... | ...content...>)
>
> 4) Switching from args to content when it's not a keyword anymore
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by Nick Levine)
>
> 5) Switching from args to content when it's not a known attribute keyword
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by me)

Considering that
    Syntax 2 is the most popular
    Nobody is against it
    cl-typesetting is already using it.

I keep it!

Thanks too all for your opinions.

Marc
Still looking for a better name for cl-typesetting...
From: Thomas F. Burdick
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <xcvvfr9g110.fsf@famine.OCF.Berkeley.EDU>
"Marc Battyani" <·············@fractalconcept.com> writes:

> Still looking for a better name for cl-typesetting...

How about Cold Lead.  You know, in contrast to the hot lead you use
the old-fashioned way.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Pascal Costanza
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <blcenq$2kr$1@newsreader2.netcologne.de>
Marc Battyani wrote:

> Still looking for a better name for cl-typesetting...

What about "colts"?


Pascal
From: Marc Battyani
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <blcl4b$d65@library2.airnews.net>
"Pascal Costanza" <········@web.de> wrote
> Marc Battyani wrote:
>
> > Still looking for a better name for cl-typesetting...
>
> What about "colts"?

Sure I hope it will be a killer application ;-)
A little bit agressive maybe...

Marc
From: james anderson
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <3F7A8256.2B2A289D@setf.de>
On Wednesday, Oct 1, 2003, at 01:24 Europe/Berlin, Marc Battyani wrote:

> From: "james anderson" <··············@setf.de>
> Sent: Tuesday, September 30, 2003 11:05 PM
>
> Hmm... Step by step I will finish to see what you mean ;-)
> As I told you I already agree with you for data representation but I 
> still
> don't see how you apply this to mixed code/data.
>
> As a picture is supposed to be better that N words (especially in a non
> native language), can you rewrite the following code snipset so that I 
> can
> see a clearer picture...
>
> (compile-text ()
> (table (:col-widths '(58 58) :border 0 :padding 0)
>             (loop for info in (otfr::source obj) do
>            (row ()
>          (if info
>              (progn
>         (cell ()(paragraph (:h-align :centered :font "Helvetica" 
> :font-size
> *s-cell-liste*)
>              (put-string (otfr::description info))))
>         (cell ()(paragraph (:h-align :centered :font "Helvetica" 
> :font-size
> *s-cell-liste*)
>              (put-string (otfr::address info)))))
>              (progn
>         (cell ()(paragraph (:h-align :centered :font "Helvetica" 
> :font-size
> *s-cell-liste*) "----"))
>         (cell ()(paragraph (:h-align :centered :font "Helvetica" 
> :font-size
> *s-cell-liste*) "----"))))))))

ok. in the form of my previous message, it would be something like

(render (as)
   ((form:pdf "table" pdf:col-widths '(58 58) pdf:border 0 pdf:padding 0)
    (loop for info in (otfr::source obj)
          do ((form:pdf "row")
              (cond (info
                     ((form:pdf "cell")
                      ((form:pdf "paragraph" (pdf:h-align . :centered) :font "Helvetica"
                                 :font-size *s-cell-liste*)
                       (put-string (otfr::description info))))
                     ((form:pdf "cell")
                      ((form:pdf "paragraph" :h-align :centered :font "Helvetica"
                                 :font-size *s-cell-liste*)
                       (put-string (otfr::address info)))))
                    (t
                     ((form:pdf "cell")
                      ((form:pdf "paragraph" :h-align :centered :font "Helvetica"
                                 :font-size *s-cell-liste*)
                       "----"))
                     ((form:pdf "cell")
                      ((form:pdf "paragraph" :h-align :centered :font "Helvetica"
                                 :font-size *s-cell-liste*)
                       "----"))))))))

it's a lot like lisp as one has come to know and love it, just with 
inline lambda expressions. note that this is not specifically form 1, 
but rather the more general variation.  where one handles the initial 
attribute as the identifier identifier one has form 1. simplifying to 
permit name-only annotations and adopting an alist form for the 
annotations gives something like

(render (as)
   ((pdf:table (pdf:col-widths . '(58 58)) (pdf:border . 0) (pdf:padding . 0))
    (loop for info in (otfr::source obj)
          do (pdf:row
              (cond (info
                     (pdf:cell
                      ((pdf:paragraph (pdf:h-align . :centered) (:font . "Helvetica")
                                      (:font-size . *s-cell-liste*))
                       (put-string (otfr::description info))))
                     (pdf:cell
                      (((form:pdf . "paragraph") (:h-align . :centered) (:font . "Helvetica")
                        (:font-size . *s-cell-liste*))
                       (put-string (otfr::address info)))))
                    (t
                     (pdf:cell
                      ((pdf:paragraph (:h-align . :centered) (:font . "Helvetica")
                                      (:font-size . *s-cell-liste*))
                       "----"))
                     (pdf:cell
                      ((pdf:paragraph (:h-align . :centered) (:font . "Helvetica")
                                      (:font-size . *s-cell-liste*))
                       "----"))))))))

the alist for attributes rather than a plist or a list of lists has the 
advantage that the expressions have the general form

annotated-expression ::= ( annotation . content* )
content ::= annotated-expression | expression
annotation ::= attribute*
attribute ::= expression | ( expression . expression ) |
expression ::= value-variable | ( function-variable . value-variable* )

which makes it possible to distinguish between the pair attribute form, 
to denote a name X character-data pair, and, in general, an expression 
attribute form, to denote a lisp expression which evaluates to a list 
of attributes. in the special case of the first attribute, a value 
variable denotes the ("generic-identifier" . name) pair.

this abstract form requires a code walker. in order to avoid that, and 
because there are, in fact, some static distinctions to be made in 
practice. i tend to use the form at the end of one of my earlier 
messages,

   (<projection-operator> <annotation> <content>)

in which the annotation operator appears in each form and there is no 
"render", or "compile-text" container. as in [nb. the "form" operator 
is chosen arbitrarily]

   (form (pdf:table (pdf:col-widths . '(58 58)) (pdf:border . 0) (pdf:padding . 0))
         (loop for info in (otfr::source obj)
               do (form pdf:row
                        (cond (info
                               (form pdf:cell
                                     (form (pdf:paragraph (pdf:h-align . :centered) (:font . "Helvetica")
                                                          (:font-size . *s-cell-liste*))
                                           (put-string (otfr::description info))))
                               (form pdf:cell
                                     (form (pdf:paragraph (:h-align . :centered) (:font . "Helvetica")
                                                          (:font-size . *s-cell-liste*))
                                           (put-string (otfr::address info)))))
                              (t
                               (form pdf:cell
                                     (form (pdf:paragraph (:h-align . :centered) (:font . "Helvetica")
                                                          (:font-size . *s-cell-liste*))
                                           "----"))
                               (form pdf:cell
                                     (form (pdf:paragraph (:h-align . :centered) (:font . "Helvetica")
                                                          (:font-size . *s-cell-liste*))
                                           "----")))))))

for a more extended example, look at the generate-page function in 
http://www.cl-xml.org/documentation/howto/generate.lisp , which encodes 
xhtml, css, and javascript. i have not (yet) used the approach to 
target different encodings from the same abstract expression, but it 
does work to use the same abstract function to both serialize and 
construct data instances. once the abstract syntax for cl-typsetting 
stop being a moving target, it will be something to consider.

think of it as describing abstractly the various paths which could be 
taken through the page description - only once the process knows where 
the data is coming from and where it is going to does it actually 
generate and bind the methods which produce the results.

...
From: Kenny Tilton
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <Olqeb.8354$q71.7305@twister.nyc.rr.com>
Pascal Costanza wrote:
> Marc Battyani wrote:
> 
>> Still looking for a better name for cl-typesetting...
> 
> 
> What about "colts"?

Do we have any parameters on this name-search? ie, should it promote CL? 
Should there be no reference at all to TeX? Can you just go crazy and 
pick a name like Bartleby or Typist? TNT? "TNT is not TeX?

I thought of one that mentions CL, but I doubt anyone would get it:

    CLectric, after the old IBM Selectric typewriters. Or maybe spelled 
C[subscript capital L]Ectric.

What about deriving something from "lexical"? Lexicon? CLex? Hard to 
pronounce that one.

kenny
From: Peter Seibel
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <m3ekxx7iq1.fsf@javamonkey.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> Pascal Costanza wrote:
> > Marc Battyani wrote:
> >
> >> Still looking for a better name for cl-typesetting...
> > What about "colts"?
> 
> Do we have any parameters on this name-search? ie, should it promote
> CL? Should there be no reference at all to TeX? Can you just go
> crazy and pick a name like Bartleby or Typist? TNT? "TNT is not TeX?

If it were me (since its open for discussion) I'd keep allusions to
Common Lisp out of the name. If this thing really beats TeX at--if not
its own game--some game that folks care about, this could be a good
viral app to show folks that you really can ues Lisp for stuff. But
the virus only works if it spreads and its spread will be slowed if it
triggers the anti-Lisp antibodies. In other words, I prefer the
wait-until-they-ask-what-its-written-in strategy.

Anyway, I sort of like the name Bartleby though I suspect that's not
quite right; a scrivener seems more about just copying the contents,
not making it look beautiful.

How about "Scriptorium", the room where medieval monks made those
beautiful illustrated manuscripts.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Kenny Tilton
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <jJzeb.11728$q71.10991@twister.nyc.rr.com>
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
>>CL? Should there be no reference at all to TeX? Can you just go
>>crazy and pick a name like Bartleby or Typist? TNT? "TNT is not TeX?
> 
> 
> Anyway, I sort of like the name Bartleby though I suspect that's not
> quite right; a scrivener seems more about just copying the contents,
> not making it look beautiful.

While looking for Computer Modern fonts, I came across a bit by Alan 
Hoenig saying he had a copy of Melville's <gasp!> novel Typee <gasp!!> 
set in Modern. A Message From God(tm)?

How about TypeB, for "Battyani"?

And there used to be a lot of talk about Type A & B personalities.

Type B is:

   relaxed (easy to use)
   uncompetitive (not fighting the user (or TeX))
   inclined to self-analysis (can you say "reflection"?)

kenny

ps. speaking of studlyCaps, TeX seems to have worked out pretty well. :)
From: Ivan Toshkov
Subject: Re: Conclusion (was Re: Looking for a better Text and HTML Lisp syntax)
Date: 
Message-ID: <bleimf$bj05l$1@ID-207269.news.uni-berlin.de>
Kenny Tilton wrote:
> 
> 
> Peter Seibel wrote:
> 
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>> CL? Should there be no reference at all to TeX? Can you just go
>>> crazy and pick a name like Bartleby or Typist? TNT? "TNT is not TeX?
>>
>>
>>
>> Anyway, I sort of like the name Bartleby though I suspect that's not
>> quite right; a scrivener seems more about just copying the contents,
>> not making it look beautiful.
> 
> 
> While looking for Computer Modern fonts, I came across a bit by Alan 
> Hoenig saying he had a copy of Melville's <gasp!> novel Typee <gasp!!> 
> set in Modern. A Message From God(tm)?
> 
> How about TypeB, for "Battyani"?

Sounds a bit like Plan "B" :)  Which may be a good name, though it 
doesn't imply anything about typesetting.

> 
> And there used to be a lot of talk about Type A & B personalities.
> 
> Type B is:
> 
>   relaxed (easy to use)
>   uncompetitive (not fighting the user (or TeX))
>   inclined to self-analysis (can you say "reflection"?)
> 
> kenny
> 
> ps. speaking of studlyCaps, TeX seems to have worked out pretty well. :)
> 
From: Thomas F. Burdick
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <xcvy8w6f7nr.fsf@famine.OCF.Berkeley.EDU>
"Marc Battyani" <·············@fractalconcept.com> writes:

> 2) An arg list after the element name:
> (table (:padding 5 :backgound-color 10) ...content...)

For cl-typesetting, I'd think that this would be far better than the
other choices.  The point of the sexp structure is to make the
document easily to manipulate with Lisp code, right?  Options 3, 4,
and 5 would require some amount of parsing in any code that consumes
them, where as #2 works perfectly with destructuring lambda-lists:

  (defmacro my-tag ((&key foo bar baz) &rest body) ...)

  (case (first form)
    (tag1 (destructuring-bind ((&key foo bar baz) &rest body)
                              (rest form)
            ...))
    ...)

As for a clever read macro syntax like:

> (Tim Bradshaw uses <table :padding... | ...content...>)

You could have that expand into any of the options you listed:

  <table :padding 5 :background-color 10 | ...content...>
  => (table (:padding 5 :background-color 10) ...content...)

> My present preference would be #3 or #4.

Those are probably nicer to type in, but at the cost of making
transformations more difficult to write.  I'd vote for #2, plus a read
macro with convenient syntax.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: ·············@comcast.net
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <wubq2n47.fsf@comcast.net>
"Marc Battyani" <·············@fractalconcept.com> writes:

> The problem when representing text and HTML in sexpr is how to differenciate
> attributes from content for the text elements.
>
> There are 5 ways that seem natural:
>
> 1) An arg list enclosing the element name:
> ((table :padding 5 :backgound-color 10) ... content...)))
> The classical LHTML representation

Pretty straightforward.

> 2) An arg list after the element name:
> (table (:padding 5 :backgound-color 10) ...content...)

This is slightly better.  Why?  You can EVAL or MACROEXPAND it!
bwahahahaha!

> 3) A separator between args and content
> (table :padding 5 :backgound-color 10 :content ...content...)
> (the separator can be made more simple like | with a read macro
> (Tim Bradshaw uses <table :padding... | ...content...>)

Pain in the ass if you want to insert extra content or append
some attributes.  You'd have to parse the list to find the separator.

> 4) Switching from args to content when it's not a keyword anymore
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by Nick Levine)

Same as above.  With an additional problem that you cannot have
meta-variables (consider that you might want to parameterize the
parameter list).

> 5) Switching from args to content when it's not a known attribute keyword
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by me)

Even worse.  Now not only can you not parameterize the parameter list,
you can't parameterize the tag!  (Consider parameterizing over <ol> vs. <ul>)
From: Iain Little
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <87r81yw9oa.fsf@yahoo.com>
"Marc Battyani" <·············@fractalconcept.com> writes:

> The problem when representing text and HTML in sexpr is how to differenciate
> attributes from content for the text elements.
>
> There are 5 ways that seem natural:
>
> 1) An arg list enclosing the element name:
> ((table :padding 5 :backgound-color 10) ... content...)))
> The classical LHTML representation
>
> 2) An arg list after the element name:
> (table (:padding 5 :backgound-color 10) ...content...)
>
> 3) A separator between args and content
> (table :padding 5 :backgound-color 10 :content ...content...)
> (the separator can be made more simple like | with a read macro
> (Tim Bradshaw uses <table :padding... | ...content...>)
>
> 4) Switching from args to content when it's not a keyword anymore
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by Nick Levine)
>
> 5) Switching from args to content when it's not a known attribute keyword
> (table :padding 5 :backgound-color 10 non-keyword-content...)
> (Suggested by me)

FWIW, I prefer #2.  There is however the minor problem that (by
default) emacs will indent things like:

(table (:padding 5
                 :background-colour 10)
       ...content...)

rather than,

(table (:padding 5
        :background-colour 10)
       ...content...)

or

(table (:padding 5
        :background-colour 10)
  ...content...)


Iain
From: Marc Battyani
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <blc9nk$670@library2.airnews.net>
"Iain Little" <······@yahoo.com> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > The problem when representing text and HTML in sexpr is how to
differenciate
> > attributes from content for the text elements.
> >
> > There are 5 ways that seem natural:
...
> > 2) An arg list after the element name:
> > (table (:padding 5 :backgound-color 10) ...content...)
...

> FWIW, I prefer #2.

OK, another vote for 2.

> There is however the minor problem that (by
> default) emacs will indent things like:
> (table (:padding 5
>                  :background-colour 10)
>        ...content...)
>
> rather than,
>
> (table (:padding 5
>         :background-colour 10)
>        ...content...)
>
> or
>
> (table (:padding 5
>         :background-colour 10)
>   ...content...)

Maybe an emacs lisp expert can help us here...

Marc
From: Janis Dzerins
Subject: Re: Looking for a beter Text and HTML Lisp syntax
Date: 
Message-ID: <twk4qyr1x46.fsf@gulbis.latnet.lv>
"Marc Battyani" <·············@fractalconcept.com> writes:

> "Iain Little" <······@yahoo.com> wrote
> > "Marc Battyani" <·············@fractalconcept.com> writes:
> >
> > > The problem when representing text and HTML in sexpr is how to
> differenciate
> > > attributes from content for the text elements.
> > >
> > > There are 5 ways that seem natural:
> ...
> > > 2) An arg list after the element name:
> > > (table (:padding 5 :backgound-color 10) ...content...)
> ...
> 
> > FWIW, I prefer #2.
> 
> OK, another vote for 2.

If we're voting, I vote for #4.  There's no need to enclose the
attributes.

> > There is however the minor problem that (by
> > default) emacs will indent things like:
> > (table (:padding 5
> >                  :background-colour 10)
> >        ...content...)
> >
> > rather than,
> >
> > (table (:padding 5
> >         :background-colour 10)
> >        ...content...)
> >
> > or
> >
> > (table (:padding 5
> >         :background-colour 10)
> >   ...content...)

#4 will indent like this:

(table :padding 5 :background-colour 10
       ...content...)

or this:

(table :padding 5
       :background-colour 10
       ...content...)

To minimize the horizontal space usage, one can do it this way (until
some better emacs support):

(table
 :padding 5 :background-colour 10
 ...content...)

-- 
Janis Dzerins

  Common Lisp -- you get more than what you see.