Thanks for posting this! While we’ve known about this for years in the Dylan community, we forget that this stuff is new to a lot of people still. :)

I really enjoy some of the things that we can do with the Dylan macro system. Some wonderful examples of this can be found in our binary-data system:

define abstract binary-data <icmp-echo-message> (<icmp-frame>)
  field code :: <unsigned-byte> = 0;
  field checksum :: <2byte-big-endian-unsigned-integer> = 0;
  field identifier :: <2byte-big-endian-unsigned-integer> = 42;
  field sequence-number :: <2byte-big-endian-unsigned-integer> = 0;
  field icmp-data :: <raw-frame>;
end;

The extensions that this paper brings would be very useful. We’ve heard / been told that much of the machinery for this is already available within the compiler, but we don’t currently know how to make this visible on the user side of the compilation process. (The people who wrote this paper and our macro expander have long since moved on.)

That said, the facilities described by this paper are widely used in the implementation of the Open Dylan compiler and some of the compiler libraries (like our C-FFI).

I also recently wrote and extended some similar code to support our Objective C / Dylan bridge that will be in our next release. This allows us to have code like:

define objc-selector @alloc
  parameter target :: <objc/class>;
  result objc-instance :: <objc/instance>;
  selector: "alloc";
end;

All of that said … macros can be quite difficult to work with. They often have relatively poor error handling, can make editor integration more difficult, make things like auto-indenting more difficult.