"Kay Schluehr" <[EMAIL PROTECTED]> writes: > Kirk Job Sluder schrieb: > > In what way do lisp macros prevent the creation of modular libraries? > > Common Lisp does does have mechanisms for library namespaces, and in > > practice a macro contained within a library is not that much different > > from a function contained in a library or a class contained in a > > library. Macros just provide another mechanism for creating useful > > domain-specific abstractions. > > To be honest I don't understand what a "domain-specific abstraction" > could be? What is the benefit of abstractions if they are not > abstracting from particular domain specific stuff?
The usual trend in higher level languages is to abstract away from the algorithmic details into domain-specific applications. So for example, rather than writing a block of code for handling the regular expression '[a-zA-Z]+, then a different block of code for the case, 'a|b|c', we have a regular expression library that packages up the algorithm and the implementation details into an interface. The python standard library is basically a collection of such abstractions. In python you usually work with strings as an object, rather than as an array of byte values interpreted to be linguistic characters located at a specific memory address as you would in c. Object oriented programming is all about creating domain-specific abstractions for data. This enables us to talk about GUIs as widgits and frames in addition to filling in pixels on a screen. Or to talk about an email Message as a collection of data that will be stored in a certain format, without having to do sed-like text processing. > > The primary advantage to macros is that > > you can create abstractions with functionality that is not easily > > described as either a function or a class definition. > > As long as macros are used to create new language features such as an > object system like CLOS this technique may be perfectly justified for > language developers ( ! ) but I still consider it as a bad idea to > muddle the language development and the application development, that > seems to be the favourite programming style of Paul Graham. On the > other hand thinking about language development as a certain application > domain I find nothing wrong with the idea that it once reaches somehow > a state of a mature product that should not be altered in arbitrary > manner for the sake of a large user community. Well, at this point, Common Lisp has been formally standardized, so changing the core standard would be very difficult. There is in fact, strong resistance to reopening the standards process at this time, based on the impression that most of what needs to be done, can be accomplished by developing libraries. So I think that CL as a mature product is not altered in an arbitrary manner. However, from my view, quite a bit of development in python involves adding new language constructs in the form of classes, functions, and instance methods, as well as interfaces to C and C++ libraries. I would argue this is one of the core strengths of python as a language, the fact that we are only limited to the builtin functions and standard library if we choose to be. As an example, whenever I work with a new data source, I usually end up creating a class to describe the kinds of records I get from that data source. And some functions for things that I find myself repeating multiple times within a program. Macros are just another way to write something once, and use it over and over again. > > Kay > -- Kirk Job-Sluder "The square-jawed homunculi of Tommy Hilfinger ads make every day an existential holocaust." --Scary Go Round -- http://mail.python.org/mailman/listinfo/python-list
