unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Introducing 'safety' compilation parameter
@ 2024-05-07 10:37 Andrea Corallo
  2024-05-07 12:01 ` Alan Mackenzie
                   ` (3 more replies)
  0 siblings, 4 replies; 33+ messages in thread
From: Andrea Corallo @ 2024-05-07 10:37 UTC (permalink / raw)
  To: emacs-devel; +Cc: Eli Zaretskii, monnier, mattias.engdegard, stefankangas

Hello,

I've put in scratch/comp-safety a branch wich introduces 'safety' as
compilation parameter.

'safety' can be used similarly to 'native-comp-speed' both as a global
variable to influence compilation both as a function declaration.

'safety' justification of existence is ATM being able to control the
undefined behaviour being created when function type declaration added
by the user is not correct.

ATM we can have two values:

1 Emitted code is generated in a safe matter even if function types are
miss-declared.
0 Emitted code can misbehave or crash Emacs if function declarations are
not correct and the function is native compiled (@pxref{Native
Compilation}).

1 is ATM the default.

I didn't want to give safety a prefix (byte- or comp-) as I believe we
should extend safety in the future with a value to have the byte
compiler generates runtime type checks to verify the declred types.
OTOH this is creating a warning for a missing prefix, not sure what's
the best way to fix this (give it a prefix or silence the compiler if
possible).

Also I added some doc for the declaration, but didn't kwnow where in the
manual the documention for the variable should go as now it has effect
only for the native compiler.  Should I document it under
"Native-Compilation Variables" for now?

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 10:37 Introducing 'safety' compilation parameter Andrea Corallo
@ 2024-05-07 12:01 ` Alan Mackenzie
  2024-05-07 13:15   ` Eli Zaretskii
                     ` (2 more replies)
  2024-05-07 14:56 ` Stefan Monnier
                   ` (2 subsequent siblings)
  3 siblings, 3 replies; 33+ messages in thread
From: Alan Mackenzie @ 2024-05-07 12:01 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: emacs-devel, Eli Zaretskii, monnier, mattias.engdegard,
	stefankangas

Hello, Andrea.

On Tue, May 07, 2024 at 06:37:50 -0400, Andrea Corallo wrote:
> Hello,

> I've put in scratch/comp-safety a branch which introduces 'safety' as
> compilation parameter.

I'm against this; see below.

> 'safety' can be used similarly to 'native-comp-speed' both as a global
> variable to influence compilation both as a function declaration.

> 'safety' justification of existence is ATM being able to control the
> undefined behaviour being created when function type declaration added
> by the user is not correct.

How is this undefined behaviour?  Lisp is a dynamically typed language.
If a function type declaration is added, this can only be advisory.  If
it is incorrect, then by the specification of (Emacs) Lisp, the code
generated must still correctly handle its arguments and run.

> ATM we can have two values:

> 1 Emitted code is generated in a safe matter even if function types are
> miss-declared.

I'm in favour of this remaining.

> 0 Emitted code can misbehave or crash Emacs if function declarations are
> not correct and the function is native compiled (@pxref{Native
> Compilation}).

I'm in favour of this not being merged.  Crashing Emacs for valid (or
even invalid) Lisp should not be an option.

> 1 is ATM the default.

I see this change as one more boil-the-frog-slowly step towards turning
Emacs Lisp into a statically typed language.  If this change gets merged
into master, how long will it be until these function declarations
become first common, then usual, then all but universal?  It that were
to happen, it would be, in my opinion, a net loss to Emacs.

Why do we need this change at all?  It may generate somewhat faster (or
smaller) code, but isn't native compiled Lisp already fast enough,
particularly on a modern machine?

> I didn't want to give safety a prefix (byte- or comp-) as I believe we
> should extend safety in the future with a value to have the byte
> compiler generates runtime type checks to verify the declred types.
> OTOH this is creating a warning for a missing prefix, not sure what's
> the best way to fix this (give it a prefix or silence the compiler if
> possible).

> Also I added some doc for the declaration, but didn't kwnow where in the
> manual the documention for the variable should go as now it has effect
> only for the native compiler.  Should I document it under
> "Native-Compilation Variables" for now?

> Thanks

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 12:01 ` Alan Mackenzie
@ 2024-05-07 13:15   ` Eli Zaretskii
  2024-05-07 16:07     ` Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] Alan Mackenzie
  2024-05-07 16:37   ` Introducing 'safety' compilation parameter Tomas Hlavaty
  2024-05-07 16:54   ` Andrea Corallo
  2 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-07 13:15 UTC (permalink / raw)
  To: Alan Mackenzie
  Cc: acorallo, emacs-devel, monnier, mattias.engdegard, stefankangas

> Date: Tue, 7 May 2024 12:01:33 +0000
> Cc: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>,
>   monnier@iro.umontreal.ca, mattias.engdegard@gmail.com,
>   stefankangas@gmail.com
> From: Alan Mackenzie <acm@muc.de>
> 
> I see this change as one more boil-the-frog-slowly step towards turning
> Emacs Lisp into a statically typed language.

Alan, please be kinder, even if you dislike very much suggestions of
others.  The above could have been easily rephrased as

  Emacs Lisp should not be turned into a statically typed language.

without losing any useful content, including your strenuous objection
to the change.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 10:37 Introducing 'safety' compilation parameter Andrea Corallo
  2024-05-07 12:01 ` Alan Mackenzie
@ 2024-05-07 14:56 ` Stefan Monnier
  2024-05-07 16:13   ` Andrea Corallo
  2024-05-09  8:40 ` Eli Zaretskii
  2024-05-09  9:19 ` Gerd Möllmann
  3 siblings, 1 reply; 33+ messages in thread
From: Stefan Monnier @ 2024-05-07 14:56 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: emacs-devel, Eli Zaretskii, mattias.engdegard, stefankangas

> I didn't want to give safety a prefix (byte- or comp-) as I believe we
> should extend safety in the future with a value to have the byte
> compiler generates runtime type checks to verify the declred types.

I don't see a strong need for a namespace prefix, but I think "safety"
is too general a term.  It could be understood to apply also to
unrelated circumstances such as process confinement or disclosure of
sensitive info over a network connection.
Maybe `elisp-safety` or `compilation-safety`?

If I read your patch correctly, we get safety in a roundabout way:
rather than test the safety setting at the spot where we decide to apply
(or not) a dangerous optimization, we use the safety setting to
"mollify" the type annotations (presumably because this will in turn
make the risky optimizations inapplicable).

What is the reason for that?


        Stefan




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Drifting towards a statically typed Emacs Lisp.  [Was: Introducing 'safety' compilation parameter]
  2024-05-07 13:15   ` Eli Zaretskii
