[Prev][Next][Index][Thread]
Re: Complicated macro expansion question
Bruce Hoult <bruce@hoult.org> wrote in message news:<bruce-F04E9C.19153822112001@news.paradise.net.nz>...
> In article <49f7a00.0111212153.7a6ea935@posting.google.com>,
> dauclair@hotmail.com (Douglas M. Auclair) wrote:
>
> > Hi! I'm working on a definer macro that'll do this kind
> > transformation:
> Ummm ... I really don't understand what you're trying to do here.
> Forget the macros for the moment: what code do you want it to expand to,
> and what does it all mean?
Sure ... I'm using the xml-parser to serialize out and serialize in
constraints for some CLP (constraint logic programming) I'm doing in
Dylan. The XML is something of the form:
<value name="age" type="integer">
<constraints>
<min>16</min>
<max>97</max>
<!-- ... -->
</constraints>
</value>
<value name="programming-language" type="string">
<constraints>
<allowed>
<elt>Dylan</elt> <!-- of course -->
<elt>Lisp</elt>
<elt>Smalltalk</elt>
</allowed>
<forbidden>
<elt>C</elt>
<elt>FORTRAN</elt>
</forbidden>
<!-- ... -->
</constraints>
</value>
The "problem" here is that the constraints all have different
tag-names, but are of the same <constraint> type and (generally) of
similar formats. That's what the *constraints* table is for, mapping
the XML tag-names to the Dylan types. <Unit>, <group>, etc are
<constraint> classes that provide the hooks to implement constraints
of those specialized classes (such as <min>, <max>, <allowed>, etc)
that the macros expand to.
>
> I don't see any definition above for <unit> or *constraints*.
True, I was using them as foo, bar, ... meta-names. Their definitions
were not important to the problems d2c is having with the macros.
Sincerely,
Doug Auclair
References: