[racket] Test to disambiguate x-expression attributes vs. content?

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.acct at 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.mccarthy at 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.acct at 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 <jay at 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 <jay at 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