@ 2024-05-07 16:07     ` Alan Mackenzie
  2024-05-07 17:06       ` Andrea Corallo
                         ` (3 more replies)
  0 siblings, 4 replies; 33+ messages in thread
From: Alan Mackenzie @ 2024-05-07 16:07 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: acorallo, emacs-devel, monnier, mattias.engdegard, stefankangas

Hello, Eli.

On Tue, May 07, 2024 at 16:15:47 +0300, Eli Zaretskii wrote:
> > Date: Tue, 7 May 2024 12:01:33 +0000
> > Cc: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>,
> >   monnier@iro.umontreal.ca, mattias.engdegard@gmail.com,
> >   stefankangas@gmail.com
> > From: Alan Mackenzie <acm@muc.de>

> > I see this change as one more boil-the-frog-slowly step towards turning
> > Emacs Lisp into a statically typed language.

> Alan, please be kinder, even if you dislike very much suggestions of
> others.

No offence was intended.

> The above could have been easily rephrased as

>   Emacs Lisp should not be turned into a statically typed language.

> without losing any useful content, ....

Not really - what would have been lost is the equivalent  of ".... and I
see this process happening at the moment.".  The frog metaphor was an
economical way of phrasing this.  Again, I'm sorry it caused offence.

> .... including your strenuous objection to the change.

I see Emacs Lisp steadily drifting towards being statically typed, and I
don't think that's a good thing.  As far as I'm aware, there has been no
general agreement amongst Emacs developers for this (unless it's
happened as a side-thread in some thread without having an accurate
Subject:).

We currently have the prospect of lots of functions being cluttered up
with "type" declarations.  We already have meaningless (to a Lisp
programmer) things like:

    Inferred type: (function (&optional t t) t)                                                                            

appearing in prominent positions in doc strings.  Why?

If this is the way Emacs Lisp is to develop, can't we at least have an
open discussion about it and a positive decision taken, rather than
letting it "just happen"?  As is already clear, I see static typing in
Emacs Lisp, except, perhaps, on a very limited scale, as a Bad Thing.

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 14:56 ` Stefan Monnier
@ 2024-05-07 16:13   ` Andrea Corallo
  2024-05-10 17:58     ` Andrea Corallo
  0 siblings, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-07 16:13 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: emacs-devel, Eli Zaretskii, mattias.engdegard, stefankangas

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

>> I didn't want to give safety a prefix (byte- or comp-) as I believe we
>> should extend safety in the future with a value to have the byte
>> compiler generates runtime type checks to verify the declred types.
>
> I don't see a strong need for a namespace prefix, but I think "safety"
> is too general a term.  It could be understood to apply also to
> unrelated circumstances such as process confinement or disclosure of
> sensitive info over a network connection.
> Maybe `elisp-safety` or `compilation-safety`?

Agree, boths SGTM, maaaybe I slightly prefer 'compilation-safety'.

> If I read your patch correctly, we get safety in a roundabout way:
> rather than test the safety setting at the spot where we decide to apply
> (or not) a dangerous optimization, we use the safety setting to
> "mollify" the type annotations (presumably because this will in turn
> make the risky optimizations inapplicable).
>
> What is the reason for that?

No specific reason, I think I thought was safer to write the patch with
way gating optimization at this (higher) level.  Thinking about now that
you raised the point, is probably easy to gate the single optimizations
as well.  Why not, I think I'll update the patch this way.

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 12:01 ` Alan Mackenzie
  2024-05-07 13:15   ` Eli Zaretskii
@ 2024-05-07 16:37   ` Tomas Hlavaty
  2024-05-07 16:54   ` Andrea Corallo
  2 siblings, 0 replies; 33+ messages in thread
From: Tomas Hlavaty @ 2024-05-07 16:37 UTC (permalink / raw)
  To: Alan Mackenzie, Andrea Corallo
  Cc: emacs-devel, Eli Zaretskii, monnier, mattias.engdegard,
	stefankangas

On Tue 07 May 2024 at 12:01, Alan Mackenzie <acm@muc.de> wrote:
> turning
> Emacs Lisp into a statically typed language.  If this change gets merged
> into master, how long will it be until these function declarations
> become first common, then usual, then all but universal?  It that were
> to happen, it would be, in my opinion, a net loss to Emacs.

this looks like the plan:

     id:86sf0q5l0v.fsf@gnu.org
     Eli Zaretskii <eliz@gnu.org> (March 16)
     Subject: Re: Declaring Lisp function types
     To: Tomas Hlavaty <tom@logand.com>
     Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
     Date: Sat, 16 Mar 2024 16:06:08 +0200

     [...]
     By contrast, _every_ function will have some type and some
     signature,
     so you will have a gazillion of hits if you search for those,
     no
     matter what its name.
     [...]



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 12:01 ` Alan Mackenzie
  2024-05-07 13:15   ` Eli Zaretskii
  2024-05-07 16:37   ` Introducing 'safety' compilation parameter Tomas Hlavaty
@ 2024-05-07 16:54   ` Andrea Corallo
  2024-05-07 23:42     ` Emanuel Berg
  2 siblings, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-07 16:54 UTC (permalink / raw)
  To: Alan Mackenzie
  Cc: emacs-devel, Eli Zaretskii, monnier, mattias.engdegard,
	stefankangas

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.
>
> On Tue, May 07, 2024 at 06:37:50 -0400, Andrea Corallo wrote:
>> Hello,
>
>> I've put in scratch/comp-safety a branch which introduces 'safety' as
>> compilation parameter.
>
> I'm against this; see below.
>
>> 'safety' can be used similarly to 'native-comp-speed' both as a global
>> variable to influence compilation both as a function declaration.
>
>> 'safety' justification of existence is ATM being able to control the
>> undefined behaviour being created when function type declaration added
>> by the user is not correct.
>
> How is this undefined behaviour?  Lisp is a dynamically typed language.
> If a function type declaration is added, this can only be advisory.  If
> it is incorrect, then by the specification of (Emacs) Lisp, the code
> generated must still correctly handle its arguments and run.
>
>> ATM we can have two values:
>
>> 1 Emitted code is generated in a safe matter even if function types are
>> miss-declared.
>
> I'm in favour of this remaining.
>
>> 0 Emitted code can misbehave or crash Emacs if function declarations are
>> not correct and the function is native compiled (@pxref{Native
>> Compilation}).
>
> I'm in favour of this not being merged.  Crashing Emacs for valid (or
> even invalid) Lisp should not be an option.
>
>> 1 is ATM the default.
>
> I see this change as one more boil-the-frog-slowly step towards turning
> Emacs Lisp into a statically typed language.  If this change gets merged
> into master, how long will it be until these function declarations
> become first common, then usual, then all but universal?  It that were
> to happen, it would be, in my opinion, a net loss to Emacs.

Hi Alan,

I'm sorry I was not clear presenting this patch.  The scope of this is
not to introduce UB but actually to *remove* it.

Anyway your concern of having in few years code full of type declaration
declaration is IMO just not realistic.  Common Lisp has function type
declarations since forever and type declared functions are very rare in
CL codebases.

This is a tool that can be useful for specific usages and not for the
general case.

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Drifting towards a statically typed Emacs Lisp.  [Was: Introducing 'safety' compilation parameter]
  2024-05-07 16:07     ` Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] Alan Mackenzie
