Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Stefan Monnier]

>     * lisp/emacs-lisp/eieio-core.el: Confine `cl-declaim' calls to compile
>     time.
[...]
> -  (cl-declaim (optimize (safety 0)))
> +  (eval-when-compile (cl-declaim (optimize (safety 0))))
 
I'd argue that cl-declaim should have no effect when interpreted, just
like (defvar foo).  At least, that's how I understand the difference
between CommonLisp proclaim and declaim.


        Stefan

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Noam Postavsky]

On Sat, Jun 24, 2017 at 10:26 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>     * lisp/emacs-lisp/eieio-core.el: Confine `cl-declaim' calls to compile
>>     time.
> [...]
>> -  (cl-declaim (optimize (safety 0)))
>> +  (eval-when-compile (cl-declaim (optimize (safety 0))))
>
> I'd argue that cl-declaim should have no effect when interpreted, just
> like (defvar foo).  At least, that's how I understand the difference
> between CommonLisp proclaim and declaim.

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node104.html (bottom of
page) says:

    declaim {decl-spec}*

    This macro is syntactically like declare and semantically like
    proclaim. It is an executable form and may be used anywhere
    proclaim may be called. However, each decl-spec is not evaluated.

    If a call to this macro appears at top level in a file being
    processed by the file compiler, the proclamations are also made at
    compile time.

Which suggests that declaim's effects are a superset of proclaim's
effects. But then it also says

    As with other defining macros, it is unspecified whether or not
    the compile-time side effects of a declaim persist after the file
    has been compiled

So I guess we could drop the effects at runtime?

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Stefan Monnier]

> Which suggests that declaim's effects are a superset of proclaim's
> effects. But then it also says
[...]
> So I guess we could drop the effects at runtime?

I agree that it's not really clear, but when you look at the doc of
proclaim and compare it to that of declaim it seems clear what is the
intention: one is meant to be "runtime only" (which is why it evaluates
its argument and is just a normal function) while the other is designed
such that it can be used at compile-time and only affects the
compilation of the current file (although the doc allows the
implementation to be less careful and let the effect "leak").


        Stefan

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Noam Postavsky]

On Sun, Jun 25, 2017 at 3:34 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> I agree that it's not really clear, but when you look at the doc of
> proclaim and compare it to that of declaim it seems clear what is the
> intention: one is meant to be "runtime only" (which is why it evaluates
> its argument and is just a normal function) while the other is designed
> such that it can be used at compile-time and only affects the
> compilation of the current file (although the doc allows the
> implementation to be less careful and let the effect "leak").

Sounds reasonable, so should it be just this?

(defmacro cl-declaim (&rest specs)
  "Like `cl-proclaim', but takes any number of unevaluated, unquoted arguments.
Furthermore, the declarations are registered at compile-time."
  (mapc #'cl-proclaim spec))

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Stefan Monnier]

> Sounds reasonable, so should it be just this?

> (defmacro cl-declaim (&rest specs)
>   "Like `cl-proclaim', but takes any number of unevaluated, unquoted arguments.
> Furthermore, the declarations are registered at compile-time."
>   (mapc #'cl-proclaim spec))

Ideally, we'd want to retract those things when we're done compiling the
current file, but I think the above is an improvement over the current
implementation, yes.


        Stefan

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Johan Bockgård]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Which suggests that declaim's effects are a superset of proclaim's
>> effects. But then it also says
> [...]
>> So I guess we could drop the effects at runtime?
>
> I agree that it's not really clear, but when you look at the doc of
> proclaim and compare it to that of declaim it seems clear what is the
> intention: one is meant to be "runtime only" (which is why it evaluates
> its argument and is just a normal function) while the other is designed
> such that it can be used at compile-time and only affects the
> compilation of the current file (although the doc allows the
> implementation to be less careful and let the effect "leak").

This is wrong. declaim has run-time effects, just like defvar etc. The
compile-time side effect is that it ALSO affects the compilation of the
remainder of the current file.

http://www.lispworks.com/documentation/HyperSpec/Body/03_bcaa.htm

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Noam Postavsky]

On Thu, Jun 29, 2017 at 3:25 PM, Johan Bockgård <bojohan@gnu.org> wrote:

> This is wrong. declaim has run-time effects, just like defvar etc. The
> compile-time side effect is that it ALSO affects the compilation of the
> remainder of the current file.
>
> http://www.lispworks.com/documentation/HyperSpec/Body/03_bcaa.htm

So you don't think this statement allows to omit run-time effects?

    It is not specified whether definitions made available in the
    compilation environment are available in the evaluation
    environment, nor is it specified whether they are available in
    subsequent compilation units or subsequent invocations of the
    compiler.

PS my earlier definition of cl-declaim had 2 bugs in it, I should have written

(defmacro cl-declaim (&rest specs)
  "Like `cl-proclaim', but takes any number of unevaluated, unquoted arguments.
Furthermore the declarations are registered at compile-time."
  (mapc #'cl-proclaim specs)
  nil)

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Johan Bockgård]

Noam Postavsky <npostavs@gmail.com> writes:

> On Thu, Jun 29, 2017 at 3:25 PM, Johan Bockgård <bojohan@gnu.org> wrote:
>
>> This is wrong. declaim has run-time effects, just like defvar etc. The
>> compile-time side effect is that it ALSO affects the compilation of the
>> remainder of the current file.
>>
>> http://www.lispworks.com/documentation/HyperSpec/Body/03_bcaa.htm
>
> So you don't think this statement allows to omit run-time effects?
>
>     It is not specified whether definitions made available in the
>     compilation environment are available in the evaluation
>     environment, nor is it specified whether they are available in
>     subsequent compilation units or subsequent invocations of the
>     compiler.

No, evaluation environment != run-time environment.(*)

The Hyperspec says that:

1. [declaim should] make definitions available both in the compilation
   and run-time environments.
2. It is not specified whether definitions [...]
   a) are available in the evaluation environment,
   b) in subsequent compilation units or subsequent invocations of the
      compiler.
