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

RE: More macro questions

Hi Nolan,

> [...]
>
> I've fixed quite a few of the broken macros ('fixed' isn't a great
> word for that; they at least compile now.) I'm trying to get a basic
> C-function-definer macro built so that the definitions for malloc and
> free will parse. Here is what I'm trying to match:
> 
> define C-function malloc
>   /* XXX - Need <C-size-t> and <C-raw-pointer> */
>   parameter size :: <C-size-t>;
>   result memory :: <C-raw-pointer>;
>   c-name: "malloc";
> end;
>
> And here is my broken definition of that macro:
> 
> define macro C-function-definer
>   { define C-function ?dname:name
>       { (parameter ?pname:name :: ?type:name) ... }
>       { (result ?rname:name :: ?type:name) ... }
>       { c-name ?cname:name }
>     end }
>     => { /* XXX - need expansion */ }
> end macro;
> 
> But, this doesn't work. Can anyone suggest how I can fix the above
> macro to match the above case? [...]

See below for a typical approach to this kind of macro (tested in 
Functional Developer).

A couple of points worth noting:

  o Brackets of any kind that appear within the outermost { } delimiting
    the pattern are matched literally, not interpreted as logical grouping
    constructs. So:

      { define C-function ?dname:name { (parameter ?pname:name) ... } end }

    will match input of the form:

      define C-function foo { (parameter bar) } end;

    where the brackets in the input are required.

  o The ellipsis ... is shorthand for a wildcard pattern match followed by 
    a recursive call to the current auxiliary rule. It should never appear
    in a main rule; if it does (and if the compiler doesn't complain, which
    it probably should) it'll most likely just be matched as a wildcard
    and substituted without any further rewriting.

    The main problem with ... for people coming to Dylan macros is that it 
    doesn't mean quite what it most often does elsewhere ("zero-or-
    more things like the pattern preceding the ...").

  o Despite the presence of wildcards and backtracking, complex Dylan 
    macro patterns tend to end up closer in style to yacc-like grammars 
    than to dense regular expressions. If you take this difference on 
    board and are comfortable with recursion, things should click quite 
    quickly.

Hope this helps,

-- Keith

define macro C-function-definer
  { define ?mods:* C-function ?:name ?clauses:* end }
    => { list(?"name", ?clauses) }
clauses:
  { }
    => { }
  { ?clause:*; ... }
    => { ?clause, ... }
clause:
  { ?pmods:* parameter ?pname:name :: ?ptype:expression }
    => { "parameter", ?"pname", ?"ptype" }
  { ?rmods:* result ?rname:name :: ?rtype:expression }
    => { "result", ?"rname", ?"rtype" }
  { #rest ?options:* }
    => { ?options }
end macro;
References: