3 ms·

I can't think of one time I've ever hit a bu[g] in a Lisp program caused by a strange macro. What about macros that have the same name? In Emacs, the conventio

by gruseom 15y ago

I can't think of one time I've ever hit a bu[g] in a Lisp program caused by a strange macro. What about macros that have the same name? In Emacs, the convention is to name your functions foo-this and foo-that if your program is foo.el. But this does not seem to be true for macros. Is that because macros don't leap outside the compilation context of foo.el? (Edit: nope, I checked it and they do.) Or is it that people are sloppier about naming their macros? Edit: or is it rather that, if your foo.el defines a macro 'blah, and I write bar.el that says (require 'foo) and then defines its own macro 'blah, it's my macro that gets used to compile my code, so the one in foo.el can't do any harm to it?

jrockway 15y ago
The naming convention for macros is a little weird. My rule is: if the macro is user-visible (and not something to make your module easier to implement), it should start with define- or with-, and should include a uniquifier somewhere in the name. If you were writing an extension called foo, you might provide a macro called with-current-foo or define-foo-bar. If someone already has a macro with this name, then don't call it that. The reason for ignoring the normal package-function naming convention is that it's simply ugly to write code like: (eproject-with-current-project "foo" (whatever)) when you could write (with-current-project "foo" (whatever))
- gruseom 15y ago
  I get (and practice) the part about user-visible macros. But what about macros that are just to make my module easier to implement? I often write those to concisify (well, you did say "uniquifier") my code. There's a tension here: encoding the package name in the macro name can easily make the name so long that the whole thing is why-bother, but using a short name runs the risk of a collision. For example, paredit.el defines XCOND. Although I don't have an XCOND, that's just the sort of macro name I might have chosen.

by gruseom 15y ago

jrockway 15y ago

The naming convention for macros is a little weird. My rule is: if the macro is user-visible (and not something to make your module easier to implement), it should start with define- or with-, and should include a uniquifier somewhere in the name. If you were writing an extension called foo, you might provide a macro called with-current-foo or define-foo-bar. If someone already has a macro with this name, then don't call it that. The reason for ignoring the normal package-function naming convention is that it's simply ugly to write code like: (eproject-with-current-project "foo" (whatever)) when you could write (with-current-project "foo" (whatever))

gruseom 15y ago
I get (and practice) the part about user-visible macros. But what about macros that are just to make my module easier to implement? I often write those to concisify (well, you did say "uniquifier") my code. There's a tension here: encoding the package name in the macro name can easily make the name so long that the whole thing is why-bother, but using a short name runs the risk of a collision. For example, paredit.el defines XCOND. Although I don't have an XCOND, that's just the sort of macro name I might have chosen.