bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36392: (info "(elisp)Writing Emacs Primitives") might need some clar


From: Basil L. Contovounesios
Subject: bug#36392: (info "(elisp)Writing Emacs Primitives") might need some clarifications
Date: Wed, 26 Jun 2019 14:09:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

tags 36392 + patch
severity 36392 minor
quit

Attachment: 0001-Clarify-update-elisp-Writing-Emacs-Primitives.patch
Description: Text Data

Stefan Kangas <stefan@marxist.se> writes:

> As a beginner on Emacs Internals, I've been reading:
>
> (info "(elisp)Writing Emacs Primitives")
>
> I hope that you find the following observations useful:
>
> 1.  "If the primitive accepts a fixed maximum number of Lisp
>     arguments, there must be one C argument for each Lisp argument,
>     and each argument must be of type ‘Lisp_Object’.  ...  If the
>     primitive has no upper limit on the number of Lisp arguments, it
>     must have exactly two C arguments: the first is the number of Lisp
>     arguments, and the second is the address of a block containing
>     their values."
>
> The example given is DEFUN( "or", ...)
>
> This function has no upper limit on the number of Lisp arguments, but
> still has only ONE argument.  Unless I'm missing something, this
> contradicts the statement above that "it must have exactly TWO C
> arguments" (my emphasis).

Indeed, this is because For is a special form (with UNEVALLED args).
Compare it with the definition for Fapply (with MANY args) in the same
file, and see the macros DEFUN_ARGS_UNEVALLED and DEFUN_ARGS_MANY in
lisp.h.

Does the attached patch, suitable for either master or emacs-26, help
clarify this?

> 2.  "Although the garbage collector does not reclaim objects reachable
>     from C ‘Lisp_Object’ stack variables, it may move non-object
>     components of an object, such as string contents; so functions
>     that access non-object components must take care to refetch their
>     addresses after performing Lisp evaluation."
>
> I don't think this is very clear.  What is non-object components?  How
> would I refetch their addresses?  How is this relevant to the topic at
> hand?

I don't know about this.

Thanks,

-- 
Basil

reply via email to

[Prev in Thread] Current Thread [Next in Thread]