emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introducing 'safety' compilation parameter


From: Andrea Corallo
Subject: Re: Introducing 'safety' compilation parameter
Date: Tue, 07 May 2024 12:54:58 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]