[racket] comments requested from users of SXML and PLT xexprs

Yesterday, Neil Van Dyke wrote:
> Comments requested from anyone who has used SXML or xexprs...

(I didn't use either of these to a point that I could comment, but I
played with a bunch of similar things, mostly trying to get away from
the problems of the latter.)


> The extraneous list nesting in SXML has two purposes I see: (1)
> Resilient to programming sloppiness, so that you can, say, just
> "unquote" to a procedure application, and that procedure application
> can either return one element or multiple elements and the SXML is
> still valid;

IMO it's more than that.  Too often I ran into cases where dealing
with lists ended up in changing function types from returning an item
to returning a list, and that requires changing all uses of the
function (mostly from being inside an `unquote' to `unquote-splicing',
and even more painful in uses of the function in unquoted contexts).
For example, the old plt website code had links defined as a mapping
that holds the link text and the url -- but at somepoint it changed
because one of the links needed to be

  '("R" (sup "5") "RS")

and that complicated all other links too.  This example annoyed me
enough that I (at least I think that I did that change) eventually
changed it to

  '(span "R" (sup "5") "RS")

which throws back at the html spec of `span' as a splicing device.

In any case, I think that these kind of problems make the "permissive"
approach much more appealing.


> (2) Possible efficiency gains in some cases, since you
> can do things like "`(foo ,(proc) bar)" to effectively splice rather
> than "`(foo ,@(proc) bar)".  Since extraneous list nesting is not
> ambiguous in SXML, the nesting is somewhat like whitespace in a text
> document.

This is a nice by-product -- for example, it's nice to do things like

  (map (lambda (x) (list "[" x "]")) l)

instead of worrying about flattening each of the results into a string
and then combining the whole list into a single string (or flattening
it and splicing the resulting list into the surrounding context).  But
I've never viewed the efficiency point as more than a nice occasional
side bonus.


> Instead, to accomplish the efficient splicing and convenience, I
> introduced an explicit "*splice*" form in certain contexts.

I got to a similar solution at some point, but it didn't feel like the
right thing since it essentially creates an xexpr variant that
eventually needs an explicit conversion to the real xexprs.  Sounds
like you tried to avoid the new type thing with doing this only in
certain contexts, which is also dangerous since the conversions are
now spread in several places.  (It's especially bad when the two types
are so close too...)


> [...] However, I have come up with what I think are some
> improvements to SXML, such as [...] attribute value composition
> [...]

Is this aimed at the problem of combining `style' attributes?  If so,
can you say more on what you did for that?  (I've considered some ways
to do that, but never got to something that was good enough in solving
the problem in an intuitive way.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!