@ 2024-05-07 17:06       ` Andrea Corallo
  2024-05-07 23:37         ` Emanuel Berg
  2024-05-07 18:00       ` Eli Zaretskii
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-07 17:06 UTC (permalink / raw)
  To: Alan Mackenzie
  Cc: Eli Zaretskii, emacs-devel, monnier, mattias.engdegard,
	stefankangas

Alan Mackenzie <acm@muc.de> writes:

> Hello, Eli.
>
> On Tue, May 07, 2024 at 16:15:47 +0300, Eli Zaretskii wrote:
>> > Date: Tue, 7 May 2024 12:01:33 +0000
>> > Cc: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>,
>> >   monnier@iro.umontreal.ca, mattias.engdegard@gmail.com,
>> >   stefankangas@gmail.com
>> > From: Alan Mackenzie <acm@muc.de>
>
>> > I see this change as one more boil-the-frog-slowly step towards turning
>> > Emacs Lisp into a statically typed language.
>
>> Alan, please be kinder, even if you dislike very much suggestions of
>> others.
>
> No offence was intended.
>
>> The above could have been easily rephrased as
>
>>   Emacs Lisp should not be turned into a statically typed language.
>
>> without losing any useful content, ....
>
> Not really - what would have been lost is the equivalent  of ".... and I
> see this process happening at the moment.".  The frog metaphor was an
> economical way of phrasing this.  Again, I'm sorry it caused offence.
>
>> .... including your strenuous objection to the change.
>
> I see Emacs Lisp steadily drifting towards being statically typed, and I
> don't think that's a good thing.  As far as I'm aware, there has been no
> general agreement amongst Emacs developers for this (unless it's
> happened as a side-thread in some thread without having an accurate
> Subject:).
>
> We currently have the prospect of lots of functions being cluttered up
> with "type" declarations.  We already have meaningless (to a Lisp
> programmer) things like:
>
>     Inferred type: (function (&optional t t) t)                                                                            
>
> appearing in prominent positions in doc strings.  Why?

Because it can be informative (when there are types other than t),
anyway you can control it with 'help-display-function-type' if you don't
want to have it in the *Help* buffer.

> If this is the way Emacs Lisp is to develop, can't we at least have an
> open discussion about it and a positive decision taken, rather than
> letting it "just happen"?  As is already clear, I see static typing in
> Emacs Lisp, except, perhaps, on a very limited scale, as a Bad Thing.

Again, there's no plan to make elisp statically typed.  I agree with you
this is a tool to be used on a limited scale, if this is not clear
enough from the doc now I guess we can just improve it.

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter]
  2024-05-07 16:07     ` Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] Alan Mackenzie
  2024-05-07 17:06       ` Andrea Corallo
@ 2024-05-07 18:00       ` Eli Zaretskii
  2024-05-08  0:14         ` Emanuel Berg
  2024-05-07 23:29       ` Emanuel Berg
  2024-05-09 23:52       ` Richard Stallman
  3 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-07 18:00 UTC (permalink / raw)
  To: Alan Mackenzie
  Cc: acorallo, emacs-devel, monnier, mattias.engdegard, stefankangas

> Date: Tue, 7 May 2024 16:07:58 +0000
> Cc: acorallo@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>   mattias.engdegard@gmail.com, stefankangas@gmail.com
> From: Alan Mackenzie <acm@muc.de>
> 
> > > I see this change as one more boil-the-frog-slowly step towards turning
> > > Emacs Lisp into a statically typed language.
> 
> > Alan, please be kinder, even if you dislike very much suggestions of
> > others.
> 
> No offence was intended.

Suggest to re-read what you are going to send, with an eye towards
stuff that doesn't help you make your point, only to vent anger, and
delete any of that.

> If this is the way Emacs Lisp is to develop, can't we at least have an
> open discussion about it and a positive decision taken, rather than
> letting it "just happen"?

We are discussing each of these changes, so the opportunity for
raising a broader issues already exists, and you and others are
welcome to voice their opinions.  It isn't like Andrea is doing this
without any discussions or without incorporating all the comments and
suggestions that people come up with.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter]
  2024-05-07 16:07     ` Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] Alan Mackenzie
  2024-05-07 17:06       ` Andrea Corallo
  2024-05-07 18:00       ` Eli Zaretskii
@ 2024-05-07 23:29       ` Emanuel Berg
  2024-05-09 23:52       ` Richard Stallman
  3 siblings, 0 replies; 33+ messages in thread
From: Emanuel Berg @ 2024-05-07 23:29 UTC (permalink / raw)
  To: emacs-devel

Alan Mackenzie wrote:

> We currently have the prospect of lots of functions being
> cluttered up with "type" declarations. We already have
> meaningless (to a Lisp programmer) things like:
>
>     Inferred type: (function (&optional t t) t)
>
> appearing in prominent positions in doc strings. Why?

In the help, not doc strings, but you know that.

Anyway I have this to reduce the verbosity of the help, maybe
the same can be set up/used for the inferred type note for
people who don't like it to show up?

(setq help-fns-describe-variable-functions
  (cl-set-difference help-fns-describe-variable-functions
    '(help-fns--customize-variable
      help-fns--customize-variable-version
      help-fns--mention-first-release
      help-fns--var-file-local
      help-fns--var-ignored-local
      help-fns--var-risky
      help-fns--var-safe-local) ))

> If this is the way Emacs Lisp is to develop, can't we at
> least have an open discussion about it and a positive
> decision taken, rather than letting it "just happen"? As is
> already clear, I see static typing in Emacs Lisp, except,
> perhaps, on a very limited scale, as a Bad Thing.

Maybe we can have both and then everyone could use it if and
where they wanted, and we would see if and to what extent it
would be used and what implications it would have, while still
being optional.

Maybe in some areas it would be used more often?

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter]
  2024-05-07 17:06       ` Andrea Corallo
@ 2024-05-07 23:37         ` Emanuel Berg
  0 siblings, 0 replies; 33+ messages in thread
From: Emanuel Berg @ 2024-05-07 23:37 UTC (permalink / raw)
  To: emacs-devel

Andrea Corallo wrote:

> Because it can be informative (when there are types other
> than t), anyway you can control it with
> 'help-display-function-type' if you don't want to have it in
> the *Help* buffer.

Ah, so you already added what I asked for/suggested in my
other post. Okay good, all the better then.

>> If this is the way Emacs Lisp is to develop, can't we at
>> least have an open discussion about it and a positive
>> decision taken, rather than letting it "just happen"? As is
>> already clear, I see static typing in Emacs Lisp, except,
>> perhaps, on a very limited scale, as a Bad Thing.
>
> Again, there's no plan to make elisp statically typed.
> I agree with you this is a tool to be used on a limited
> scale, if this is not clear enough from the doc now I guess
> we can just improve it.

I think it is cool with the inferred type system, as well as
the possibility to have explicit types for functions,
arguments, etc, in source.

Those types could be used in many different ways at compile as
well as run time, that doesn't mean we must "make Elisp
statically typed".

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 16:54   ` Andrea Corallo
@ 2024-05-07 23:42     ` Emanuel Berg
  0 siblings, 0 replies; 33+ messages in thread
From: Emanuel Berg @ 2024-05-07 23:42 UTC (permalink / raw)
  To: emacs-devel

Andrea Corallo wrote:

> Anyway your concern of having in few years code full of type
> declaration declaration is IMO just not realistic.
> Common Lisp has function type declarations since forever and
> type declared functions are very rare in CL codebases.
>
> This is a tool that can be useful for specific usages and
> not for the general case.

Very much so, it will also be interesting to see what specific
usages those will be!

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter]
  2024-05-07 18:00       ` Eli Zaretskii
@ 2024-05-08  0:14         ` Emanuel Berg
  0 siblings, 0 replies; 33+ messages in thread
From: Emanuel Berg @ 2024-05-08  0:14 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii wrote:

>>> Alan, please be kinder, even if you dislike very much
>>> suggestions of others.
>> 
>> No offence was intended.
>
> Suggest to re-read what you are going to send, with an eye
> towards stuff that doesn't help you make your point, only to
> vent anger, and delete any of that.

No one has been angry in this thread so far, but if we keep up
the meta discussion that can change for that very reason.

-- 
underground experts united
https://dataswamp.org/~incal




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 10:37 Introducing 'safety' compilation parameter Andrea Corallo
  2024-05-07 12:01 ` Alan Mackenzie
  2024-05-07 14:56 ` Stefan Monnier
@ 2024-05-09  8:40 ` Eli Zaretskii
  2024-05-10  7:47   ` Andrea Corallo
  2024-05-10 18:02   ` Andrea Corallo
  2024-05-09  9:19 ` Gerd Möllmann
  3 siblings, 2 replies; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-09  8:40 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: emacs-devel, monnier, mattias.engdegard, stefankangas

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>  mattias.engdegard@gmail.com, stefankangas@gmail.com
> Date: Tue, 07 May 2024 06:37:50 -0400
> 
> I've put in scratch/comp-safety a branch wich introduces 'safety' as
> compilation parameter.
> 
> 'safety' can be used similarly to 'native-comp-speed' both as a global
> variable to influence compilation both as a function declaration.
> 
> 'safety' justification of existence is ATM being able to control the
> undefined behaviour being created when function type declaration added
> by the user is not correct.
> 
> ATM we can have two values:
> 
> 1 Emitted code is generated in a safe matter even if function types are
> miss-declared.
> 0 Emitted code can misbehave or crash Emacs if function declarations are
> not correct and the function is native compiled (@pxref{Native
> Compilation}).
> 
> 1 is ATM the default.

Is this for Emacs 30 or Emacs 31?

If the former, we should conclude this discussion soon enough.

I don't have an opinion about the utility of this for Emacs Lisp, but
this part of the documentation:

> +Possible values are:
> +
> +0 Emitted code can misbehave or crash Emacs if function declarations are
> +not correct and the function is native compiled (@pxref{Native
> +Compilation}).
> +
> +1 Emitted code is generated in a safe matter even if function are
> +miss-declared."

should be formatted as a @table.

> Also I added some doc for the declaration, but didn't kwnow where in the
> manual the documention for the variable should go as now it has effect
> only for the native compiler.  Should I document it under
> "Native-Compilation Variables" for now?

Yes, I think so.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 10:37 Introducing 'safety' compilation parameter Andrea Corallo
                   ` (2 preceding siblings ...)
  2024-05-09  8:40 ` Eli Zaretskii
@ 2024-05-09  9:19 ` Gerd Möllmann
  2024-05-10  7:58   ` Andrea Corallo
  3 siblings, 1 reply; 33+ messages in thread
From: Gerd Möllmann @ 2024-05-09  9:19 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: emacs-devel, Eli Zaretskii, monnier, mattias.engdegard,
	stefankangas

Andrea Corallo <acorallo@gnu.org> writes:

