Re: [PATCH] Improve detection of local function calls in methods

[Stefan Monnier <monnier@iro.umontreal.ca>]

> - (func exp) is non-standard and ad-hoc.

(FUNC EXP) is indeed non-standard.  But I completely disagree with
`ad-hoc`: IMO this form is the fundamental form of `flet` (it
corresponds directly to `let`, just in the function namespace) and
the form (FUNC ARGS &rest BODY) should be viewed as a simple syntactic
sugar for the common case of (FUNC (lambda ARGS &rest BODY)).

>   Do you happen to remember, maybe it was invented solely for
>   ~cl--generic-lambda~?

It was added to Emacs's `master` for the purpose of
`cl--generic-lambda`, yes.  It was invented long before, OTOH ;-)
[ I still can't explain how I forgot to add it when we moved from
  `flet` to `cl-flet` in Emacs-24.3.  ]

> - (func exp) definition form is described incorrectly in the docstring:
>   it should be (FUNCTION-NAME SYMBOL) and so on;

Not sure what you mean here.  Do you mean `func` should be
`function-name` since this should be a symbol and not a function?
[ I would agree with that, tho `function-name` would be longish so
  I'd rather go maybe with just `name`.  ]
Or do you mean that `exp` should be `symbol`?
If so, I disagree because this allows an arbitrary expression that's
evaluated before its resulting value is bound to the specified function
symbol.

>   this also affects `cl-macrolet` docstring which claims it's “like
>   `cl-flet`” but in fact it's not as it doesn't support this definition
>   form

Indeed, this was not updated when `cl-flet` was extended.
Not sure what's best to do here:
- we could extend `cl-macrolet` to also accept (NAME EXP), but this is
  much less useful for macros since EXP is evaluated in the
  macroexpansion context.
- tweak the docstring to clarify the "like"ness.

> - ~cl-flet~ with invalid function names should error but it doesn't

You mean if the "function name" is not a symbol?
Indeed, it would be better to signal an error in that case.

> This involves a “macro” version of expand-flet; we'll see whether it's
> worth keeping alongside the corresponding function.

Your sample code looks OK, tho I don't think having a macro for it is
worth the trouble.


        Stefan