[racket-dev] Removing Xexpr preference from Web Server

Eli Barzilay wrote at 11/30/2010 06:36 AM:
> The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like "<quote>nbsp</quote>".

I make errors of not getting my quotes, backquotes, and commas in the 
right place sometimes, but those errors tend to be discovered quickly.

BTW, in SHTML, my old SXML derivative for HTML, one does "(& nbsp)" 
instead of xexpr's just "nbsp" for an entity reference.  Perhaps there 
is a little less risk of confusion.

I think there would be even less risk of confusion if DrRacket syntax 
coloring assumed that the quote and backquote characters always 
introduced a normal Scheme quote/quasiquote context, and colored the 
literal parts green.

> A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad "<span>stuff</span>" hack.
>   

I ran into this potential pitfall when I was doing PLT servlets with 
xexprs.  It's not so much an issue in SXML, since (for better or worse) 
SXML permits unnecessary paren nesting, so you never have to splice.

Other solutions/workarounds:

* Just be careful, and test.

* When I was doing PLT servlets, I just had a naming convention for 
procs that produced xexprs, so "foo-bar-xexpr-elem" would get unquote 
and "blort-baz-xexpr-content" would get unquote-splicing.

* Ideally, I'd want static type checking of my HTML/SXML forms.  This 
might have been some of the attraction of Haskell to Oleg.

* My template language doesn't use unquote or unquote-splicing, and 
instead uses constructs that I think are less error-prone.

-- 
http://www.neilvandyke.org/