> I've put in scratch/comp-safety a branch wich introduces 'safety' as
> compilation parameter.
>
> 'safety' can be used similarly to 'native-comp-speed' both as a global
> variable to influence compilation both as a function declaration.
>
> 'safety' justification of existence is ATM being able to control the
> undefined behaviour being created when function type declaration added
> by the user is not correct.
>
> ATM we can have two values:
>
> 1 Emitted code is generated in a safe matter even if function types are
> miss-declared.
> 0 Emitted code can misbehave or crash Emacs if function declarations are
> not correct and the function is native compiled (@pxref{Native
> Compilation}).
>
> 1 is ATM the default.
>
> I didn't want to give safety a prefix (byte- or comp-) as I believe we
> should extend safety in the future with a value to have the byte
> compiler generates runtime type checks to verify the declred types.
> OTOH this is creating a warning for a missing prefix, not sure what's
> the best way to fix this (give it a prefix or silence the compiler if
> possible).
>
> Also I added some doc for the declaration, but didn't kwnow where in the
> manual the documention for the variable should go as now it has effect
> only for the native compiler.  Should I document it under
> "Native-Compilation Variables" for now?

Hi Andrea,

I don't know if something like this has been discussed before... CMUCL
and SBCL treat declarations differently depending on the speed settings.
If speed is below some threshold, declarations work like assertions,
with high speed settings declarations are treated as promises.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter]
  2024-05-07 16:07     ` Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] Alan Mackenzie
                         ` (2 preceding siblings ...)
  2024-05-07 23:29       ` Emanuel Berg
@ 2024-05-09 23:52       ` Richard Stallman
  2024-05-10  6:31         ` Eli Zaretskii
  3 siblings, 1 reply; 33+ messages in thread
From: Richard Stallman @ 2024-05-09 23:52 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   Emacs Lisp should not be turned into a statically typed language.

  > > without losing any useful content, ....

  > Not really - what would have been lost is the equivalent  of ".... and I
  > see this process happening at the moment.".  The frog metaphor was an
  > economical way of phrasing this.  Again, I'm sorry it caused offence.

I worry about this too.

This is not the first time that Lisp compilation has inspired adding
features to declare types of various values that apear inside Lisp
functions.  For instance, that happened with Maclisp in the 1970s.

That pressure is not necessarily overwhelming; it does not necessarily
pressure programmers to declare types in all their code.  When I wrote
Lisp code in the 1970s, I did not declare types.  I was not required
to do so.

But what worries e is that users who want the highest speed
will put pressure on all Emacs developers to add type declaratons
everywhere to give those users the highest possible speed.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter]
  2024-05-09 23:52       ` Richard Stallman
