- Use "\(fn ARG1 ARG2...)" now (so 22.1 at least has good cl docstrings)
- Use the best method available, once we branch 22.1
That represents doing twice the fixing, but I don't mind, and it'll
get us the best results (assuming I don't screw up the docstrings :)
I would not have
> However, coherence between functions is one factor in what
> makes any particular argument name better or worse.
Sure, of course. That's why I said "absolute".
Anyway, as I share Kim's (and others') worries about even small
changes during a freeze (other than cosmetic, like docstring fixes,
obs
> We never told users it was ok to use these as free variables, so we
> don't have to worry about that issue. However, when changing the arg
> names of a function in CL that calls other functions in CL, it would
> be good to verify that the called functions don't use them as
> free variables.
> (
> How about if you do whatever is best so as to use the best possible names
> in each function?
OK. That's even better. assuming there's no interest in maintaining
absolute argument-name consistency between functions (which doesn't
exist now, to be fair).
There is no need for
Thanks to the wonders of dynamic scoping this actually changes the
semantics subtly. In most cases you'll never be able to tell the
difference, but when higer-order functions are involved it can be a problem;
so if you do that, be careful.
We never told users it was ok to use thes
> And do _not_ do it before the release!
Well, changing argument names can be destabilizing. Changing
docstrings certainly is not.
--
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinf
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> 2) Change the argument names to match the docstrings.
>> Pros: it is the cleaner way.
>> Cons: lot of change in the cl* files; less coherence between argument
>> names among functions.
>
> Thanks to the wonders of dynamic scoping this a
> How about if you do whatever is best so as to use the best possible names
> in each function?
OK. That's even better. assuming there's no interest in maintaining
absolute argument-name consistency between functions (which doesn't
exist now, to be fair).
--
/L/e/k/t/u
2) Change the argument names to match the docstrings.
Pros: it is the cleaner way.
Cons: lot of change in the cl* files; less coherence between argument
names
among functions.
3) Change the docstrings to match the argument names.
Pro: easy.
C
> 2) Change the argument names to match the docstrings.
> Pros: it is the cleaner way.
> Cons: lot of change in the cl* files; less coherence between argument
> names among functions.
Thanks to the wonders of dynamic scoping this actually changes the
semantics subtly. In most case
Many cl*.el functions have a mismatch between the real argument names
and the ones used in their docstrings (mostly because many cl
functions do use some kind of old "standardized" naming scheme for
arguments, like cl-env, cl-keys, etc.).
For example, `cl-macroexpand' uses cl-macro and cl-env as a
11 matches
Mail list logo
