> The Python approach leads to more readable >code: http://www.mired.org/home/mwm/papers/readability.html
The two cases he sites do not apply to Clojure: The first case is a function that is allowed to change the value of a variable passed into it. Variables are immutable in Clojure so you can't write the dangerous 'inc' function he describes. You can't change the value of a variable passed to a function in Python either, but you can pass a mutable object to a function and have the function modify the object, which is close to the same thing. Clojure is much more readable than Python in this regard. The second case is a function that is allowed to change the order of evaluation of its arguments, decide how many times to evaluate its arguments, and even whether or not to evaluate an argument at all. True, in a language that allows side effects this can be confusing. But this doesn't apply to Clojure. (Clojure does allow side effects through STM of course, but this is very explicit and controlled - more readable.) I agree that macros can in some cases lead to less readable code. On the other hand, mutability hurts readability too. Steve On Mon, Jun 28, 2010 at 2:04 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > 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<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- 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
