[Prev][Next][Index][Thread]

RE: Complicated macro expansion question

> Hi!  I'm working on a definer macro that'll do this kind
> transformation:
>
> [...]
>
> But d2c complains that definitions must appear at the top level (?!?)
> -- wrapping begin ... end around various pieces doesn't help.  Should
> these macros work as written?  Is there a better way to do these
> macros?

There is a small defect in the code as written:

  Serious warning at play:6:

  This main rule pattern of the macro constraints-symbol-helper starts with constraints-helper, which does not match the macro name.

  play:5:     ------------------
  play:6:   { constraints-helper(?parent:name, ?subclasses:*) } =>
  play:7:     ------------------

says FunDev. If you fix this, though, it seems to work fine. Certainly
there's no example of a non top-level definition in the generated code,
so I think there must be a bug in d2c (even if it's just that d2c
doesn't catch the above defect and a misleading error message is the
result downstream).

Bruce wrote:

> Also, regarding macros, Dylan definer macros must have the name of
> the macro as the first thing after the word "define" when you use
> them. [...]

Definer macros support adjectives between "define" and the defining
word: "define open abstract class ...", "define open generic ...",
and so on. Pretty much any name that isn't a defining word can be
used as an adjective. The pattern matcher matches any patterns that
appear between "define" and the definer name in the macro's main
rule against any names appearing in the input fragment between the
"define" and the definer name. It's pretty straightforward.

I'll concede that Doug's using this feature a little... creatively
in this case. ;)

-- Keith
Follow-Ups: References: