Hacker News Reader

Comment by oconnor663 | Hacker News Reader

> he simply asked if Python could gracefully manipulate Python code as data

Have there been any big LISP macro code injection vulnerabilities in the wild?

As the other comment says, that doesn't really make sense. However, I have had to debug a codebase where lisps unhygienic macros led to extremely weird errors. The second time that happened in a big project I decided that schemes hygienic macros are superior. The extra cruft writing them is worth it. I have literally spent weeks debugging weird macro errors introduced years after the macro was first written.

You're not wrong: simple macros can be written poorly. Macros which don't properly use GENSYM should be rejected in review. Also, it's entirely possible to write a hygienic macro implementation with DEFMACRO: nothing stops a team from doing that (or using one off-the-shelf).

But sometimes you do need the full power of DEFMACRO, and it's not possible to write DEFMACRO with DEFINE-SYNTAX. So one tool enables you to do anything you need, and the other only some of what you need. I know what I prefer.

Let's agree to agree then :) I much prefer Racket's macros. Their version of syntax-case is a bit simplified compared to the one shipped with other schemes like guile and chez.

If you want to see where you can go by (ab)using racket macros, watch this: https://www.youtube.com/watch?v=WQGh_NemRy4

What do you mean with "macro code injection vulnerabilities"? Macros are expanded before the code is compiled; by the time someone is running the program there are no macros. Well, technically, someone could call `EVAL` in a production app, but that's strongly discouraged.

Reply on news.ycombinator.com