<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark,<br>
<br>
Mark Haniford wrote:
<blockquote
cite="mid:AANLkTik5BdJMECZ-z6R2JnVO81Hs7h9RvK2RDCzAMTTR@mail.gmail.com"
type="cite">
<pre wrap="">That's just Emacs. Most modern tools in the Java or .NET world
already do that type of stuff. Apple's Dylan IDE probably would
have that stuff 10-12 years ago, but NeXT came around and the rest is
history.
</pre>
</blockquote>
<br>
Unfortunately, there are serious problems introduced<br>
by the use of macros. There are "lines of code" that<br>
cannot be seen in the source, because they are<br>
produced by macros.<br>
<br>
One place where this obviously causes problems<br>
is code coverage tools. You run all of your tests,<br>
and the tool tells you what lines of code didn't<br>
ever get tested. (That's an oversimplified<br>
nutshell description.) The Clozure team<br>
is working on a solutinon to this problem.<br>
I don't know to what degree that work<br>
could be applied to other areas of IDE<br>
capabilites, such as you said.<br>
<br>
One of the very first things you want when<br>
you start writing macros is for auto-indentation<br>
to do the right thing. The IDE can't just<br>
know this for a macro.<br>
<br>
In case you want to know how we do this, read<br>
the rest of this mail. Fasten your seatbelts;<br>
we're in for a bumpy ride!<br>
<br>
To deal with this, in our system, we collect<br>
information for each macro about how<br>
it should be indented. For conmmon<br>
idiomatic cases, this is done automatically,<br>
but you can do it manually or complicated<br>
macros or where the automatic generation<br>
isn't right. There is a "little language"<br>
for declaring how a form should be indented.<br>
In some places in the code, the forms of<br>
this "little language" are called "indentaiton<br>
descriptors" (which I think is a good name).<br>
<br>
We load all of the code of our system into<br>
Lisp, just as anyone would. During the<br>
load, the loaders sees top level forms<br>
that associate the names of the macros<br>
with a little data structure in the "little<br>
language". It puts these into a simple<br>
hash table, keyed by the name of the function.<br>
<br>
We also load swank (the Lisp side of<br>
Slime). This will automatically read<br>
in the per-site swank modifications,<br>
in site-init.lisp. It sends this back to<br>
Slime, with the keyword :indentation-update.<br>
(It would be nice if this keyword contained<br>
"indentation-descriptor" in its name, but<br>
that's not important here.)<br>
<br>
This causes Slime to call slime-handle-indentation-update.<br>
This puts the new indentation desriptor<br>
on both the slime-indent and the common-lisp-indent-function<br>
properties of the symbol whose indentation we're been<br>
talking about. This gets examined by the code<br>
in site-init.el (that's the Emacs side of the per-site<br>
stuff). In our case, a GNU Emacs function named<br>
"cl-indent:function) gets called. This is a very<br>
big and complicated function, which interprets<br>
the "little language" (the indentation descriptor).<br>
<br>
<br>
<br>
Next, we have a top-level form in our<br>
<br>
libs/slime/site-init.lisp<br>
<br>
Next, we have a top-level form in our<br>
site-init. What it does is to make<br>
a one-element list of the hash table,<br>
and then set <br>
<br>
swank::*application-hints-tables*<br>
<br>
to that list.<br>
<br>
Next, when we load swank, we also load<br>
some of the nice contributed swank libraries,<br>
and one of the ones we load is called<br>
<br>
contrib/swank-indentation.lisp<br>
<br>
also, back when we loaded slime,<br>
we also loaded into GNU Emacs<br>
the file <br>
<br>
contrib/slime-indentation.el<br>
<br>
The Lisp function<br>
<br>
symbol-indentation<br>
<br>
is re-defined to do indentation by first<br>
looking for the symbol in our hash table,<br>
and if it's not found, doing what the original<br>
symbol-indentation function would have done.<br>
(You can see that in swank.lisp.)<br>
<br>
If it does find a result in the hash table, that<br>
means we stated how the macro should indent,<br>
using the "little language". When Slime<br>
needs to indent something, one of the things<br>
it does is to send a message to Swank<br>
that causes Swank to run symbol-indentation<br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:AANLkTik5BdJMECZ-z6R2JnVO81Hs7h9RvK2RDCzAMTTR@mail.gmail.com"
type="cite">
<pre wrap="">
On Wed, Sep 8, 2010 at 10:39 PM, Laughing Water <a class="moz-txt-link-rfc2396E" href="mailto:lw@mt.net"><lw@mt.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Sep 8, 2010 at 09:59, Julian Squires <a class="moz-txt-link-rfc2396E" href="mailto:julian@cipht.net"><julian@cipht.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:pro@common-lisp.net">pro@common-lisp.net</a>
<a class="moz-txt-link-freetext" href="http://common-lisp.net/cgi-bin/mailman/listinfo/pro">http://common-lisp.net/cgi-bin/mailman/listinfo/pro</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
pro mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pro@common-lisp.net">pro@common-lisp.net</a>
<a class="moz-txt-link-freetext" href="http://common-lisp.net/cgi-bin/mailman/listinfo/pro">http://common-lisp.net/cgi-bin/mailman/listinfo/pro</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
pro mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pro@common-lisp.net">pro@common-lisp.net</a>
<a class="moz-txt-link-freetext" href="http://common-lisp.net/cgi-bin/mailman/listinfo/pro">http://common-lisp.net/cgi-bin/mailman/listinfo/pro</a>
</pre>
</blockquote>
</body>
</html>