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/
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
