Re: Introducing 'safety' compilation parameter

[Alan Mackenzie <acm@muc.de>]

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