In article <[EMAIL PROTECTED]>, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sat, 09 Dec 2006 21:55:19 +0000, Kirk Sluder wrote: > > Who says they do? All forms of abstraction have been criticized. Sometimes > the criticism is valid. Sometimes it warns against abuses of the > abstraction. Just because a feature is useful sometimes doesn't > necessarily mean the benefit outweighs the cost. The primary focus of the criticism in this discussion has been that macros are a bad from of abstraction compared to libraries, (and I'm admittedly extending that to objects, functions and classes.) > But at least you know that foolib is a module or package. You know what > from and import do, and that can't change. And you know that bar is an > object with a method also called bar, it is being called, and the > argument is a string "somefile". Those things can't change. Imagine a > hypothetical language where those two lines could mean *anything*. But as was pointed out earlier in the thread, those keywords can be overshadowed by custom functions in python as well. The only reason that we don't assume those two python lines could mean *anything* is because those mechanisms are not well advertised, and most people don't have a need to shadow "import." Of course, it is possible to abstract away all of the lisp in such a way that you have a completely new programming language. But is this really a problem? Perl5 and bash are abstractions of C. Python has been implemented on both C and java, and chunks of perl6 have been implemented on top of Haskell. Completely new programming languages and frameworks develop their own base of knowledge and expertise separate from the parent language. > My point isn't whether or not their claims are correct (a "couple" of > macros? really?) but that things like this feed the perception that Lisp > is close to that hypothetical language where anything could be anything. > If anything could be anything, do you really know what (+ 1 2) means > without reading every line of code? How do you know that operator has not been shadowed or overloaded in python? In most cases what you have to do is trust both the underlying implementation, and the author(s) of the libraries you use. Both python and lisp share mechanisms to protect namespaces is part of the answer. So one way to protect myself is to run my code in it's own namespace, and require explicit addressing of imported functions and constructs. In this way I can be pretty certain that (+ 1 2) uses the lisp primitives, and has not been shadowed, while (SOMEPACKAGE:+ 1 2) should be treated with suspicion. The process of writing lisp often involves access to the REPL, so I can have lisp expand the definition of any expression: CL-USER> (macroexpand '(+ 1 2)) (+ 1 2) NIL CL-USER> (macroexpand '(loop for i upto 100 collect i)) (BLOCK NIL ...<expansion snipped for brevity>... ) T CL-USER> This tells me that + is not a macro in my current environment. While loop is. And at least one of the powerful aspects of lisp is than since lisp programs are nested stets of s-expressions, you can design something that walks through the code and highlights all macro calls, and foreign functions that shadow native functions. I don't how difficult this would be for languages such as python. ... extended argument snipped ... > Or maybe it is only an advantage while Lisp programmers are a > self-selected group of above-average skill. Wait until fifty million VB > code monkeys start writing Lisp macros and maybe, just maybe, you'll wish > they were using a less powerful and more restrictive language. Perhaps it's because I'm a social scientist and not a programmer by training, but I find many arguments for *technical* solutions to *human performance* problems to be rather weak as a general practice. In some cases, using a very restrictive language may be the best solution for the problem. However, there are plenty of other ways around the problem that can be tailored to special needs. In addition to sandboxing macros into packages and walking the code to detect macros, you could run a custom lisp image that does not permit DEFMACRO or enforces documentation on DEFMACRO. Or you could rely on social mechanisms like only using libraries from trusted sources, and better training of those code monkeys. -- http://mail.python.org/mailman/listinfo/python-list