<div>Attila's experience matches mine: anaphoric macros are useful because</div><div>they enhance readability. (I mean, of course, when they're used</div><div>properly, but that's such a tiresome caveat to have to add and I'm</div>
<div>hoping one benefit of this list is that we don't have to jump through</div><div>*all* the usual hoops.) Given this experience I find it hard to fathom</div><div>the critique of anaphoric macros that they are bad for readability.</div>
<div><br></div><div>Plausible reasons for disagreement are (a) we've had different</div><div>experiences; (b) we have different tastes; or (c) we're talking about</div><div>different things. Perhaps the best approach in every case is to make</div>
<div>our terms explicit, so at risk of overspecifying I'm going to be as</div><div>explicit as I can.</div><div><br></div><div>"Anaphoric macros" for me nearly always means AWHEN or AIF, very</div><div>occasionally ACOND and that's about it. When I say these "improve</div>
<div>readability" I mean that they make code shorter in an easily grokkable</div><div>way. "Used properly" means "used in a small snippet": when their scope</div><div>grows beyond the nearly trivial, their benefit -- concision -- tends</div>
<div>to get diluted to the point of why bother. Worse, the meaning of IT</div><div>gets exponentially harder to grok the further IT strays from ITs</div><div>anaphoric introduction.</div><div><br></div><div>Here are two simple examples chosen nearly at random from the Skysheet</div>
<div>code (Skysheet is the web-based spreadsheet startup I'm working at):</div><div><br></div><div> (awhen (search "Version/" str)</div><div> (after-slash it))</div><div><br></div><div> (awhen (getf sh :col-deltas)</div>
<div> (alist->hash it))</div><div><br></div><div>AWHEN makes these forms slightly more trivial than they would be</div><div>without it. I like that: trivial is second only to non-existent as a</div><div>good thing for code to be.</div>
<div><br></div><div>Here are two more. These are about as complex as I'd ever like an</div><div>anaphoric macro to get:</div><div><br></div><div> (awhen (next-as-binary-op)</div><div> (when (>= (precedence it) level)</div>
<div> (consume)</div><div> it))</div><div><br></div><div> (aif (implicit arg)</div><div> (cond ((eq it :column) +abs-row+)</div><div> ((eq it :row) +abs-col+)</div><div> (t +abs-abs+))</div>
<div> (aim-rank (getf arg :aim)))</div><div><br></div><div>(That COND would be better as a CASE, but it has to run in both CL and</div><div>JS via Parenscript, and CASE doesn't map to an expression in the</div><div>
latter.)</div><div><br></div><div>In all four examples I prefer AWHEN/AIF to an explicit binding because</div><div>it makes the code shorter and more idiomatic. I guess you'll have to</div><div>take my word for it that the concept temporarily denoted IT is in each</div>
<div>case obvious from context and would not get any obviouser with an</div><div>explicit name.</div><div><br></div><div>A couple of general reflections.</div><div><br></div><div>Readability is hard to talk about because it's so in the eye of the</div>
<div>beholder. My own views on what's readable have changed a lot. They</div><div>even vary per-program. In the end I find the definition is a cultural</div><div>thing that has to get hammered out on a per-project basis by people</div>
<div>who are working together (and needs a certain amount of re-hammering</div><div>with each new person).</div><div><br></div><div>Finally, I hesitate to post the above because anaphoric macros are</div><div>kind of a bike-shedding topic: not that interesting but easy to have</div>
<div>an opinion about, so they get argued about more than they deserve. But</div><div>I think it's a useful exercise occasionally to get right down to the</div><div>threading on the screws. Too often in abstract discussions about</div>
<div>programming I find myself wondering what people really mean; this</div><div>experience gets worse as the subject matter gets more meta. Perhaps</div><div>anaphoric macros are worth talking about *because* they are so</div>
<div>simple. They're a chance to practice talking concretely about</div><div>abstraction.</div><div><br></div><div>Dan Gackle</div><div><br></div><br><div class="gmail_quote">On Mon, Sep 27, 2010 at 3:56 AM, Attila Lendvai <span dir="ltr"><<a href="mailto:attila.lendvai@gmail.com">attila.lendvai@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> macros that are useful and should be allowed. It is just that<br>
> anaphoric macros, despite all their cuteness, tax code readers<br>
> unnecessarily hard and thus have not been adopted as acceptable<br>
> practice in multi-programmer environments.<br>
<br>
<br>
</div>well, it's one opinion.<br>
<br>
there's at least one counter example in our team of 4. and i<br>
personally do like reasonable usage of anaphoric macros, even when<br>
done by my colleagues. and the reason is exactly that it *rises* code<br>
readability for us.<br>
<br>
our practice includes special coloring for "it" and avoids any usage<br>
which is not blatantly trivial.<br>
<font color="#888888"><br>
--<br>
attila<br>
<br>
PS: argh, i so much didn't want to join such a subjective<br>
discussion... i need to meditate on this a bit more to successfully<br>
resist next time. the first exercise will be to let go my opinion of<br>
with-nesting... :)<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
pro mailing list<br>
<a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
</div></div></blockquote></div><br>