On 20.08.23 05:57, Michael Heerdegen wrote:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
>> (debug ((&rest [&or (&define [&name symbolp "@cl-flet@"]
>> 			[&name [] gensym] ;Make it unique!
>> 			cl-lambda-list
>> 			cl-declarations-or-string
>> 			[&optional ("interactive" interactive)]
>> 			def-body)
>> 		    (&define [&name symbolp "@cl-flet@"]
>> 			[&name [] gensym] ;Make it unique!
>> 			def-body)])
> 
>> The second &define is for the (FN EXPR) bindings.  It comes after the
>> &define for "normal" function bindings because because, for some
>> reason, apparently the second &define also matches the other case.
> 
> That's because you use 'def-body' which matches any number of body
> expressions.  I think this is not correct: we are expecting a single
> form.

Ah, I see.  Thanks.

> 
> Apart from that: yes, something like this... I did not yet understand
> the &name magic.
> 
> And i wonder whether we should apply the distributive law and factor out
> the first few identical specs inside the &or.

I'd rather keep the two separate, I must admit.  Basically, bacause the 
first case it the important one, and the second I find obscure.

I also checked now what's up with functions whose name is (setf ...), 
which is valid CL.  That's not supported in ELisp, it seems, so I 
changed the debug spec of cl-defun accordingly in the attached patch.

If this looks good, I'd bring that to master, unless Eli wants it in 29.