Re: defmacro with built-in gensym declaration and initialization

[Basil L. Contovounesios]

akater <nuclearspace@gmail.com> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> IMO, this minor convenience is insufficient motivation for
>> conflating/complicating a macro's global arglist, i.e. its arity,
>> calling convention, etc., with utilities for its local body.  Is there
>> some other motivation?  Am I missing something?
>
> My motivation mostly comes from CL where complicated lambda lists are
> not considered an issue, and it didn't come to my mind it could be an
> issue for Emacs Lisp users.  In particular, &gensym does indeed follow
> the design of &aux, described below as “hideous” (another surprise).

I'd seen &aux before but didn't look up what it does until now, and I
must say I share Stefan's sentiment :).

> I use &aux regularly, and I find it a nice addition as it reduces the
> nesting depth of defun and defmacro forms.  &gensym does that and saves
> some boilerplate on top of it, I tried it in real life macros, found it
> useful, and that's pretty much it.

Let's just say I would sooner see native arglists gain support for
keyword arguments ;).

For non-native arglists, we could always extend cl-defmacro or some
other definition definer.

>> conflating/complicating a macro's global arglist, i.e. its arity,
>
> What's the arity of defmacro?  This form already allows any number of
> arguments so as far as I can see adding another keyword does not change
> arity.  Calling convention is backwards compatible.

I was referring to the arity of the macro being defined, not that of
defmacro.

> Again, Common Lisp
> implementations are allowed to introduce their own lambda list keywords
> so I didn't (and still don't) think extending lambda-list keywords set
> is a big deal.

I can't imagine it being as little a deal in Elisp, but that's just my
impression.

>> Why not provide handy gensym/once-only local conveniences for macro
>> authors instead (some of which already exist in one form or another,
>> e.g. macroexp-let2, inline-letevals, and org-with-gensyms)?
>
> I don't have much experience with macroexp-let2 which on the first
> glance looks like an overcomplicated once-only that is mostly relevant
> for functions that are meant to be byte-compiled.

It and its variant macroexp-let2* are relevant wherever the macro author
wants to avoid evaluating an argument more than once, but improvements
are always welcome.

> Since we're moving to
> natively compiled Elisp, I was thinking it's going to become less
> relevant in near future, and &gensym covers most use cases of once-only.

I don't see how native compilation changes how existing and new Elisp
macros ought to be written.

> Again, org-with-gensyms is precisely something that's being replaced
> here with an alternative that is less verbose and has a decreased
> nesting depth.

Just my 2 cents,

-- 
Basil