3. compile-time side effects happen only [..] at top level.


(*) evaluation environment n. a [kind of] run-time environment in which
    macro expanders and code specified by eval-when to be evaluated are
    evaluated. All evaluations initiated by the compiler take place in
    the evaluation environment.

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Stefan Monnier]

> The Hyperspec says that:
>
> 1. [declaim should] make definitions available both in the compilation
>    and run-time environments.

Hmm... the uses of declaim that I'm familiar with are optimization
settings for the compiler.  These don't "make definitions available"
AFAICT.  If foo.el contains a declaim to set the optimization level,
I don't see why it would make sense for this setting to affect all files
compiled after foo.elc was loaded (I can understand that the spec may
allow such a suboptimal behavior, but not that it would require it).


        Stefan

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Johan Bockgård]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> The Hyperspec says that:
>>
>> 1. [declaim should] make definitions available both in the compilation
>>    and run-time environments.
>
> Hmm... the uses of declaim that I'm familiar with are optimization
> settings for the compiler.  These don't "make definitions available"
> AFAICT.  If foo.el contains a declaim to set the optimization level,
> I don't see why it would make sense for this setting to affect all files
> compiled after foo.elc was loaded (I can understand that the spec may
> allow such a suboptimal behavior, but not that it would require it).

In CL declaim can be used to make variables special. (In fact, `special'
is the only declaration that must have an effect in all conforming CL
implementations.)

Also see

https://groups.google.com/forum/#!original/comp.lang.lisp/rO1Vru1fbvI/-3FkSBvlE0gJ

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Stefan Monnier]

> In CL declaim can be used to make variables special. (In fact, `special'
> is the only declaration that must have an effect in all conforming CL
> implementations.)

Right, AFAIK it's largely equivalent to Elisp's (defvar foo).

not sure how it works in CL, but in Elisp, if a file foo.el has

    (defvar foo)
    ...

then `foo` will be treated as dynamically bound in foo.el when the
compiler generate the code for foo.elc.
But loading foo.elc, won't mark `foo` as dynamically bound, so in

    (require 'foo)
    (defun bar (x)
      (let ((foo x))
        (lambda (y) (+ foo y))))

the function `bar` should treat its `foo` binding lexically.


        Stefan


PS: Note I'm really talking about (defvar foo) and not (defvar foo blabla)

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Johan Bockgård]

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

>> In CL declaim can be used to make variables special. (In fact, `special'
>> is the only declaration that must have an effect in all conforming CL
>> implementations.)
>
> Right, AFAIK it's largely equivalent to Elisp's (defvar foo).
>
> not sure how it works in CL

`proclaim' makes "global declarations", aka "proclamations". `declaim'
is like `proclaim' but also has compile-time effects.

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Stefan Monnier]

>>> In CL declaim can be used to make variables special. (In fact, `special'
>>> is the only declaration that must have an effect in all conforming CL
>>> implementations.)
>> Right, AFAIK it's largely equivalent to Elisp's (defvar foo).
>> not sure how it works in CL

> `proclaim' makes "global declarations", aka "proclamations". `declaim'
> is like `proclaim' but also has compile-time effects.

That description is sufficiently broad that it accepts both your
interpretation and mine.


        Stefan

Re: [Emacs-diffs] master c75eb10: Don't change byte-compile-delete-errors at runtime (Bug#27340)

[Stefan Monnier]

> This is wrong. declaim has run-time effects, just like defvar etc.

If you put (defvar foo) in foo.el, then compile it, then load foo.elc,
you'll see that this defvar has no runtime effect.

I think cl-declaim should basically behave the same: it holds
compilation directives which should basically only influence the
compilation of the current file.


        Stefan