Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> One big category of nil car's resulted from all the :autoload-end's around.
>
> Oh, what you mean is that nil is when the element is not a cons cell?
> Indeed that makes sense.
> [ Cons cells with a nil element would be surprising, OTOH.  ]

Yep, like :autoload-end :). 

>> That leaves a number with explicit nil cars in their expansion, for
>> whatever reason:
>
> I think these have `nil` in the list of forms (that follows a `progn`),
> but not in the `car` of one of the forms, right?  So again, it's when
> `form` is not a cons-cell.
> In any case, indeed those non-cons situations justify the "not nil" check.

Yes, but I just wonder what such non-conses are doing in the expansion.
Maybe just doc strings or some such.

>> No, it's a good chance to learn.  Will want to iterate on docs first, if
>> you think its ready (I think it is).
>
> I was thinking to do it in the single-hunk bug fix, which I do think is
> ready (it just needs a commit message).

Is the commit message in need of expansion?  I worked up some quick docs
and included in the patch; see attached.

>> Have you had a chance to test it "in the wild" with a custom macro?
>
> No, not yet.  But I think the transient macros are a good test case.

Good idea.  Michael, if you can try this along with a patch like the one
Stefan proposed for tramp (correcting the declare form name) that would
be useful.  Assuming it all works as expected, you'll notice
`tramp-loaddefs.el' no longer contains the macro and the calls to it,
but rather only the expanded forms it generates.