@ 2024-05-10  6:31         ` Eli Zaretskii
  0 siblings, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-10  6:31 UTC (permalink / raw)
  To: rms; +Cc: acm, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 09 May 2024 19:52:12 -0400
> 
> But what worries me is that users who want the highest speed
> will put pressure on all Emacs developers to add type declaratons
> everywhere to give those users the highest possible speed.

The onus will be on the Emacs maintainers to resist that pressure.  I
don't see how that pressure is any different from any other pressure
put on us about any other kind of changes.  It's part of our job to
deal with that, and deal correctly.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-09  8:40 ` Eli Zaretskii
@ 2024-05-10  7:47   ` Andrea Corallo
  2024-05-10 10:17     ` Eli Zaretskii
  2024-05-10 18:02   ` Andrea Corallo
  1 sibling, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-10  7:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, monnier, mattias.engdegard, stefankangas

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>>  mattias.engdegard@gmail.com, stefankangas@gmail.com
>> Date: Tue, 07 May 2024 06:37:50 -0400
>> 
>> I've put in scratch/comp-safety a branch wich introduces 'safety' as
>> compilation parameter.
>> 
>> 'safety' can be used similarly to 'native-comp-speed' both as a global
>> variable to influence compilation both as a function declaration.
>> 
>> 'safety' justification of existence is ATM being able to control the
>> undefined behaviour being created when function type declaration added
>> by the user is not correct.
>> 
>> ATM we can have two values:
>> 
>> 1 Emitted code is generated in a safe matter even if function types are
>> miss-declared.
>> 0 Emitted code can misbehave or crash Emacs if function declarations are
>> not correct and the function is native compiled (@pxref{Native
>> Compilation}).
>> 
>> 1 is ATM the default.
>
> Is this for Emacs 30 or Emacs 31?

Hi Eli,

the question is related to the patch or the defaul value?

> If the former, we should conclude this discussion soon enough.
>
> I don't have an opinion about the utility of this for Emacs Lisp, but
> this part of the documentation:
>
>> +Possible values are:
>> +
>> +0 Emitted code can misbehave or crash Emacs if function declarations are
>> +not correct and the function is native compiled (@pxref{Native
>> +Compilation}).
>> +
>> +1 Emitted code is generated in a safe matter even if function are
>> +miss-declared."
>
> should be formatted as a @table.

Thx will do.

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-09  9:19 ` Gerd Möllmann
@ 2024-05-10  7:58   ` Andrea Corallo
  2024-05-10  8:09     ` Gerd Möllmann
  2024-05-10 14:00     ` Stefan Monnier
  0 siblings, 2 replies; 33+ messages in thread
From: Andrea Corallo @ 2024-05-10  7:58 UTC (permalink / raw)
  To: Gerd Möllmann
  Cc: emacs-devel, Eli Zaretskii, monnier, mattias.engdegard,
	stefankangas

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> I've put in scratch/comp-safety a branch wich introduces 'safety' as
>> compilation parameter.
>>
>> 'safety' can be used similarly to 'native-comp-speed' both as a global
>> variable to influence compilation both as a function declaration.
>>
>> 'safety' justification of existence is ATM being able to control the
>> undefined behaviour being created when function type declaration added
>> by the user is not correct.
>>
>> ATM we can have two values:
>>
>> 1 Emitted code is generated in a safe matter even if function types are
>> miss-declared.
>> 0 Emitted code can misbehave or crash Emacs if function declarations are
>> not correct and the function is native compiled (@pxref{Native
>> Compilation}).
>>
>> 1 is ATM the default.
>>
>> I didn't want to give safety a prefix (byte- or comp-) as I believe we
>> should extend safety in the future with a value to have the byte
>> compiler generates runtime type checks to verify the declred types.
>> OTOH this is creating a warning for a missing prefix, not sure what's
>> the best way to fix this (give it a prefix or silence the compiler if
>> possible).
>>
>> Also I added some doc for the declaration, but didn't kwnow where in the
>> manual the documention for the variable should go as now it has effect
>> only for the native compiler.  Should I document it under
>> "Native-Compilation Variables" for now?
>
> Hi Andrea,
>
> I don't know if something like this has been discussed before... CMUCL
> and SBCL treat declarations differently depending on the speed settings.
> If speed is below some threshold, declarations work like assertions,
> with high speed settings declarations are treated as promises.

I though looking at [1] only 'safety' was involved in declarations
working like assertions.

After your hint I see now SBCL does that when:

(or (>=safety 2) (>= safety speed 1)) [2]

That's complex/confusing 🤯!  I think would be better to control that
only with 'safety' no?

Thanks

  Andrea


[1] <https://www.lispworks.com/documentation/lw61/CLHS/Body/d_optimi.htm>
[2] <https://www.sbcl.org/manual/#Declarations-as-Assertions>



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10  7:58   ` Andrea Corallo
@ 2024-05-10  8:09     ` Gerd Möllmann
  2024-05-10  8:19       ` Andrea Corallo
  2024-05-10 14:00     ` Stefan Monnier
  1 sibling, 1 reply; 33+ messages in thread
From: Gerd Möllmann @ 2024-05-10  8:09 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: emacs-devel, Eli Zaretskii, monnier, mattias.engdegard,
	stefankangas

Andrea Corallo <acorallo@gnu.org> writes:

>> I don't know if something like this has been discussed before... CMUCL
>> and SBCL treat declarations differently depending on the speed settings.
>> If speed is below some threshold, declarations work like assertions,
>> with high speed settings declarations are treated as promises.
>
> I though looking at [1] only 'safety' was involved in declarations
> working like assertions.
>
> After your hint I see now SBCL does that when:
>
> (or (>=safety 2) (>= safety speed 1)) [2]
>
> That's complex/confusing 🤯!  I think would be better to control that
> only with 'safety' no?

You could read it as "either I the programmer value safety very much, or
I value safety, and I value safety at least as much as speed".

Anyway, I just wanted to hint at the "declarations as
assertions/promises", and since you know about it, mission accomplished
:-).



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10  8:09     ` Gerd Möllmann
@ 2024-05-10  8:19       ` Andrea Corallo
  0 siblings, 0 replies; 33+ messages in thread
From: Andrea Corallo @ 2024-05-10  8:19 UTC (permalink / raw)
  To: Gerd Möllmann
  Cc: emacs-devel, Eli Zaretskii, monnier, mattias.engdegard,
	stefankangas

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> I don't know if something like this has been discussed before... CMUCL
>>> and SBCL treat declarations differently depending on the speed settings.
>>> If speed is below some threshold, declarations work like assertions,
>>> with high speed settings declarations are treated as promises.
>>
>> I though looking at [1] only 'safety' was involved in declarations
>> working like assertions.
>>
>> After your hint I see now SBCL does that when:
>>
>> (or (>=safety 2) (>= safety speed 1)) [2]
>>
>> That's complex/confusing 🤯!  I think would be better to control that
>> only with 'safety' no?
>
> You could read it as "either I the programmer value safety very much, or
> I value safety, and I value safety at least as much as speed".

Right, sounds much better in words actually! :)

> Anyway, I just wanted to hint at the "declarations as
> assertions/promises", and since you know about it, mission accomplished
> :-).

Thanks



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10  7:47   ` Andrea Corallo
@ 2024-05-10 10:17     ` Eli Zaretskii
  2024-05-10 11:42       ` Andrea Corallo
  0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-10 10:17 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: emacs-devel, monnier, mattias.engdegard, stefankangas

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,
>   mattias.engdegard@gmail.com,  stefankangas@gmail.com
> Date: Fri, 10 May 2024 03:47:53 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andrea Corallo <acorallo@gnu.org>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
> >>  mattias.engdegard@gmail.com, stefankangas@gmail.com
> >> Date: Tue, 07 May 2024 06:37:50 -0400
> >> 
> >> I've put in scratch/comp-safety a branch wich introduces 'safety' as
> >> compilation parameter.
> >> 
> >> 'safety' can be used similarly to 'native-comp-speed' both as a global
> >> variable to influence compilation both as a function declaration.
> >> 
> >> 'safety' justification of existence is ATM being able to control the
> >> undefined behaviour being created when function type declaration added
> >> by the user is not correct.
> >> 
> >> ATM we can have two values:
> >> 
> >> 1 Emitted code is generated in a safe matter even if function types are
> >> miss-declared.
> >> 0 Emitted code can misbehave or crash Emacs if function declarations are
> >> not correct and the function is native compiled (@pxref{Native
> >> Compilation}).
> >> 
> >> 1 is ATM the default.
> >
> > Is this for Emacs 30 or Emacs 31?
> 
> Hi Eli,
> 
> the question is related to the patch or the defaul value?

Both.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10 10:17     ` Eli Zaretskii
@ 2024-05-10 11:42       ` Andrea Corallo
  2024-05-10 15:10         ` Eli Zaretskii
  0 siblings, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-10 11:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, monnier, mattias.engdegard, stefankangas

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,
>>   mattias.engdegard@gmail.com,  stefankangas@gmail.com
>> Date: Fri, 10 May 2024 03:47:53 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Andrea Corallo <acorallo@gnu.org>
>> >> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>> >>  mattias.engdegard@gmail.com, stefankangas@gmail.com
>> >> Date: Tue, 07 May 2024 06:37:50 -0400
>> >> 
>> >> I've put in scratch/comp-safety a branch wich introduces 'safety' as
>> >> compilation parameter.
>> >> 
>> >> 'safety' can be used similarly to 'native-comp-speed' both as a global
>> >> variable to influence compilation both as a function declaration.
>> >> 
>> >> 'safety' justification of existence is ATM being able to control the
>> >> undefined behaviour being created when function type declaration added
>> >> by the user is not correct.
>> >> 
>> >> ATM we can have two values:
>> >> 
>> >> 1 Emitted code is generated in a safe matter even if function types are
>> >> miss-declared.
>> >> 0 Emitted code can misbehave or crash Emacs if function declarations are
>> >> not correct and the function is native compiled (@pxref{Native
>> >> Compilation}).
>> >> 
>> >> 1 is ATM the default.
>> >
>> > Is this for Emacs 30 or Emacs 31?
>> 
>> Hi Eli,
>> 
>> the question is related to the patch or the defaul value?
>
> Both.

ATM the default is the equivalent to the proposed 0 (and so it was since
the introduction of native compilation).

The proposal is for 30 but if it's too late it's for 31 :)

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10  7:58   ` Andrea Corallo
  2024-05-10  8:09     ` Gerd Möllmann
@ 2024-05-10 14:00     ` Stefan Monnier
  1 sibling, 0 replies; 33+ messages in thread
