I wasn't referencing the docs. I'm just talking abstractly. The point is that you have to consider the attribute list as a totally different kind of thing. The thing you cite can be directly turned into a match pattern, though:
(match xe [(? string? s) ....] [(list (? symbol? tag) (list (list (? symbol? k) (? string? v)) ...) xe ...) ....] [(cons (? symbol? tag) (list xe ...)) ...] etc On Mon, Jun 10, 2013 at 1:20 PM, Matthew Butterick <mb.list.a...@gmail.com> wrote: > Aha, the xexpr-drop-empty-attributes is probably best, since it will produce > consistent forms. Thanks. > > BTW what part of the docs are you citing for (list* Symbol (option > AttributeList) XexprList)? The only definition of X-expressions I'm aware of > is here. > > > On Mon, Jun 10, 2013 at 11:58 AM, Jay McCarthy <jay.mccar...@gmail.com> > wrote: >> >> The type of Xexpr is... >> | AtomicContent >> | (list* Symbol (option AttributeList) XexprList) >> >> It sounds like you have one function F that you would like to give the >> type "Xexpr -> Value", but you are having a problem when you apply it >> to the AttributeList. You should have such a problem, because an >> AttributeList is not an Xexpr, so your types are wrong. >> >> In other words, if you want to recursively process an Xexpr, then you >> need two functions, one for attribute lists and one for xexpr lists. >> >> Finally, I find it convenient when automatically processing Xexprs to >> ensure that xexpr-drop-empty-attributes is #f so that there is always >> an attribute list and do: >> >> (match xe >> [(list* tag attrs content) ....]) >> >> >> >> On Mon, Jun 10, 2013 at 12:40 PM, Matthew Butterick >> <mb.list.a...@gmail.com> wrote: >> > Consider an x-expression that represents an XML tag, so it has the >> > general >> > form >> > >> > '(tag ((attr-name "attr-value") ... ) content ...) >> > >> > The attributes or content might be omitted, of course. >> > >> > When I recursively process these expressions, I start by decomposing the >> > x-expression into components: >> > >> > tag >> > ((attr-name "attr-value") ... ) >> > (content ...) >> > >> > The problem that surfaces in a recursive-processing context is that the >> > list >> > of content might have the same form as an attribute expression, e.g., >> > >> > ((field-1 "value-1") (field-2 "value-2")) >> > ((p "some text") (p "some more text")) >> > >> > Is there a test I could use to reliably disambiguate between these two >> > cases, short of creating a new struct for x-expressions? Seems like I'm >> > overlooking some middle ground. >> > >> > >> > >> > ____________________ >> > Racket Users list: >> > http://lists.racket-lang.org/users >> > >> >> >> >> -- >> Jay McCarthy <j...@cs.byu.edu> >> Assistant Professor / Brigham Young University >> http://faculty.cs.byu.edu/~jay >> >> "The glory of God is Intelligence" - D&C 93 > > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 ____________________ Racket Users list: http://lists.racket-lang.org/users
