[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Improve detection of local function calls in methods
From: |
Stefan Monnier |
Subject: |
Re: [PATCH] Improve detection of local function calls in methods |
Date: |
Fri, 10 Sep 2021 11:49:59 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> - (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