On Mon, 28 Jun 2010 11:21:24 -0700 (PDT) cageface <milese...@gmail.com> wrote:
> On Jun 28, 11:09 am, Daniel Gagnon <redalas...@gmail.com> wrote: > > That feature would *not* be a simple macro. It isn't simply a call to .close > > on whatever object, it's an arbitrary cleanup procedure on any object that > > implements the feature. The whole standard library implements it and objects > > know how to clean after themselves. So do most third objects like database > > connexions and what not. > > So in order to make this work in Python the *entire* standard library > had to be modified to support it? That's worse than I thought. No, only those that wanted to take advantage of it. > It's an interesting point though. In a certain sense, a macro is > establishing an interface across a set of objects. In writing a macro > you are implying that there exists a set of objects for which the > macro's transformation is logical. The python "with" statement > required implementation of the implied interface across all valid > arguments, whereas the macro version takes advantage of the fact that > most of the applicable objects just happen to have a .close method. In > both cases you're dealing with "with-able" objects. The difference is > that the "interface" that objects can expose to macros is much richer > because arbitrary syntactic fragments are "objects" in this sense. You're making a false assumption. Most of the valid library objects *didn't* have a ".close" method. The decimal library was tweaked to allow the with statement to create a new context, and automatically restore the previous one. The various forms of locking things were all tweaked so that you could use the with statement to acquire a lock that was released on exit. These things could have been done with a simple macro, but would have required tweaking the library to add a "close" function for the objects, even if the function name made no semantic sense. Either that, or use a different name for the function, and then go through and rewrite "the *entire* standard library" to take advantage of it. > The python approach is superior if you believe, as Guido apparently > does, that the useful set of syntactic constructs is small and well- > bounded. If you think, as most lispers do, that syntactic manipulation > is the essence of expressive power then the work it takes to add *one* > new keyword to a language like python seems farcical. The Python approach leads to more readable code: http://www.mired.org/home/mwm/papers/readability.html <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
