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?
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))
(with-current-project "foo" (whatever))But I still think Lisps impose an overhead on reading code, and that overhead is highly unfriendly to a moderate GNU user who just wants to start poking around to see what happens under the hood and customize a few things. If a goal of the GNU project is to empower users to extend their own software, that burden should be avoided.
The problems I said with macros not being visually distinct reflect what I've personally found when trying to grok others' code. Many special forms are easily picked out, but one must be sure that all have been picked out in order to separate the control flow from the expression trees.
Interesting thought, but where is your evidence? From personal experience, I've spent the most time reading and writing Perl and Emacs Lisp. As a result, I find both of them easier to read than Python, which is a language designed to be readable. The reality is that all computer programs are hard to read if you don't practice reading them. (As an aside, I would estimate that about 20% of programmers "in industry" are able to fluently read code. The rest just write the same thing over and over again and are confused when they are asked to fix bugs in code they didn't write.)
The problem with this argument is that a sexp-based configuration language is already adopted by a community of programmers: Emacs Lisp. Emacs itself ships with over a million lines of Lisp code, and there are thousands of extensions available from around the Internet.
The problems you worry about with respect to macros have simply not happened; most people name macros the same way (starting with def or define-), and most macros are written "cleanly" in such a way as to not surprise the programmer. (I'll be honest: I can't think of one time I've ever hit a but in a Lisp program caused by a strange macro.)
Emacs Lisp shows that if you give someone a turing-complete programming language on top of a powerful piece of software with a clean and well-documented API, programmers will ignore the warts and enhance the software in ways you never thought possible.
Guile is not a perfect programming langauge, and I would never use it by choice. But if I started using some piece of software that used it for configuration, I know I would love it because it would stay out of the way and let me make things. Once you are making cool things, you don't care about the syntax or programming language features at your disposal: you just make it work.
Some other examples of this include JavaScript for Firefox extensions and Vimscript for Vpim extensions. JavaScript is very ... minimal compared to other languages like Perl, Python, Ruby, Haskell, and so on, but people write great browser extensions anyway. Vimscript is the weirdest thing I've ever seen but Vim is able to do a lot of cool stuff despite this.
The only thing a successful extension language needs is something worth extending. If you use Guile as your extension language, you can concentrate doing that instead of writing your own programming langauge toolchain.