Re: Help sought: Details of byte-compile-make-closure, please.

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

Alan Mackenzie [2022-05-17 09:15:37] wrote:
> Whilst fixing bug #55323, I came across more places in the byte compiler
> where we might need to strip positions from symbols.

[ Sidenote: I don't understand why you'd need to strip the positions
  manually here.  Is it for the `(apply #'make-byte-code ...` case,
  because your later position-stripping code doesn't recurse within
  byte-code functions?  ]

> (i) Does byte-compile-make-closure get called at all when
> lexical-binding is nil?

No.

> (ii) Is the ARG argument to make-byte-code, extracted from the parameter
> FORM always in the bit-encoded form (7 bits for minimum args, 7 bits for
> maximum args and 1 bit for &rest), or might it sometimes be an "old
> fashioned" list of symbols?

It's never the "old fashioned" list of symbols, because that's only
used for lexical-binding==nil functions as you can see in
`byte-compile-lambda` where we do:

	     (apply #'make-byte-code
		    (if lexical-binding
			(byte-compile-make-args-desc arglist)
		      bare-arglist)

> I need to know this because such a list
> might need positions stripping from these symbols.

Indeed.

> (iii) Is there ever a non-null interactive form contained in the
> parameter FORM?

Usually not, but sometimes yes.

> (If so, it comes in in a &rest parameter and is
> forwarded to make-byte-code in an &optional argument.)  Such an
> interactive form may need positions stripping from its symbols too.

FWIW, I think that is `byte-compile-lambda` strips the positions then
`byte-compile-make-closure` won't need to (since all the args, constant
vector, interactive form, ... comes from the byte code returned by
`byte-compile-make-closure`).

Oh, actually not quite: the `docstring-exp` needs to be stripped before
passing it to `eval`.


        Stefan