<div dir="ltr">Aha, the xexpr-drop-empty-attributes is probably best, since it will produce consistent forms. Thanks.<div><div><br></div><div style>BTW what part of the docs are you citing for <span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><i>(list* Symbol (option AttributeList) XexprList)</i></span>? The only definition of X-expressions I'm aware of is <a href="http://docs.racket-lang.org/xml/index.html?q=x-expression#%28def._%28%28lib._xml%2Fprivate%2Fxexpr-core..rkt%29._xexpr~3f%29%29">here</a>.</div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 11:58 AM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The type of Xexpr is...<br> | AtomicContent<br> | (list* Symbol (option AttributeList) XexprList)<br> <br> It sounds like you have one function F that you would like to give the<br> type "Xexpr -> Value", but you are having a problem when you apply it<br> to the AttributeList. You should have such a problem, because an<br> AttributeList is not an Xexpr, so your types are wrong.<br> <br> In other words, if you want to recursively process an Xexpr, then you<br> need two functions, one for attribute lists and one for xexpr lists.<br> <br> Finally, I find it convenient when automatically processing Xexprs to<br> ensure that xexpr-drop-empty-attributes is #f so that there is always<br> an attribute list and do:<br> <br> (match xe<br> [(list* tag attrs content) ....])<br> <div><div class="h5"><br> <br> <br> On Mon, Jun 10, 2013 at 12:40 PM, Matthew Butterick<br> <<a href="mailto:mb.list.acct@gmail.com">mb.list.acct@gmail.com</a>> wrote:<br> > Consider an x-expression that represents an XML tag, so it has the general<br> > form<br> ><br> > '(tag ((attr-name "attr-value") ... ) content ...)<br> ><br> > The attributes or content might be omitted, of course.<br> ><br> > When I recursively process these expressions, I start by decomposing the<br> > x-expression into components:<br> ><br> > tag<br> > ((attr-name "attr-value") ... )<br> > (content ...)<br> ><br> > The problem that surfaces in a recursive-processing context is that the list<br> > of content might have the same form as an attribute expression, e.g.,<br> ><br> > ((field-1 "value-1") (field-2 "value-2"))<br> > ((p "some text") (p "some more text"))<br> ><br> > Is there a test I could use to reliably disambiguate between these two<br> > cases, short of creating a new struct for x-expressions? Seems like I'm<br> > overlooking some middle ground.<br> ><br> ><br> ><br> </div></div>> ____________________<br> > Racket Users list:<br> > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> ><br> <span class="HOEnZb"><font color="#888888"><br> <br> <br> --<br> Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br> Assistant Professor / Brigham Young University<br> <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br> <br> "The glory of God is Intelligence" - D&C 93<br> </font></span></blockquote></div><br></div>