[pro] The Best Examples of "Code is Data"

Laughing Water lw at mt.net
Thu Sep 9 03:39:57 UTC 2010


Regarding the use of "it":

What if your editor could reveal the referent of "it" with a simple mouse-over? Would that be an adequate solution?

Come to think of it, programming could be easier in general if more information could appear in this "tool-tip" fashion rather than requiring the heavyweight mechanism of applying a tool that opens another window, or worse, looking up documentation in a separate web-browser.

I may be the least professional Lisper in this discussion, and I haven't learned my tools yet. So take my ideas for whatever they're worth.

LW


On Sep 8, 2010, at 8:34 AM, Hans Hübner wrote:

> On Wed, Sep 8, 2010 at 09:59, Julian Squires <julian at cipht.net> wrote:
>> I don't understand why anaphoric macros are so frowned upon.  Like any
>> powerful tool, it's easy to construct pathological situations where
>> they make code more difficult to understand.  However, I feel that
>> when tastefully used, they enhance the expressiveness of the language,
>> readibility of code, and they can help to reduce the verbosity of CL
>> of which many outsiders complain.  Of course, the prior two sentences
>> apply just as well to macros in general as they do to anaphora.
> 
> The power of macros gives Lisp programmers the freedom to create the
> language that they need, but every single modification of the language
> makes it derive from what another programmer would expect.  Thus, in a
> setting where the written code serves not only as instructions to a
> computer, but also as prose communicating intent to another
> programmer, it is vital to establish borders to the amount of language
> modification permitted.
> 
> There are certain idiomatic macro styles that are commonly understood
> amongs Lisp programmers, but the number of these styles is low.  One
> of them is the WITH-family used for implicit (and guaranteed) resource
> release, another is the DO-family for iteration.  These idiomatic
> styles are easy to recognize and well-established, so they are rather
> common.
> 
> Another family of macros that is everywhere, idiomatic and
> well-established is top-level definers.  That family certainly is much
> broader, and often a simple top-level definition form expands into
> loads of code.  They are often part of a larger framework, and as
> top-level forms they are easy to recognize.
> 
> Anaphoric macros usually are much harder to recognize visually, and
> they do "unexpected" things to source code on a micro-level.  This is
> what I object to.  Within the body of the anaphoric construct, a
> simple variable "it" suddenly becomes dependent on the local context.
> I find code with anaphoric macros harder to read than code that uses
> explicit variable names, because, in a linear reading flow, I am not
> told what a certain symbol is bound to.  Rather, I need to imagine the
> "it" myself when reading "awhen". [*]
> 
> What I do support is the use of combined test-and-bind macros
> (WHEN-BIND, WHEN-LET or similar).  They serve the same purpose as
> anaphoric macros (reduce repetetive words in local contexts), but they
> are much more scalable and require giving things names.
> 
> Anaphoric macros are a good example of things that one can do with
> Common Lisp and that one can also like about Common Lisp, but that are
> not useful in industrial software development practice.  When working
> together, making things as easy to read as possible is not only a
> question of style, but also of politeness and responsibility.  I am
> certainly not claiming that the macro types listed above are the only
> macros that are useful and should be allowed.  It is just that
> anaphoric macros, despite all their cuteness, tax code readers
> unnecessarily hard and thus have not been adopted as acceptable
> practice in multi-programmer environments.
> 
> -Hans
> 
> [*] I never really dug Forth for anything but  small programs because,
> like anaphoric macros in CL, Forth requires me to keep more state in
> my head when reading code.
> 
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro





More information about the pro mailing list