bug#42691: 28.0.50; eval-and-compile

bug#42691: 28.0.50; eval-and-compile

[Helmut Eller]

Compiling this example:

  (require 'cl-lib)
  (cl-macrolet ((foo () '123))
    (eval-and-compile (foo)))

with

  emacs -Q --batch -f batch-byte-compile bug.el

prints:

  In toplevel form:
  bug.el:2:1: Error: Symbol’s function definition is void: foo

I think when compiling eval-and-compile the macro-environment is not
passed along properly.


In GNU Emacs 28.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
 of 2020-08-03 built on caladan
Repository revision: e1f09607e02eb507b229285ed48b85a3c6a50259
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

bug#42691: 28.0.50; eval-and-compile

[Andreas Schwab]

On Aug 03 2020, Helmut Eller wrote:

> Compiling this example:
>
>   (require 'cl-lib)
>   (cl-macrolet ((foo () '123))
>     (eval-and-compile (foo)))
>
> with
>
>   emacs -Q --batch -f batch-byte-compile bug.el
>
> prints:
>
>   In toplevel form:
>   bug.el:2:1: Error: Symbol’s function definition is void: foo
>
> I think when compiling eval-and-compile the macro-environment is not
> passed along properly.

Only the body of eval-and-compile is evaluated at that point.  If you
want to modify the environment of the evaluation, you need to move that
modification inside the eval-and-compile form.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#42691: 28.0.50; eval-and-compile

[Helmut Eller]

On Mon, Aug 03 2020, Andreas Schwab wrote:

> On Aug 03 2020, Helmut Eller wrote:
>
>> Compiling this example:
>>
>>   (require 'cl-lib)
>>   (cl-macrolet ((foo () '123))
>>     (eval-and-compile (foo)))
>>
>> with
>>
>>   emacs -Q --batch -f batch-byte-compile bug.el
>>
>> prints:
>>
>>   In toplevel form:
>>   bug.el:2:1: Error: Symbol’s function definition is void: foo
>>
>> I think when compiling eval-and-compile the macro-environment is not
>> passed along properly.
>
> Only the body of eval-and-compile is evaluated at that point.  If you
> want to modify the environment of the evaluation, you need to move that
> modification inside the eval-and-compile form.

Are you saying this is not a bug in eval-and-compile?

The docstring of eval-and-compile says eval-and-compile is like progn,
except that the body it is evaluated at compile-time too.  If it is
supposed to work like progn, then the environment should be defined as
for progn.

Helmut

bug#42691: 28.0.50; eval-and-compile

[Andreas Schwab]

On Aug 03 2020, Helmut Eller wrote:

> Are you saying this is not a bug in eval-and-compile?

Yes.

> The docstring of eval-and-compile says eval-and-compile is like progn,
> except that the body it is evaluated at compile-time too.  If it is
> supposed to work like progn, then the environment should be defined as
> for progn.

At runtime, yes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#42691: 28.0.50; eval-and-compile

[Helmut Eller]

On Mon, Aug 03 2020, Andreas Schwab wrote:

> On Aug 03 2020, Helmut Eller wrote:
>
>> Are you saying this is not a bug in eval-and-compile?
>
> Yes.
>
>> The docstring of eval-and-compile says eval-and-compile is like progn,
>> except that the body it is evaluated at compile-time too.  If it is
>> supposed to work like progn, then the environment should be defined as
>> for progn.
>
> At runtime, yes.

So you are arguing, that the body should be evaluated and macro-expanded
in the null environment.  That's not like progn at all.  Obviously, I
disagree.  I also note that

  emacs -Q --batch -l bug.el

prints:

  Eager macro-expansion failure: (void-function foo)
  Eager macro-expansion failure: (void-function foo)
  Symbol’s function definition is void: foo

which I also consider a bug.

Helmut

bug#42691: 28.0.50; eval-and-compile

[Andreas Schwab]

On Aug 03 2020, Helmut Eller wrote:

> So you are arguing, that the body should be evaluated and macro-expanded
> in the null environment.

No, I don't.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#42691: 28.0.50; eval-and-compile

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Are you saying this is not a bug in eval-and-compile?
>
> Yes.

I think that's correct -- the `eval-and-compile' makes the contents
evaluate in contexts where it otherwise wouldn't be evaluated.  But it
doesn't make the enclosing forms be evaluated in those contexts, so in
this case, they have to be moved down inside the `eval-and-compile'.

So this seems to be working as designed, and I'm closing this bug
report.  (If I misunderstood what this was about, please respond to the
debbugs address and we'll reopen.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no