Question about eval and compile-command

Question about eval and compile-command

[Eshel Yaron]

Hi all,

I'm curious as to why `compile` and `recompile` use `eval` to evaluate
the value of `compile-command`.  AFAICT since commit
5b6858da26e4e6671ee93b67b921a86309b3d6a2 (July 19 2001), these commands
evaluate `compile-command`, as if it's expected to be an expression that
evaluates to a string rather than just a plain string.

The commit message says:

    (compilation-parse-errors): `linenum' might return a this-error using
    the alternative format (a pair of markers).

But I don't quite understand how that relates to `compile-command`.

Also, the `:type` of `compile-command` remains `string`, and I couldn't
find any mention of the value of `compile-command` being evaluated that
way in the relevant documentation.

I wonder if this is just a remnant of a past experiment or an
undocumented feature.  Or maybe there's something else I'm missing?

Thanks,

Eshel

Re: Question about eval and compile-command

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Date: Thu, 03 Aug 2023 12:29:38 +0300
> 
> Hi all,
> 
> I'm curious as to why `compile` and `recompile` use `eval` to evaluate
> the value of `compile-command`.  AFAICT since commit
> 5b6858da26e4e6671ee93b67b921a86309b3d6a2 (July 19 2001), these commands
> evaluate `compile-command`, as if it's expected to be an expression that
> evaluates to a string rather than just a plain string.
> 
> The commit message says:
> 
>     (compilation-parse-errors): `linenum' might return a this-error using
>     the alternative format (a pair of markers).
> 
> But I don't quite understand how that relates to `compile-command`.

It doesn't, it describes the change in compilation-parse-errors.

It looks like Stefan added the 'eval' calls as a minor cleanup and not
as part of the change itself.  Stefan, any chance you remember why you
added the 'eval' calls?

Re: Question about eval and compile-command

[Stefan Monnier]

> It looks like Stefan added the 'eval' calls as a minor cleanup and not
> as part of the change itself.  Stefan, any chance you remember why you
> added the 'eval' calls?

I added it to allow the `compile-command` to be
(re)computed dynamically.


        Stefan

Re: Question about eval and compile-command

[Eshel Yaron]

Thanks Eli, Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It looks like Stefan added the 'eval' calls as a minor cleanup and not
>> as part of the change itself.  Stefan, any chance you remember why you
>> added the 'eval' calls?
>
> I added it to allow the `compile-command` to be
> (re)computed dynamically.

I have two followup questions in that case:

1. Given that this is meant to allow recomputing `compile-command`
dynamically, why does `compile` set `compile-command` to its `command`
argument (which is a string, not an expression)?  This potentially
causes `compile-command` to only be dynamically evaluated in the first
invocation of `compile`, before being set to a plain string.  Consider:

--8<---------------cut here---------------start------------->8---
(let ((compilation-read-command nil)
      (compile-command '(concat "echo " (int-to-string (random 100)))))
  (call-interactively #'compile)
  compile-command)
  => "echo 38"
--8<---------------cut here---------------end--------------->8---

We see that `compile` had the side effect of setting `compile-command`
to a string.

2. Should the manual/docstrings reflect that `compile-command` can be
computed dynamically in this manner?  I'd be happy to contribute a patch
documenting this feature, expect I'm not totally sure how users should
best leverage it (see previous question).

Re: Question about eval and compile-command

[Stefan Monnier]

>> I added it to allow the `compile-command` to be
>> (re)computed dynamically.
> I have two followup questions in that case:
> 1. Given that this is meant to allow recomputing `compile-command`
> dynamically, why does `compile` set `compile-command` to its `command`
> argument (which is a string, not an expression)?

Looks like I overlooked this at the time :-(


        Stefan

Re: Question about eval and compile-command

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It looks like Stefan added the 'eval' calls as a minor cleanup and not
>> as part of the change itself.  Stefan, any chance you remember why you
>> added the 'eval' calls?
>
> I added it to allow the `compile-command` to be
> (re)computed dynamically.

In retrospect, shouldn't the type be be a string or a function?  For
former for a static command, the latter for a dynamically computed one?

>
>         Stefan

Re: Question about eval and compile-command

[Stefan Monnier]

>> I added it to allow the `compile-command` to be
>> (re)computed dynamically.
> In retrospect, shouldn't the type be be a string or a function?  For
> former for a static command, the latter for a dynamically computed one?

Very definitely.


        Stefan

Re: Question about eval and compile-command

[Andreas Schwab]

On Aug 03 2023, Philip Kaludercic wrote:

> In retrospect, shouldn't the type be be a string or a function?

Not a function, but a form.

-- 
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."

RE: [External] : Re: Question about eval and compile-command

[Drew Adams]

> > In retrospect, shouldn't the type be be a string or a function?
> 
> Not a function, but a form.

A string is a form too...

   A Lisp object that is intended for
   evaluation is called a "form"

https://www.gnu.org/software/emacs/manual/html_node/elisp/Intro-Eval.html

Re: [External] : Re: Question about eval and compile-command

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
>  Eshel Yaron <me@eshelyaron.com>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 3 Aug 2023 21:35:39 +0000
> 
> > > In retrospect, shouldn't the type be be a string or a function?
> > 
> > Not a function, but a form.
> 
> A string is a form too...

Methodologically, it is not good to rely on this, because many Emacs
users will not realize that.  We never use "form" when we talk about
strings, for that very reason.

Using mathematical rigor when writing software documentation is almost
never a good idea, in practice.

Re: [External] : Re: Question about eval and compile-command

[Andreas Schwab]

On Aug 03 2023, Drew Adams wrote:

>> > In retrospect, shouldn't the type be be a string or a function?
>> 
>> Not a function, but a form.
>
> A string is a form too...

But a function does not evaluate to a string.

-- 
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."

Re: [External] : Re: Question about eval and compile-command

[Philip Kaludercic]

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

> On Aug 03 2023, Drew Adams wrote:
>
>>> > In retrospect, shouldn't the type be be a string or a function?
>>> 
>>> Not a function, but a form.
>>
>> A string is a form too...
>
> But a function does not evaluate to a string.

I'll rephrase my comment to avoid confusion: "Instead of any accepting a
string, or any form (both of which are evaluated, which is not an issue
due to the fact that evaluation of strings is idempotent), it seems like
it would have been better if the expected type of `compile-command' were
either a string, that would be interpreted without any further
processing, or a function, that would be funcalled with the expectation
that it would return a string, which would be taken to be the compile
command."