[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing '
From: |
Andrea Corallo |
Subject: |
Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] |
Date: |
Tue, 07 May 2024 13:06:58 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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
Re: Introducing 'safety' compilation parameter, Tomas Hlavaty, 2024/05/07
Re: Introducing 'safety' compilation parameter, Andrea Corallo, 2024/05/07
Re: Introducing 'safety' compilation parameter, Stefan Monnier, 2024/05/07