From: Stefan Monnier @ 2024-05-10 14:00 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: Gerd Möllmann, emacs-devel, Eli Zaretskii, mattias.engdegard,
	stefankangas

> After your hint I see now SBCL does that when:
>
> (or (>=safety 2) (>= safety speed 1)) [2]

FWIW, I always thought that having both `safety` and `speed` was a form
of overengineering which doesn't serve the users.


        Stefan




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10 11:42       ` Andrea Corallo
@ 2024-05-10 15:10         ` Eli Zaretskii
  0 siblings, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-10 15:10 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: emacs-devel, monnier, mattias.engdegard, stefankangas

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,
>   mattias.engdegard@gmail.com,  stefankangas@gmail.com
> Date: Fri, 10 May 2024 07:42:16 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Is this for Emacs 30 or Emacs 31?
> >> 
> >> Hi Eli,
> >> 
> >> the question is related to the patch or the defaul value?
> >
> > Both.
> 
> ATM the default is the equivalent to the proposed 0 (and so it was since
> the introduction of native compilation).
> 
> The proposal is for 30 but if it's too late it's for 31 :)

I didn't (yet) say it was too late, I just said that if we want this
in Emacs 30, we need top conclude this discussion soon enough.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-07 16:13   ` Andrea Corallo
@ 2024-05-10 17:58     ` Andrea Corallo
  2024-05-13  2:29       ` Stefan Monnier
  0 siblings, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-10 17:58 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: emacs-devel, Eli Zaretskii, mattias.engdegard, stefankangas

Andrea Corallo <acorallo@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I didn't want to give safety a prefix (byte- or comp-) as I believe we
>>> should extend safety in the future with a value to have the byte
>>> compiler generates runtime type checks to verify the declred types.
>>
>> I don't see a strong need for a namespace prefix, but I think "safety"
>> is too general a term.  It could be understood to apply also to
>> unrelated circumstances such as process confinement or disclosure of
>> sensitive info over a network connection.
>> Maybe `elisp-safety` or `compilation-safety`?
>
> Agree, boths SGTM, maaaybe I slightly prefer 'compilation-safety'.
>
>> If I read your patch correctly, we get safety in a roundabout way:
>> rather than test the safety setting at the spot where we decide to apply
>> (or not) a dangerous optimization, we use the safety setting to
>> "mollify" the type annotations (presumably because this will in turn
>> make the risky optimizations inapplicable).
>>
>> What is the reason for that?
>
> No specific reason, I think I thought was safer to write the patch with
> way gating optimization at this (higher) level.  Thinking about now that
> you raised the point, is probably easy to gate the single optimizations
> as well.  Why not, I think I'll update the patch this way.

Okay I pushed scratch/comp-safety2 changing the knob name to
'compilation-safety' and gating the dangerous optimizations as
discussed.

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-09  8:40 ` Eli Zaretskii
  2024-05-10  7:47   ` Andrea Corallo
@ 2024-05-10 18:02   ` Andrea Corallo
  2024-05-10 18:05     ` Andrea Corallo
  1 sibling, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-10 18:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, monnier, mattias.engdegard, stefankangas

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>>  mattias.engdegard@gmail.com, stefankangas@gmail.com
>> Date: Tue, 07 May 2024 06:37:50 -0400
>> 
>> I've put in scratch/comp-safety a branch wich introduces 'safety' as
>> compilation parameter.
>> 
>> 'safety' can be used similarly to 'native-comp-speed' both as a global
>> variable to influence compilation both as a function declaration.
>> 
>> 'safety' justification of existence is ATM being able to control the
>> undefined behaviour being created when function type declaration added
>> by the user is not correct.
>> 
>> ATM we can have two values:
>> 
>> 1 Emitted code is generated in a safe matter even if function types are
>> miss-declared.
>> 0 Emitted code can misbehave or crash Emacs if function declarations are
>> not correct and the function is native compiled (@pxref{Native
>> Compilation}).
>> 
>> 1 is ATM the default.
>
> Is this for Emacs 30 or Emacs 31?
>
> If the former, we should conclude this discussion soon enough.
>
> I don't have an opinion about the utility of this for Emacs Lisp, but
> this part of the documentation:
>
>> +Possible values are:
>> +
>> +0 Emitted code can misbehave or crash Emacs if function declarations are
>> +not correct and the function is native compiled (@pxref{Native
>> +Compilation}).
>> +
>> +1 Emitted code is generated in a safe matter even if function are
>> +miss-declared."
>
> should be formatted as a @table.

Okay, I moved that part to doc/lispref/compile.texi to document in
'compilation-safety' and added the @table for the possible values.
Still in functions.texi we keep a reference to it.

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10 18:02   ` Andrea Corallo
@ 2024-05-10 18:05     ` Andrea Corallo
  0 siblings, 0 replies; 33+ messages in thread
From: Andrea Corallo @ 2024-05-10 18:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, monnier, mattias.engdegard, stefankangas

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo@gnu.org>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>>>  mattias.engdegard@gmail.com, stefankangas@gmail.com
>>> Date: Tue, 07 May 2024 06:37:50 -0400
>>> 
>>> I've put in scratch/comp-safety a branch wich introduces 'safety' as
>>> compilation parameter.
>>> 
>>> 'safety' can be used similarly to 'native-comp-speed' both as a global
>>> variable to influence compilation both as a function declaration.
>>> 
>>> 'safety' justification of existence is ATM being able to control the
>>> undefined behaviour being created when function type declaration added
>>> by the user is not correct.
>>> 
>>> ATM we can have two values:
>>> 
>>> 1 Emitted code is generated in a safe matter even if function types are
>>> miss-declared.
>>> 0 Emitted code can misbehave or crash Emacs if function declarations are
>>> not correct and the function is native compiled (@pxref{Native
>>> Compilation}).
>>> 
>>> 1 is ATM the default.
>>
>> Is this for Emacs 30 or Emacs 31?
>>
>> If the former, we should conclude this discussion soon enough.
>>
>> I don't have an opinion about the utility of this for Emacs Lisp, but
>> this part of the documentation:
>>
>>> +Possible values are:
>>> +
>>> +0 Emitted code can misbehave or crash Emacs if function declarations are
>>> +not correct and the function is native compiled (@pxref{Native
>>> +Compilation}).
>>> +
>>> +1 Emitted code is generated in a safe matter even if function are
>>> +miss-declared."
>>
>> should be formatted as a @table.
>
> Okay, I moved that part to doc/lispref/compile.texi to document in
> 'compilation-safety' and added the @table for the possible values.
> Still in functions.texi we keep a reference to it.

Sorry forgot to mention that the new code is in scratch/comp-safety2
(I'll do some GC at the end but wanted to keep both approaches for now).

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-10 17:58     ` Andrea Corallo
@ 2024-05-13  2:29       ` Stefan Monnier
  2024-05-13 18:59         ` Eli Zaretskii
  0 siblings, 1 reply; 33+ messages in thread
