3 ms·

> A little more detail here: it has a lot more namespaces than that. And I don't think the function/value split is even the most important namespacing it does

by kbp 8y ago

> A little more detail here: it has a lot more namespaces than that. And I don't think the function/value split is even the most important namespacing it does with regards to macro hygiene ("functions are less likely to be shadowed" always struck me as a kind of weak argument). Symbols being namespaced under packages is a much more robust solution: CL-USER> (defmacro m (x) `(car ,x)) M CL-USER> (defpackage :p) #<PACKAGE "P"> CL-USER> (in-package :p) #<COMMON-LISP:PACKAGE "P"> P> (cl:macroexpand '(cl-user::m x)) (COMMON-LISP:CAR X) CL:CAR isn't accessible in P, so (car x) by itself would signal UNDEFINED-FUNCTION, but the macro works correctly. Defining a P::CAR function wouldn't change anything. That isn't just for functions, either, eg if you do: (defmacro awhen (pred &body body) `(let ((it ,pred)) (when it ,@body))) (where you want to leak IT), and then import AWHEN but not IT, you'll get an error that YOUR-PACKAGE::IT isn't bound to anything when you try to use it; it doesn't matter that AWHEN-PACKAGE:IT is bound. I don't disagree with anything you said, I just think it made CL macros look flimsier than they are.

kazinator 8y ago
The problem is that it is quite common for cl:car to be accessible in packages, because of the practice of use-ing the cl package everywhere. Even if I'm in my own package, I can't do this: (flet ((car (x) ...))) (m arg)) because in order to have a hassle-free Lisp coding experience in my package, I brought in all the public symbols from the common-lisp package. So my flet is in fact shadowing cl:car. Even if I just import the specific common-lisp things I need, and car is not one of them, that could change. Today, that car above is mypkg:car. Tomorrow, someone edits the defpackage to import car (because they needed it in a function they added), and now when that file is re-read, car is cl:car. Packages have a theoretical solution to the hygiene problem that will not be air-tight in practice due to use/importation. Another problem is that programmers aren't going to define a large number of packages to protects parts of their program from each other. A common practice is just to make one package for an entire project. You need fine-grained package use to achieve near perfect hygiene. Ideally, each module that provides macros should have its own package, and use only symbols from that package in the macro expansion. If module A uses a macro from package B, and that macro generates a local function F, that will be B::F, not interfering with the A::F function. If the modules are in the same master project package, the clash is not averted, obviously.

by kbp 8y ago

kazinator 8y ago

The problem is that it is quite common for cl:car to be accessible in packages, because of the practice of use-ing the cl package everywhere. Even if I'm in my own package, I can't do this: (flet ((car (x) ...))) (m arg)) because in order to have a hassle-free Lisp coding experience in my package, I brought in all the public symbols from the common-lisp package. So my flet is in fact shadowing cl:car. Even if I just import the specific common-lisp things I need, and car is not one of them, that could change. Today, that car above is mypkg:car. Tomorrow, someone edits the defpackage to import car (because they needed it in a function they added), and now when that file is re-read, car is cl:car. Packages have a theoretical solution to the hygiene problem that will not be air-tight in practice due to use/importation. Another problem is that programmers aren't going to define a large number of packages to protects parts of their program from each other. A common practice is just to make one package for an entire project. You need fine-grained package use to achieve near perfect hygiene. Ideally, each module that provides macros should have its own package, and use only symbols from that package in the macro expansion. If module A uses a macro from package B, and that macro generates a local function F, that will be B::F, not interfering with the A::F function. If the modules are in the same master project package, the clash is not averted, obviously.