From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Drifting towards a statically typed Emacs Lisp. [Was: Introducing 'safety' compilation parameter] Date: Wed, 08 May 2024 01:29:50 +0200 Message-ID: <87le4l8akx.fsf@dataswamp.org> References: <86v83pahks.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36948"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:5HwB4gd8EuwW+owDycgOG4m3nFs= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 08 04:22:58 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s4WxM-0009KF-NM for ged-emacs-devel@m.gmane-mx.org; Wed, 08 May 2024 04:22:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4Wwl-0004Yj-Hy; Tue, 07 May 2024 22:22:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4UG5-0001Zv-F7 for emacs-devel@gnu.org; Tue, 07 May 2024 19:30:05 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4UG2-0001cz-Pi for emacs-devel@gnu.org; Tue, 07 May 2024 19:30:05 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1s4UFz-00090D-OK for emacs-devel@gnu.org; Wed, 08 May 2024 01:30:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 07 May 2024 22:22:16 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318983 Archived-At: 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