From: Stefan Monnier @ 2024-05-13  2:29 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: emacs-devel, Eli Zaretskii, mattias.engdegard, stefankangas

> Okay I pushed scratch/comp-safety2 changing the knob name to
> 'compilation-safety' and gating the dangerous optimizations as
> discussed.

Thanks.  LGTM now (I'm still not sure we need both "safety" and "speed"
controls, but we may as well follow CL's lead).


        Stefan




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-13  2:29       ` Stefan Monnier
@ 2024-05-13 18:59         ` Eli Zaretskii
  2024-05-13 21:12           ` Andrea Corallo
  0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-13 18:59 UTC (permalink / raw)
  To: acorallo, Stefan Monnier; +Cc: emacs-devel, mattias.engdegard, stefankangas

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  Eli Zaretskii <eliz@gnu.org>,
>  mattias.engdegard@gmail.com,  stefankangas@gmail.com
> Date: Sun, 12 May 2024 22:29:08 -0400
> 
> > Okay I pushed scratch/comp-safety2 changing the knob name to
> > 'compilation-safety' and gating the dangerous optimizations as
> > discussed.
> 
> Thanks.  LGTM now (I'm still not sure we need both "safety" and "speed"
> controls, but we may as well follow CL's lead).

Agreed.  Andrea, feel free to land this on master, and thanks.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-13 18:59         ` Eli Zaretskii
@ 2024-05-13 21:12           ` Andrea Corallo
  2024-05-14  6:11             ` Eli Zaretskii
  0 siblings, 1 reply; 33+ messages in thread
From: Andrea Corallo @ 2024-05-13 21:12 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: Stefan Monnier, emacs-devel, mattias.engdegard, stefankangas

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: emacs-devel@gnu.org,  Eli Zaretskii <eliz@gnu.org>,
>>  mattias.engdegard@gmail.com,  stefankangas@gmail.com
>> Date: Sun, 12 May 2024 22:29:08 -0400
>> 
>> > Okay I pushed scratch/comp-safety2 changing the knob name to
>> > 'compilation-safety' and gating the dangerous optimizations as
>> > discussed.
>> 
>> Thanks.  LGTM now (I'm still not sure we need both "safety" and "speed"
>> controls, but we may as well follow CL's lead).
>
> Agreed.  Andrea, feel free to land this on master, and thanks.

Done now.  As usual feel free to round any edge if you spot it 🙏

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Introducing 'safety' compilation parameter
  2024-05-13 21:12           ` Andrea Corallo
@ 2024-05-14  6:11             ` Eli Zaretskii
  0 siblings, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2024-05-14  6:11 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: monnier, emacs-devel, mattias.engdegard, stefankangas

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org,
>   mattias.engdegard@gmail.com,  stefankangas@gmail.com
> Date: Mon, 13 May 2024 17:12:15 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Okay I pushed scratch/comp-safety2 changing the knob name to
> >> > 'compilation-safety' and gating the dangerous optimizations as
> >> > discussed.
> >> 
> >> Thanks.  LGTM now (I'm still not sure we need both "safety" and "speed"
> >> controls, but we may as well follow CL's lead).
> >
> > Agreed.  Andrea, feel free to land this on master, and thanks.
> 
> Done now.  As usual feel free to round any edge if you spot it 🙏

Done.



^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2024-05-14  6:11 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-07 10:37 Introducing 'safety' compilation parameter Andrea Corallo
2024-05-07 12:01 ` Alan Mackenzie
2024-05-07 13:15   ` Eli Zaretskii
2024-05-07 16:07     ` Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] Alan Mackenzie
2024-05-07 17:06       ` Andrea Corallo
2024-05-07 23:37         ` Emanuel Berg
2024-05-07 18:00       ` Eli Zaretskii
2024-05-08  0:14         ` Emanuel Berg
2024-05-07 23:29       ` Emanuel Berg
2024-05-09 23:52       ` Richard Stallman
2024-05-10  6:31         ` Eli Zaretskii
2024-05-07 16:37   ` Introducing 'safety' compilation parameter Tomas Hlavaty
2024-05-07 16:54   ` Andrea Corallo
2024-05-07 23:42     ` Emanuel Berg
2024-05-07 14:56 ` Stefan Monnier
2024-05-07 16:13   ` Andrea Corallo
2024-05-10 17:58     ` Andrea Corallo
2024-05-13  2:29       ` Stefan Monnier
2024-05-13 18:59         ` Eli Zaretskii
2024-05-13 21:12           ` Andrea Corallo
2024-05-14  6:11             ` Eli Zaretskii
2024-05-09  8:40 ` Eli Zaretskii
2024-05-10  7:47   ` Andrea Corallo
2024-05-10 10:17     ` Eli Zaretskii
2024-05-10 11:42       ` Andrea Corallo
2024-05-10 15:10         ` Eli Zaretskii
2024-05-10 18:02   ` Andrea Corallo
2024-05-10 18:05     ` Andrea Corallo
2024-05-09  9:19 ` Gerd Möllmann
2024-05-10  7:58   ` Andrea Corallo
2024-05-10  8:09     ` Gerd Möllmann
2024-05-10  8:19       ` Andrea Corallo
2024-05-10 14:00     ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).