[qwertyuiop924]

The macro abstraction is that the AST is exposed as a series of lists, which is what macros process. Instead, syntax-case exposes 'syntax' objects, which are entirely distinct from any other datatype, and kind of complicated.

This isn't a horrific sin (new macro abstractions pop up like rabbits, although they rarely change something so fundamental, at least in Lisp mavro systems), but if you're going to replace an abstraction everybody knows and understands with a more complex one, you better have a good reason, and I don't think the benefits outweigh the costs.

[ufo]

I thought that the syntax objects resulted in better error messages, due to keeping track of source code position, lexical bindings for variables and so on. Isn't that worth the complexity?

[junke]

Talking about CL, all the things that are done with syntax objects are done with environments (`&environment`). Type declarations, lexical bindings, etc. You can even process the same code in two different environments if this is useful. Other bindings from symbols to values can be stored in the symbols themselves: things like original code source (as a string; I recovered deleted code thanks to that in the past), original location, custom properties, etc.

[qwertyuiop924]

So like the sc macro system, but more featureful. In theory, the sc macros could record this sort of data (maybe), but I don't think they record as much as syntax objects.

[qwertyuiop924]

I'm not sure it is. As junke pointed out below, however, some of this can be achieved through other, less intrusive methods, such as environments, which are actually used by the sc macro mechanism. You don't get it all, but it's usually enough to know that the error was triggered in the expansion of a macro on line <n>. That's dramatically better than most C error messages already. :-D