Just because there does not appear to be any logic behind a certain decision does not mean it's a bug.
That being said, I've always thought of the compiler workflow in Lisp as being (conceptually): Reader / Data -> Macro Expander -> Compiler. Naturally, macros must be expanded in the macro expansion phase. Special forms, however, are not macros. And while they must participate in the macro expansion phase to some extent (to determine which subforms are subject to macro expansion), I always figured any logic (other than expansion) would be done by the Compiler. In this case, however, it seems that there is logic being applied to a special form that affects the way the form is interpreted (by the compiler) before expansion is done. While that's not necessarily wrong: 1. It doesn't fit my conceptual compilation model (is my model too simple?) 2. In general, wouldn't it make sense to apply any such logic only after all the sub-forms are expanded? Are there special forms for which that rule would not apply? 3. There seem to be compiler states that can not be trivially reached if we first walk the tree, expand all the macros (like the built-in macro expander would), and pass the expanded code into the compiler. In this case, I think we can make the two semantically equivalent by introducing a "try" pseudo-macro that scans the pre-expanded form (like the compiler would) and wraps the resulting body in a "do" form. Does this violate separation between the macro expander and the compiler? Are there states that can not be reached (i.e., the pre-expanded code is semantically different than the non-expanded code), no matter how we implement our expander? Nathan Davis On Tuesday, April 2, 2013 3:37:14 PM UTC-5, Cedric Greevey wrote: > > On Tue, Apr 2, 2013 at 12:20 AM, Bill Robertson > <billrob...@gmail.com<javascript:> > > wrote: > >> While it may violate the principle of least surprise (until you >> realize/learn that try/catch is a special form), I don't think it's a bug. >> > > Since there's no good engineering reason not to permit macros like > (rethrow ...) to work, it is a bug. Also, pointing out that macros that can > break this property is something of a straw man when I'm indicating that > something *built into the language* has the problem. The latter can be a > language fault even if the former is not. > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
