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. 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. 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. -- 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
