To ask an abstract question: is there a particular reason that X-expressions are defined in Racket as a special kind of S-expression, rather than a struct or primitive datatype?
On Tue, Jun 11, 2013 at 6:46 AM, Matthias Felleisen <matth...@ccs.neu.edu>wrote: > > 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
