Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 13. Mai 2017 um 19:05 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 13 May 2017 16:44:08 +0200
> > Cc: Philipp Stephani <phst@google.com>
> >
> > Instead of a lambda, create a new type containing all data required to
> > call the function, and support it in the evaluator.  Because this type
> > now also needs to store the function documentation, it is too big for
> > Lisp_Misc; use a pseudovector instead.  That also has the nice benefit
> > that we don't have to add special support to the garbage collector.
>
> Thanks.
>
> > +#ifdef HAVE_MODULES
> > +  else if (MODULE_FUNCTIONP (fun))
> > +    doc = XMODULE_FUNCTION (fun)->documentation;
> > +#endif
>
> I wonder whether it would be cleaner to have MODULE_FUNCTIONP defined
> even when HAVE_MODULES is not: it looks like it could save us quite a
> few #ifdef's.
>

Done.


>
> > -DEFUN ("internal--module-call", Finternal_module_call,
> Sinternal_module_call, 1, MANY, 0,
> > -       doc: /* Internal function to call a module function.
> > -ENVOBJ is a save pointer to a module_fun_env structure.
> > -ARGLIST is a list of arguments passed to SUBRPTR.
> > -usage: (module-call ENVOBJ &rest ARGLIST)   */)
> > -  (ptrdiff_t nargs, Lisp_Object *arglist)
> > +Lisp_Object
> > +funcall_module (const struct Lisp_Module_Function *const envptr,
> > +                ptrdiff_t nargs, Lisp_Object *arglist)
> >  {
>
> I don't think we can simply remove a function that was already present
> in one or more Emacs releases.  We need to provide a backward
> compatibility layer, and definitely also mention this in NEWS.
>

This is purely internal, and we can change implementation details at will.
I've added a NEWS entry, though.