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

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