You may have been speaking abstractly but the point is that it is a mostly accurate summary of Xexpr and I use just this form in HtDP/2e to process X-expressions. -- Matthias
On Jun 10, 2013, at 3:27 PM, Jay McCarthy wrote: > 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 ____________________ Racket Users list: http://lists.racket-lang.org/users
