From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: monnier@iro.umontreal.ca, bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Mar 2024 23:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69739@debbugs.gnu.org Cc: monnier@iro.umontreal.ca X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: monnier@iro.umontreal.ca Received: via spool by submit@debbugs.gnu.org id=B.171019928115908 (code B ref -1); Mon, 11 Mar 2024 23:22:01 +0000 Received: (at submit) by debbugs.gnu.org; 11 Mar 2024 23:21:21 +0000 Received: from localhost ([127.0.0.1]:41468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjoxI-00048Q-W1 for submit@debbugs.gnu.org; Mon, 11 Mar 2024 19:21:20 -0400 Received: from lists.gnu.org ([209.51.188.17]:57726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjoxC-000483-4s for submit@debbugs.gnu.org; Mon, 11 Mar 2024 19:21:14 -0400 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 1rjowW-0005kI-2z for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2024 19:20:28 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rjowJ-0000Yz-Hp for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2024 19:20:24 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8D351442C81 for ; Mon, 11 Mar 2024 19:20:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710199201; bh=QRkYvZ+UJHnYRPIGUOwQfw9e1IsIAkf5xRTK/vLYfwY=; h=From:To:Subject:Date:From; b=E3THFMtfxsPnnJtEnf4ghfxHzRAjWsyu+7YZC1i+4TgO+FuXBc7d44/UCCgoRe8VL Teg3MenyrGKRpadCCdxOKZvC8SP+xv3CKAZjjQLHFzEbQDXQ5nXKXwCxqZvsuZp/8J TSdOSf3lYAGB+GmKVZ0Y01XXub3zxZnDYN/wgZ8UBFRtTH2O8VOK4aCXrAcyQTEK8r VEDDCMVtLNoZQL1tUr5czIfFywRSHCz4TVJKtX4Vf5tj1ZaW+mtXxGF9wOarQ+q136 1yNm91Rl4rLFSeohUq0wq/9k7hPnQiROHLSM0e6pLzDI7FZY4UdOLJdVjFydAaYfDp zJmu9V0cpFn5w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BD5DC4447A8 for ; Mon, 11 Mar 2024 19:20:01 -0400 (EDT) Received: from pastel (69-165-147-56.dsl.teksavvy.com [69.165.147.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9DECE120403 for ; Mon, 11 Mar 2024 19:20:01 -0400 (EDT) From: Stefan Monnier Date: Mon, 11 Mar 2024 19:19:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.038 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Package: Emacs Version: 30.0.50 `type-of` is supposed to return "the" type of its argument. Given that ELisp has a notion of subtyping, "the" type is expected to mean "the most precise type". This is used in `cl-generic` to decide which method to apply, so it's important that it returns precise information. Currently, there `type-of` fails to return precise enough information in a few cases: - When the argument is nil, it returns `symbol`. The problem here is that `symbol` is not a subtype of `list`, whereas nil is a list. - When the argument is a special form, a C primitive, or a native-compiled function it returns `subr`. Currently our type hierarchy says that `subr` is a subtype of `compiled-function` (and hence of `function`), but a special form is *not* a function (it fails the `functionp` test and can't be `funcall`ed). Currently `cl-generic` works around the first point above by using (if FOO (type-of FOO) 'null) instead of calling `type-of` directly. Suggestion: I suggest we change `type-of` to return `null` for `nil`, `special-form` for subrs that are special forms, `subr-primitive` for C primitives, and `subr-native-elisp` for native-compiled subrs. There are a few other cases where we could improve the precision, tho they are less important because they don't cause problems w.r.t subtyping like the above does. Further improvements could include: - Return `boolean` for `t`. This would be nice otherwise (with the above suggestion) `cl-generic` can dispatch on "nil is a boolean" but not on "t is a boolean". - Return `keyword` for symbols that are keywords. - Return `fixnum` or `bignum` rather than just `integer`. Probably not worth the trouble. - We could go crazy and return `keyword-with-pos` for `symbols-with-pos` that are keywords. Of these further improvements, only the first (return `boolean` for `t`) seems worth the trouble. Still, any change as suggested here would be an incompatible change, so there's risk it'll break some code out there (`type-of` is not used very often, but it *is* used). Another option is to introduce a new function which does the same as `type-of` but with changes like the ones above. (we could even decide to give it a `cl-generic-` prefix to discourage its use elsewhere so we can be more free to change its return value in the future). Stefan From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2024 13:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171025071723483 (code B ref 69739); Tue, 12 Mar 2024 13:39:02 +0000 Received: (at 69739) by debbugs.gnu.org; 12 Mar 2024 13:38:37 +0000 Received: from localhost ([127.0.0.1]:42093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk2Ky-00066g-NR for submit@debbugs.gnu.org; Tue, 12 Mar 2024 09:38:37 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk2Kv-00066Q-Rn for 69739@debbugs.gnu.org; Tue, 12 Mar 2024 09:38:35 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CAC3F806EF; Tue, 12 Mar 2024 09:37:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710250671; bh=DB1nZU6IUuQRtjtn5iKC1QfCe2VswDi5xynEVueh52M=; h=From:To:Subject:In-Reply-To:References:Date:From; b=jHtOS0axBWQcNXBvqevinpYK+0UihEH5AnvFRDThtOBBBNhr1aAK3j0nfI2+t0QTS 12rPccGV++4bcKAziEg4MkJWKSJmAyDpjE7yD+ED0gm6oGhcXbMSgb8A3y+ZgglfwL xMDjZiyfMIZrS6sLSeweUR1gFVHxK/kyMIfD96Fu/WGoBxJMd5zBovYoEibRa3fu42 awIsmnuWGfWMNGKDgDqtnAgD5ZYnT5vab0n4v6YMqx8ziVZBOnTO3ujnlNx33CS6vq i5Izm32hjuV4cRmNWj6Wkh7unSOrCHFqZp2YmGo/MMqsqHI+H/O3xo9AwgAzlD+mAo TMo98ec29EZXA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3C191800D0; Tue, 12 Mar 2024 09:37:51 -0400 (EDT) Received: from pastel (69-165-147-56.dsl.teksavvy.com [69.165.147.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1D160120472; Tue, 12 Mar 2024 09:37:51 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Mon, 11 Mar 2024 19:19:40 -0400") Message-ID: References: Date: Tue, 12 Mar 2024 09:37:49 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.025 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain To make it more concrete, here's a suggested patch. Comments? Objections? Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-type-of-Return-more-precise-types-bug-69739.patch >From 7b017522a11f8d8e0bafab85b7032d4e9763aeff Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 12 Mar 2024 09:26:24 -0400 Subject: [PATCH] (type-of): Return more precise types (bug#69739) * src/data.c (Ftype_of): Give more precise types for nil, t, and the three subcases of `subr`. (syms_of_data): Define the corresponding new symbols. * lisp/emacs-lisp/cl-preloaded.el (subr): Demote it to `atom`. (subr-native-elisp, subr-primitive): Add `compiled-function` as parent instead. (special-form): New type. (finalizer): New (previously missing) type. * lisp/emacs-lisp/seq.el (seq-remove-at-position): Adjust to `type-of` returning `null` for nil. * lisp/obsolete/eieio-compat.el (eieio--generic-static-object-generalizer): * lisp/emacs-lisp/cl-generic.el (cl--generic-typeof-generalizer): Simplify. * doc/lispref/objects.texi (Type Predicates): Update accordingly. --- doc/lispref/objects.texi | 13 +++++++------ etc/NEWS | 5 +++++ lisp/emacs-lisp/cl-generic.el | 3 +-- lisp/emacs-lisp/cl-preloaded.el | 11 +++++++---- lisp/emacs-lisp/seq.el | 2 +- lisp/obsolete/eieio-compat.el | 2 +- src/data.c | 14 +++++++++++--- 7 files changed, 33 insertions(+), 17 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 279f449a994..00581814825 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -1485,8 +1485,8 @@ Type Descriptors @subsection Type Descriptors A @dfn{type descriptor} is a @code{record} which holds information -about a type. Slot 1 in the record must be a symbol naming the type, and -@code{type-of} relies on this to return the type of @code{record} +about a type. The first slot in the record must be a symbol naming the type, +and @code{type-of} relies on this to return the type of @code{record} objects. No other type descriptor slot is used by Emacs; they are free for use by Lisp extensions. @@ -2186,8 +2186,9 @@ Type Predicates @code{float}, @code{font-entity}, @code{font-object}, @code{font-spec}, @code{frame}, @code{hash-table}, @code{integer}, @code{marker}, @code{mutex}, @code{obarray}, @code{overlay}, @code{process}, -@code{string}, @code{subr}, @code{symbol}, @code{thread}, -@code{vector}, @code{window}, or @code{window-configuration}. +@code{string}, @code{subr-primitive}, @code{subr-native-elisp}, +@code{special-form}, @code{symbol}, @code{null}, @code{boolean}, +@code{thread}, @code{vector}, @code{window}, or @code{window-configuration}. However, if @var{object} is a record, the type specified by its first slot is returned; @ref{Records}. @@ -2196,9 +2197,9 @@ Type Predicates @result{} integer @group (type-of 'nil) - @result{} symbol + @result{} null (type-of '()) ; @r{@code{()} is @code{nil}.} - @result{} symbol + @result{} null (type-of '(x)) @result{} cons (type-of (record 'foo)) diff --git a/etc/NEWS b/etc/NEWS index 19cd170e5c7..d06b3f9c06d 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -62,6 +62,11 @@ more details. * Incompatible Changes in Emacs 30.1 +** 'type-of' sometimes returns more precise types. +More specifically, for nil and t it returns 'null' and 'boolean' +instead of just 'symbol' and for "subrs", it now returns one of +'special-form', 'subr-primitive', or 'subr-native-elisp'. + ** Tree-Sitter modes are now declared as submodes of the non-TS modes. In order to help the use of those Tree-Sitter modes, they are now declared to have the corresponding non-Tree-Sitter mode as an diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el index 84eb800ec24..cc7773ad4a2 100644 --- a/lisp/emacs-lisp/cl-generic.el +++ b/lisp/emacs-lisp/cl-generic.el @@ -1339,8 +1339,7 @@ cl--generic-type-specializers (cl--class-allparents class))))) (cl-generic-define-generalizer cl--generic-typeof-generalizer - ;; FIXME: We could also change `type-of' to return `null' for nil. - 10 (lambda (name &rest _) `(if ,name (type-of ,name) 'null)) + 10 #'type-of #'cl--generic-type-specializers) (cl-defmethod cl-generic-generalizers :extra "typeof" (type) diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 5743684fa89..7ab39fed222 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -355,6 +355,7 @@ frame (cl--define-built-in-type buffer atom) (cl--define-built-in-type window atom) (cl--define-built-in-type process atom) +(cl--define-built-in-type finalizer atom) (cl--define-built-in-type window-configuration atom) (cl--define-built-in-type overlay atom) (cl--define-built-in-type number-or-marker atom @@ -415,15 +416,17 @@ compiled-function "Abstract type of functions that have been compiled.") (cl--define-built-in-type byte-code-function (compiled-function) "Type of functions that have been byte-compiled.") -(cl--define-built-in-type subr (compiled-function) +(cl--define-built-in-type subr (atom) "Abstract type of functions compiled to machine code.") (cl--define-built-in-type module-function (function) "Type of functions provided via the module API.") (cl--define-built-in-type interpreted-function (function) "Type of functions that have not been compiled.") -(cl--define-built-in-type subr-native-elisp (subr) - "Type of function that have been compiled by the native compiler.") -(cl--define-built-in-type subr-primitive (subr) +(cl--define-built-in-type special-form (subr) + "Type of the core syntactic elements of the Emacs Lisp language.") +(cl--define-built-in-type subr-native-elisp (subr compiled-function) + "Type of functions that have been compiled by the native compiler.") +(cl--define-built-in-type subr-primitive (subr compiled-function) "Type of functions hand written in C.") (unless (cl--class-parents (cl--find-class 'cl-structure-object)) diff --git a/lisp/emacs-lisp/seq.el b/lisp/emacs-lisp/seq.el index 20077db9e60..cd6f26abdb3 100644 --- a/lisp/emacs-lisp/seq.el +++ b/lisp/emacs-lisp/seq.el @@ -363,7 +363,7 @@ seq-remove-at-position The result is a sequence of the same type as SEQUENCE." (seq-concatenate (let ((type (type-of sequence))) - (if (eq type 'cons) 'list type)) + (if (memq type '(null cons)) 'list type)) (seq-subseq sequence 0 n) (seq-subseq sequence (1+ n)))) diff --git a/lisp/obsolete/eieio-compat.el b/lisp/obsolete/eieio-compat.el index 8fdcebbd1c4..c50524d359e 100644 --- a/lisp/obsolete/eieio-compat.el +++ b/lisp/obsolete/eieio-compat.el @@ -146,7 +146,7 @@ eieio--generic-static-symbol-generalizer (cl-generic-define-generalizer eieio--generic-static-object-generalizer ;; Give it a slightly higher priority than `class' so that the ;; interleaved list comes before the class's non-interleaved list. - 51 #'cl--generic-struct-tag + 51 #'type-of (lambda (tag &rest _) (and (symbolp tag) (setq tag (cl--find-class tag)) (eieio--class-p tag) diff --git a/src/data.c b/src/data.c index 35f4c82c68f..35bd3b19e45 100644 --- a/src/data.c +++ b/src/data.c @@ -202,7 +202,9 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, return Qinteger; case Lisp_Symbol: - return Qsymbol; + return NILP (object) ? Qnull + : EQ (object, Qt) ? Qboolean + : Qsymbol; case Lisp_String: return Qstring; @@ -224,7 +226,10 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, case PVEC_WINDOW_CONFIGURATION: return Qwindow_configuration; case PVEC_PROCESS: return Qprocess; case PVEC_WINDOW: return Qwindow; - case PVEC_SUBR: return Qsubr; + case PVEC_SUBR: + return XSUBR (object)->max_args == UNEVALLED ? Qspecial_form + : SUBR_NATIVE_COMPILEDP (object) ? Qsubr_native_elisp + : Qsubr_primitive; case PVEC_COMPILED: return Qcompiled_function; case PVEC_BUFFER: return Qbuffer; case PVEC_CHAR_TABLE: return Qchar_table; @@ -4202,6 +4207,7 @@ #define PUT_ERROR(sym, tail, msg) \ "Variable binding depth exceeds max-specpdl-size"); /* Types that type-of returns. */ + DEFSYM (Qboolean, "boolean"); DEFSYM (Qinteger, "integer"); DEFSYM (Qsymbol, "symbol"); DEFSYM (Qstring, "string"); @@ -4217,7 +4223,9 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qwindow_configuration, "window-configuration"); DEFSYM (Qprocess, "process"); DEFSYM (Qwindow, "window"); - DEFSYM (Qsubr, "subr"); + DEFSYM (Qspecial_form, "special-form"); + DEFSYM (Qsubr_primitive, "subr-primitive"); + DEFSYM (Qsubr_native_elisp, "subr-native-elisp"); DEFSYM (Qcompiled_function, "compiled-function"); DEFSYM (Qbuffer, "buffer"); DEFSYM (Qframe, "frame"); -- 2.43.0 --=-=-=-- From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2024 13:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171025194126811 (code B ref 69739); Tue, 12 Mar 2024 13:59:02 +0000 Received: (at 69739) by debbugs.gnu.org; 12 Mar 2024 13:59:01 +0000 Received: from localhost ([127.0.0.1]:43302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk2ei-0006yN-JY for submit@debbugs.gnu.org; Tue, 12 Mar 2024 09:59:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk2ec-0006y6-SU for 69739@debbugs.gnu.org; Tue, 12 Mar 2024 09:58:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rk2dz-0006p8-2j; Tue, 12 Mar 2024 09:58:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=m/1dn2RswQuIcBkGvUPeTCPZjQKzos9uzEm+whFa8Wo=; b=OhHWj389NkdB gFDl0DPw1i5SEPXThXf+OxEpzSzzRNNrpythPBlr3FQ9W3HpPdqNpnmjw+vkCUvndy+adcRnJ53xp /D9H3ZjxGgRidYPWdIjPuxNtbPuzwy1TkEZRUVQ/IKIeJq5a7FKKcapWCZg2RVpXuT0OK6SADCfQf LxdSBtNcPfa0U636misBX9lwU6Bjd83ZhVInuiZbIpANnN+B84Zzd8PB6xcrtmrW9IWDwlThKLYRe nKHXaG/jGbr6mej816CDXcoh46g63wxZdAZ45Cp1hcox91JG88u4H0C6TyPpc9FXJvMz5T0PiRrAG iNGanNkqQmV+b+US8Bsgxg==; Date: Tue, 12 Mar 2024 15:58:08 +0200 Message-Id: <86o7bjtuvj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (bug-gnu-emacs@gnu.org) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: monnier@iro.umontreal.ca > Date: Mon, 11 Mar 2024 19:19:40 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Still, any change as suggested here would be an incompatible change, so > there's risk it'll break some code out there (`type-of` is not used very > often, but it *is* used). Another option is to introduce a new function > which does the same as `type-of` but with changes like the ones above. > (we could even decide to give it a `cl-generic-` prefix to discourage > its use elsewhere so we can be more free to change its return value in > the future). I'd prefer a non-breaking change, if possible and reasonable. Thanks. From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2024 14:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.17102545179746 (code B ref 69739); Tue, 12 Mar 2024 14:42:02 +0000 Received: (at 69739) by debbugs.gnu.org; 12 Mar 2024 14:41:57 +0000 Received: from localhost ([127.0.0.1]:43346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk3KG-0002X5-Jg for submit@debbugs.gnu.org; Tue, 12 Mar 2024 10:41:57 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16047) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk3KC-0002Wg-VY for 69739@debbugs.gnu.org; Tue, 12 Mar 2024 10:41:54 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BE2891001CE; Tue, 12 Mar 2024 10:40:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710254454; bh=lzA7Ps08mChwEs206/5KJBfUhZihl7hU3IcI7bfdlBc=; h=From:To:Subject:In-Reply-To:References:Date:From; b=V874WcC8OeBkwzIx96nnamoQfcjXqPqivXdGT4D/77ekUYDMFV5gcaHFZkNEVEPM2 bTK6KDSSmmKfI9WbnQFGYZbk5Z+l9r+7516tc8+r3ZyAi1mrs/ew4d7PNwPGaWIgrC ZclJwuZwnV5H42KWBOGGtFpGCwmChQFhG9yDmw4OPPqchLgKru1n3RzQ+GKJGXsRBp hQwlRBs9QL6yOn9rgxVKChXBlv6d3hqKLraJi0NX74eb2uPRkMLP0UMoCLFBFkeRUa wjHGSb7y3VW0qZGU/IqOeABCi/9ru+E7LU8Rqc8Z300MGFkPJ+h26l8Y9NHNSnFLQc g6ed4f7+kWinA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E7C3100051; Tue, 12 Mar 2024 10:40:54 -0400 (EDT) Received: from pastel (69-165-147-56.dsl.teksavvy.com [69.165.147.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 21075120024; Tue, 12 Mar 2024 10:40:54 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Tue, 12 Mar 2024 09:37:49 -0400") Message-ID: References: Date: Tue, 12 Mar 2024 10:40:52 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.054 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain > To make it more concrete, here's a suggested patch. Hmm... got a bit carried away on the simplification of cl-generic, sorry. Here's a better patch that does work. Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-type-of-Return-more-precise-types-bug-69739.patch >From dcea90a70e96d238650f771b2a26348d73b1fa05 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 12 Mar 2024 09:26:24 -0400 Subject: [PATCH] (type-of): Return more precise types (bug#69739) * src/data.c (Ftype_of): Give more precise types for nil, t, and the three subcases of `subr`. (syms_of_data): Define the corresponding new symbols. * lisp/emacs-lisp/cl-preloaded.el (subr): Demote it to `atom`. (subr-native-elisp, subr-primitive): Add `compiled-function` as parent instead. (special-form): New type. (finalizer): New (previously missing) type. * lisp/emacs-lisp/seq.el (seq-remove-at-position): Adjust to `type-of` returning `null` for nil. * lisp/obsolete/eieio-core.el (cl--generic-struct-tag): * lisp/emacs-lisp/cl-generic.el (cl--generic-typeof-generalizer): Simplify. * test/lisp/emacs-lisp/ert-tests.el (ert-test-plist-difference-explanation) (ert-test-explain-equal, ert-test-explain-equal-string-properties): Adjust expected answers. * doc/lispref/objects.texi (Type Predicates): Update. --- doc/lispref/objects.texi | 13 +++++++------ etc/NEWS | 5 +++++ lisp/emacs-lisp/cl-generic.el | 3 +-- lisp/emacs-lisp/cl-preloaded.el | 11 +++++++---- lisp/emacs-lisp/eieio-core.el | 2 +- lisp/emacs-lisp/seq.el | 2 +- src/data.c | 14 +++++++++++--- test/lisp/emacs-lisp/ert-tests.el | 8 ++++---- 8 files changed, 37 insertions(+), 21 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 279f449a994..00581814825 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -1485,8 +1485,8 @@ Type Descriptors @subsection Type Descriptors A @dfn{type descriptor} is a @code{record} which holds information -about a type. Slot 1 in the record must be a symbol naming the type, and -@code{type-of} relies on this to return the type of @code{record} +about a type. The first slot in the record must be a symbol naming the type, +and @code{type-of} relies on this to return the type of @code{record} objects. No other type descriptor slot is used by Emacs; they are free for use by Lisp extensions. @@ -2186,8 +2186,9 @@ Type Predicates @code{float}, @code{font-entity}, @code{font-object}, @code{font-spec}, @code{frame}, @code{hash-table}, @code{integer}, @code{marker}, @code{mutex}, @code{obarray}, @code{overlay}, @code{process}, -@code{string}, @code{subr}, @code{symbol}, @code{thread}, -@code{vector}, @code{window}, or @code{window-configuration}. +@code{string}, @code{subr-primitive}, @code{subr-native-elisp}, +@code{special-form}, @code{symbol}, @code{null}, @code{boolean}, +@code{thread}, @code{vector}, @code{window}, or @code{window-configuration}. However, if @var{object} is a record, the type specified by its first slot is returned; @ref{Records}. @@ -2196,9 +2197,9 @@ Type Predicates @result{} integer @group (type-of 'nil) - @result{} symbol + @result{} null (type-of '()) ; @r{@code{()} is @code{nil}.} - @result{} symbol + @result{} null (type-of '(x)) @result{} cons (type-of (record 'foo)) diff --git a/etc/NEWS b/etc/NEWS index 19cd170e5c7..d06b3f9c06d 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -62,6 +62,11 @@ more details. * Incompatible Changes in Emacs 30.1 +** 'type-of' sometimes returns more precise types. +More specifically, for nil and t it returns 'null' and 'boolean' +instead of just 'symbol' and for "subrs", it now returns one of +'special-form', 'subr-primitive', or 'subr-native-elisp'. + ** Tree-Sitter modes are now declared as submodes of the non-TS modes. In order to help the use of those Tree-Sitter modes, they are now declared to have the corresponding non-Tree-Sitter mode as an diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el index 84eb800ec24..06f70146808 100644 --- a/lisp/emacs-lisp/cl-generic.el +++ b/lisp/emacs-lisp/cl-generic.el @@ -1339,8 +1339,7 @@ cl--generic-type-specializers (cl--class-allparents class))))) (cl-generic-define-generalizer cl--generic-typeof-generalizer - ;; FIXME: We could also change `type-of' to return `null' for nil. - 10 (lambda (name &rest _) `(if ,name (type-of ,name) 'null)) + 10 (lambda (name &rest _) `(type-of ,name)) #'cl--generic-type-specializers) (cl-defmethod cl-generic-generalizers :extra "typeof" (type) diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 5743684fa89..7ab39fed222 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -355,6 +355,7 @@ frame (cl--define-built-in-type buffer atom) (cl--define-built-in-type window atom) (cl--define-built-in-type process atom) +(cl--define-built-in-type finalizer atom) (cl--define-built-in-type window-configuration atom) (cl--define-built-in-type overlay atom) (cl--define-built-in-type number-or-marker atom @@ -415,15 +416,17 @@ compiled-function "Abstract type of functions that have been compiled.") (cl--define-built-in-type byte-code-function (compiled-function) "Type of functions that have been byte-compiled.") -(cl--define-built-in-type subr (compiled-function) +(cl--define-built-in-type subr (atom) "Abstract type of functions compiled to machine code.") (cl--define-built-in-type module-function (function) "Type of functions provided via the module API.") (cl--define-built-in-type interpreted-function (function) "Type of functions that have not been compiled.") -(cl--define-built-in-type subr-native-elisp (subr) - "Type of function that have been compiled by the native compiler.") -(cl--define-built-in-type subr-primitive (subr) +(cl--define-built-in-type special-form (subr) + "Type of the core syntactic elements of the Emacs Lisp language.") +(cl--define-built-in-type subr-native-elisp (subr compiled-function) + "Type of functions that have been compiled by the native compiler.") +(cl--define-built-in-type subr-primitive (subr compiled-function) "Type of functions hand written in C.") (unless (cl--class-parents (cl--find-class 'cl-structure-object)) diff --git a/lisp/emacs-lisp/eieio-core.el b/lisp/emacs-lisp/eieio-core.el index a2f7c4172a3..8221625d885 100644 --- a/lisp/emacs-lisp/eieio-core.el +++ b/lisp/emacs-lisp/eieio-core.el @@ -1046,7 +1046,7 @@ 'inconsistent-class-hierarchy (defun cl--generic-struct-tag (name &rest _) ;; Use exactly the same code as for `typeof'. - `(if ,name (type-of ,name) 'null)) + `(type-of ,name)) (cl-generic-define-generalizer eieio--generic-generalizer ;; Use the exact same tagcode as for cl-struct, so that methods diff --git a/lisp/emacs-lisp/seq.el b/lisp/emacs-lisp/seq.el index 20077db9e60..cd6f26abdb3 100644 --- a/lisp/emacs-lisp/seq.el +++ b/lisp/emacs-lisp/seq.el @@ -363,7 +363,7 @@ seq-remove-at-position The result is a sequence of the same type as SEQUENCE." (seq-concatenate (let ((type (type-of sequence))) - (if (eq type 'cons) 'list type)) + (if (memq type '(null cons)) 'list type)) (seq-subseq sequence 0 n) (seq-subseq sequence (1+ n)))) diff --git a/src/data.c b/src/data.c index 35f4c82c68f..35bd3b19e45 100644 --- a/src/data.c +++ b/src/data.c @@ -202,7 +202,9 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, return Qinteger; case Lisp_Symbol: - return Qsymbol; + return NILP (object) ? Qnull + : EQ (object, Qt) ? Qboolean + : Qsymbol; case Lisp_String: return Qstring; @@ -224,7 +226,10 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, case PVEC_WINDOW_CONFIGURATION: return Qwindow_configuration; case PVEC_PROCESS: return Qprocess; case PVEC_WINDOW: return Qwindow; - case PVEC_SUBR: return Qsubr; + case PVEC_SUBR: + return XSUBR (object)->max_args == UNEVALLED ? Qspecial_form + : SUBR_NATIVE_COMPILEDP (object) ? Qsubr_native_elisp + : Qsubr_primitive; case PVEC_COMPILED: return Qcompiled_function; case PVEC_BUFFER: return Qbuffer; case PVEC_CHAR_TABLE: return Qchar_table; @@ -4202,6 +4207,7 @@ #define PUT_ERROR(sym, tail, msg) \ "Variable binding depth exceeds max-specpdl-size"); /* Types that type-of returns. */ + DEFSYM (Qboolean, "boolean"); DEFSYM (Qinteger, "integer"); DEFSYM (Qsymbol, "symbol"); DEFSYM (Qstring, "string"); @@ -4217,7 +4223,9 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qwindow_configuration, "window-configuration"); DEFSYM (Qprocess, "process"); DEFSYM (Qwindow, "window"); - DEFSYM (Qsubr, "subr"); + DEFSYM (Qspecial_form, "special-form"); + DEFSYM (Qsubr_primitive, "subr-primitive"); + DEFSYM (Qsubr_native_elisp, "subr-native-elisp"); DEFSYM (Qcompiled_function, "compiled-function"); DEFSYM (Qbuffer, "buffer"); DEFSYM (Qframe, "frame"); diff --git a/test/lisp/emacs-lisp/ert-tests.el b/test/lisp/emacs-lisp/ert-tests.el index 1aff73d66f6..289069362b3 100644 --- a/test/lisp/emacs-lisp/ert-tests.el +++ b/test/lisp/emacs-lisp/ert-tests.el @@ -674,7 +674,7 @@ ert-test-string-first-line (ert-deftest ert-test-explain-equal () (should (equal (ert--explain-equal nil 'foo) - '(different-atoms nil foo))) + '(different-types nil foo))) (should (equal (ert--explain-equal '(a a) '(a b)) '(list-elt 1 (different-atoms a b)))) (should (equal (ert--explain-equal '(1 48) '(1 49)) @@ -732,10 +732,10 @@ ert-test-plist-difference-explanation nil)) (should (equal (ert--plist-difference-explanation '(a b c t) '(a b)) - '(different-properties-for-key c (different-atoms t nil)))) + '(different-properties-for-key c (different-types t nil)))) (should (equal (ert--plist-difference-explanation '(a b c t) '(c nil a b)) - '(different-properties-for-key c (different-atoms t nil)))) + '(different-properties-for-key c (different-types t nil)))) (should (equal (ert--plist-difference-explanation '(a b c (foo . bar)) '(c (foo . baz) a b)) '(different-properties-for-key c @@ -778,7 +778,7 @@ ert-test-explain-equal-string-properties #("foo" 0 1 (a b)) "foo") '(char 0 "f" - (different-properties-for-key a (different-atoms b nil)) + (different-properties-for-key a (different-types b nil)) context-before "" context-after "oo"))) (should (equal (ert--explain-equal-including-properties-rec -- 2.43.0 --=-=-=-- From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2024 14:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171025466210073 (code B ref 69739); Tue, 12 Mar 2024 14:45:01 +0000 Received: (at 69739) by debbugs.gnu.org; 12 Mar 2024 14:44:22 +0000 Received: from localhost ([127.0.0.1]:43350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk3Mc-0002cP-Hw for submit@debbugs.gnu.org; Tue, 12 Mar 2024 10:44:22 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24074) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk3MM-0002bL-Ee for 69739@debbugs.gnu.org; Tue, 12 Mar 2024 10:44:21 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 829BA83273; Tue, 12 Mar 2024 10:43:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710254605; bh=ZULC6pr2HzIOxq3U9wZ4lqi6EKKTIEd4W14UPJEzneE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iAX4MaEBGEl2vi5jurkCKXvNKNx2YjfJ+2++EGa9yQ35o1tzSIm3qe4VBLJRnPF1K DtnqvJmKvAKXuya8e9cBcAiRq6V/JZkiFOx5tLXHREo9Vr8wg05rPV/jwN7xORflV8 Au1xEmzH/13hcmTFTQXZFLey19CdtqZmV8fGAaZ6AUBSTb0wQWMtOc+hSAn9EvsTMa mSQxJZKurdUKcE4sTBTgggQTew/plG7+JxwA08HEv94OF803Ruz4m/1qhNXoV7Xh+t 4hIIyF1ybR6eKtvJVYU1CRkVC5C2IF6arPaeNGApHYWS1bQwTrJjSFJpJQ/I+d4XYs EZnuGL4g4zygw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 28D12815B7; Tue, 12 Mar 2024 10:43:25 -0400 (EDT) Received: from pastel (69-165-147-56.dsl.teksavvy.com [69.165.147.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 06319120735; Tue, 12 Mar 2024 10:43:24 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86o7bjtuvj.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 12 Mar 2024 15:58:08 +0200") Message-ID: References: <86o7bjtuvj.fsf@gnu.org> Date: Tue, 12 Mar 2024 10:43:24 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.024 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Still, any change as suggested here would be an incompatible change, so >> there's risk it'll break some code out there (`type-of` is not used very >> often, but it *is* used). Another option is to introduce a new function >> which does the same as `type-of` but with changes like the ones above. >> (we could even decide to give it a `cl-generic-` prefix to discourage >> its use elsewhere so we can be more free to change its return value in >> the future). > I'd prefer a non-breaking change, if possible and reasonable. Suggestion for a good name for that new function? Should it make `type-of` obsolete? Stefan From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2024 15:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171025584012866 (code B ref 69739); Tue, 12 Mar 2024 15:04:02 +0000 Received: (at 69739) by debbugs.gnu.org; 12 Mar 2024 15:04:00 +0000 Received: from localhost ([127.0.0.1]:43376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk3fc-0003LR-2l for submit@debbugs.gnu.org; Tue, 12 Mar 2024 11:04:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk3fa-0003LH-I6 for 69739@debbugs.gnu.org; Tue, 12 Mar 2024 11:03:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rk3el-0003oS-GX; Tue, 12 Mar 2024 11:03:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=376+GLNNw/TWCYX1eFgcC6EtuGZVpHGfmpBCWuaJro0=; b=WepXDPH4k3Sz 7mg5NxJB5qHQgaHhIX5Fnmt6O9IglN6pcfE787q2cgxUO8tf0nOkceszv2oOCxxJQeopvILFtYShn i0KiezOGtBiyM+OwyecVLh8KRD3bWbVMiumqpAARw8JYWhWqeFJ1XAcGxN/YkJYCdxbzymIVvKQsw muYa9IDVA7z99/YwgTx2AOFE5qEfoU7h8rjt1czC4lrUzRd2TYPrp9eBaWgnQFJnhWAxJ5Kwgfh9r Sx3Uemo3Fhp5ikHS/53mveLFXHFwVaAfwg75iMs+yXSD34wEy+sM/NV4rK2dylg9cnuZNmI8elcZe Jig25AEX+31j+pNlb/DEAA==; Date: Tue, 12 Mar 2024 17:02:53 +0200 Message-Id: <86il1rtrvm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Tue, 12 Mar 2024 10:43:24 -0400) References: <86o7bjtuvj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 69739@debbugs.gnu.org > Date: Tue, 12 Mar 2024 10:43:24 -0400 > > >> Still, any change as suggested here would be an incompatible change, so > >> there's risk it'll break some code out there (`type-of` is not used very > >> often, but it *is* used). Another option is to introduce a new function > >> which does the same as `type-of` but with changes like the ones above. > >> (we could even decide to give it a `cl-generic-` prefix to discourage > >> its use elsewhere so we can be more free to change its return value in > >> the future). > > I'd prefer a non-breaking change, if possible and reasonable. > > Suggestion for a good name for that new function? cl-generic-type-of is one. > Should it make `type-of` obsolete? I don't have an opinion on this. Depends on how much type-of is used, I guess. Maybe we should wait for the next major release and decide whether to deprecate then? From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2024 15:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171025804427210 (code B ref 69739); Tue, 12 Mar 2024 15:41:02 +0000 Received: (at 69739) by debbugs.gnu.org; 12 Mar 2024 15:40:44 +0000 Received: from localhost ([127.0.0.1]:43425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk4FA-00074n-0X for submit@debbugs.gnu.org; Tue, 12 Mar 2024 11:40:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk4F5-00074X-Ou for 69739@debbugs.gnu.org; Tue, 12 Mar 2024 11:40:42 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 154F844083E; Tue, 12 Mar 2024 11:39:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710257997; bh=1X3J4bvAFstE32nsfoBAh1qrl/RJ8ocW75MchSqKLE0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ir4pwr6SkIj2m5VpSRBZSCxjy678iHQsrc4BguzNfO30avl/bjdtNGc2wvhpyhbmn IdVKitXwq5UV4oICOoc3ZAEts39G3jcr9Vf6iy9niuiV6rd5J+kHVOdgJ+bo9kpAWD uoY6q6z1SDSqSoHgM3/Aj3rX/cchTePZVnWM3rkGiJelNmylpvyYeFq31/TC/BS2ln QaUVSuLVQxGTe/6wbP5E04q1DZ5NQ0HTDRbfstuZLg+8XVVFF3CXARxCpITZmfBi3K xuuofXB7A2RaEoSKwO9hrdXw/pHEOkr8zwpwL2HIi4wziLdwfdolhui2diyMJJ1nNM KEeHbYcnxlJTg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B333D440782; Tue, 12 Mar 2024 11:39:57 -0400 (EDT) Received: from pastel (69-165-147-56.dsl.teksavvy.com [69.165.147.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9298D120675; Tue, 12 Mar 2024 11:39:57 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86il1rtrvm.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 12 Mar 2024 17:02:53 +0200") Message-ID: References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> Date: Tue, 12 Mar 2024 11:39:56 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.038 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> >> Still, any change as suggested here would be an incompatible change, so >> >> there's risk it'll break some code out there (`type-of` is not used very >> >> often, but it *is* used). Another option is to introduce a new function >> >> which does the same as `type-of` but with changes like the ones above. >> >> (we could even decide to give it a `cl-generic-` prefix to discourage >> >> its use elsewhere so we can be more free to change its return value in >> >> the future). >> > I'd prefer a non-breaking change, if possible and reasonable. >> >> Suggestion for a good name for that new function? > > cl-generic-type-of is one. > >> Should it make `type-of` obsolete? > > I don't have an opinion on this. Depends on how much type-of is used, > I guess. Maybe we should wait for the next major release and decide > whether to deprecate then? In my review of uses of `type-of`, I found: - The most common seemed to be when generating error messages like (error "Arg should be an int rather than a %s" (type-of arg)) - The next most common was misuses like (eq (type-of FOO) 'BAR) which should be using `BAR-p` instead (or `cl-typep`). - The next most common was when `type-of` is applied to a struct (i.e. it returns the same as (aref FOO 0)). Since this was new functionality in Emacs-26, I'm surprised at how widespread it is. - There were a few that are combined with case/pcase and would probably be better served by `cl-typecase`. I think that marking it obsolete wouldn't be an option if the new function is named something like `cl-generic-type-of`: it would have to be a more "neutral" name. The reason why I'd like to make it obsolete (if it can't be changed) is to try and avoid having two slightly-different functions where most users don't actually care about the difference. Stefan From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough In-Reply-To: Resent-From: Rudolf Schlatte Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2024 16:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69739@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.171025972730957 (code B ref -1); Tue, 12 Mar 2024 16:09:02 +0000 Received: (at submit) by debbugs.gnu.org; 12 Mar 2024 16:08:47 +0000 Received: from localhost ([127.0.0.1]:43481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk4gI-00083E-Ki for submit@debbugs.gnu.org; Tue, 12 Mar 2024 12:08:46 -0400 Received: from lists.gnu.org ([209.51.188.17]:54120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rk4gH-000835-Ac for submit@debbugs.gnu.org; Tue, 12 Mar 2024 12:08:45 -0400 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 1rk4fe-0005MF-7c for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2024 12:08:06 -0400 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 1rk4fb-0006eJ-5g for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2024 12:08:04 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rk4fX-0001yM-6t for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2024 17:07:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ From: Rudolf Schlatte Date: Tue, 12 Mar 2024 17:07:47 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:xEEbrcB7t3XrdPLrIO0MAC3hrds= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@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.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > * Incompatible Changes in Emacs 30.1 > > +** 'type-of' sometimes returns more precise types. > +More specifically, for nil and t it returns 'null' and 'boolean' > +instead of just 'symbol' and for "subrs", it now returns one of > +'special-form', 'subr-primitive', or 'subr-native-elisp'. Is it true that in all cases, if `(type-of x)' used to return `foo' before the change, `(typep x 'foo)' still returns t after the change? If so, that might be worth mentioning, since it makes fixing broken code easier. From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Mar 2024 11:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.17103309884341 (code B ref 69739); Wed, 13 Mar 2024 11:57:01 +0000 Received: (at 69739) by debbugs.gnu.org; 13 Mar 2024 11:56:28 +0000 Received: from localhost ([127.0.0.1]:44888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkNDf-00017x-L9 for submit@debbugs.gnu.org; Wed, 13 Mar 2024 07:56:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkNDd-00017g-Lx for 69739@debbugs.gnu.org; Wed, 13 Mar 2024 07:56:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rkNCu-0004ww-NK; Wed, 13 Mar 2024 07:55:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sYHfJ00w2Tr1eK3jBcgbZQa6L/yhZNif9nwJA1nW6C8=; b=Khnl/VT/qkNV 5r2tENI902LoD+cguHGVAFSkAk2ve1nUj/dnLbws1y6qucYs1imdgisBk0zOKmqtE3FsBU5m7e6j9 Jv8498iGZsmWUwYnkNYBuzTVEWLeAGf2X9TJX4RNxf2/POgEUfGO1ff5fiWykREV7LMfxUyIQlE5F L2O/hckJWLX66V/9ofOowU/RzL4EoARqdsiaYxpze+5h+JW53gvPVUXkulI/bR9QMNtxTxXf8kEAe Th8NNAb04wKleDuC21WCsXTldzAZsX6njOFwOIdJeCQzVqtylxbPpyBU0HZMD67LL+SM15OHfCtTz LiqtB65jE+2Djr5HgbfjBg==; Date: Wed, 13 Mar 2024 13:55:33 +0200 Message-Id: <86a5n2tkga.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Tue, 12 Mar 2024 11:39:56 -0400) References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 69739@debbugs.gnu.org > Date: Tue, 12 Mar 2024 11:39:56 -0400 > > I think that marking it obsolete wouldn't be an option if the new > function is named something like `cl-generic-type-of`: it would have to > be a more "neutral" name. I just picked up your own suggestion. I'm not wedded to that name, so if there are better alternatives, let's hear them. > The reason why I'd like to make it obsolete (if it can't be changed) is > to try and avoid having two slightly-different functions where most > users don't actually care about the difference. Sure, but we don't usually declare such APIs obsolete the very day the better one is introduced. We usually let the community some time to adjust, and maybe tell us where our ideas were wrong or need some adjustments. From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Mar 2024 22:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Rudolf Schlatte Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.17103679806246 (code B ref 69739); Wed, 13 Mar 2024 22:13:01 +0000 Received: (at 69739) by debbugs.gnu.org; 13 Mar 2024 22:13:00 +0000 Received: from localhost ([127.0.0.1]:47552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkWqK-0001cg-6Z for submit@debbugs.gnu.org; Wed, 13 Mar 2024 18:13:00 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8353) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkWqH-0001cN-Ax for 69739@debbugs.gnu.org; Wed, 13 Mar 2024 18:12:59 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0E4E91000DD; Wed, 13 Mar 2024 18:12:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710367934; bh=ijZEIgP+2TTfsjwO1NQG47vxZGlvF/inl76iiJI35V0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=d/xT/02PNHXDy+x+ek0n/WlIXlm/wXKmnLtcVc4EZCIlbOJAjqFV6wFKWt3HrOGNF SFeqFxhk4354KKrX8Dr8iPialdEqCTKn44YqU7sNTendn10S4iSAzHUgFyqvBeXS+T PAft5qOSJHXPD4o5Gg/BbbpU2bLt7LeGHHm94L206lB4huOmV529fY7AZKjd3LwTr6 vFkHNO+L1nidUDZrzXrOgMjX+gFBV7VPlAjWf6WINtBIKQm6eHrhmV/GuP9CsRRzq4 3GBvSewJOMCxNBI8M03yPqQjuOclmxW3gT1RDvUeAy8IK3Z8BlagoU6R1Eq+KK1HZQ ISL4QxF872/gQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E324310004A; Wed, 13 Mar 2024 18:12:14 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BEBD11201E7; Wed, 13 Mar 2024 18:12:14 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Rudolf Schlatte's message of "Tue, 12 Mar 2024 17:07:47 +0100") Message-ID: References: Date: Wed, 13 Mar 2024 18:10:09 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.102 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> * Incompatible Changes in Emacs 30.1 >> >> +** 'type-of' sometimes returns more precise types. >> +More specifically, for nil and t it returns 'null' and 'boolean' >> +instead of just 'symbol' and for "subrs", it now returns one of >> +'special-form', 'subr-primitive', or 'subr-native-elisp'. > > Is it true that in all cases, if `(type-of x)' used to return `foo' > before the change, `(typep x 'foo)' still returns t after the change? > If so, that might be worth mentioning, since it makes fixing broken code > easier. Yes. But in any case, it seems we'll go with a different patch which leaves `type-of` unchanged. Stefan From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Mar 2024 16:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.17104354122293 (code B ref 69739); Thu, 14 Mar 2024 16:57:01 +0000 Received: (at 69739) by debbugs.gnu.org; 14 Mar 2024 16:56:52 +0000 Received: from localhost ([127.0.0.1]:50504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkoNu-0000ao-Fw for submit@debbugs.gnu.org; Thu, 14 Mar 2024 12:56:52 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkoNr-0000aY-Hi for 69739@debbugs.gnu.org; Thu, 14 Mar 2024 12:56:49 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1435810004C; Thu, 14 Mar 2024 12:56:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710435364; bh=deDhV48JJZPXgt2rrOl16FVKdBc+RFa6LpDLQ63wu/U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G1Qx1YgPwebYEtkJnDCsbi4pDBjF1EPnZVzjFCooqaWGLZSYrVl1PpFpZaLafBa+5 xoZ60X7ULVA+i8oSy2XaDgvUwFa1jpNlwr8SMs8cv4dL2umkPCEIIjxCS9YRUVggaZ 8c6Z5Xl7e30uJY/b8D34pZdonASqZiX0yotJ8qGPdiZVRobnmD+wzDgLct7+oNIzsI tiEodbbnehfS+VYhNHWPDY1ho/emaJxW8CPJLa3CVBiTiCGXDa20Go5kgx+rB97vQh F8iWCB1xTLsxn1JBBs60QLA3WWmMvS5EQM6SvWlicTcjzNRQCmaGKVPs5g/GwvBh+c APpR43VNEQ3lg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 40B77100046; Thu, 14 Mar 2024 12:56:04 -0400 (EDT) Received: from alfajor (bras-base-mtrlpq0776w-grc-27-65-94-77-40.dsl.bell.ca [65.94.77.40]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 300961201A9; Thu, 14 Mar 2024 12:56:04 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86a5n2tkga.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Mar 2024 13:55:33 +0200") Message-ID: References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> Date: Thu, 14 Mar 2024 12:56:03 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.750 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain OK, here's a new patch. I ended up with `cl-type-of` as the name of the new function (after all, it tries to better match the expected semantics of Common Lisp's `type-of`). Comments? Objections? Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-cl-type-of-New-function-to-return-more-precise-types.patch >From a1d656bf089af3e55fd08ef5ed3e33f207360593 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 12 Mar 2024 09:26:24 -0400 Subject: [PATCH 1/2] (cl-type-of): New function to return more precise types (bug#69739) * src/data.c (Fcl_type_of): New function, extracted from `Ftype_of`. Make it return more precise types for symbols, integers, and subrs. (Ftype_of): Use it. (syms_of_data): Define the corresponding new symbols and defsubr the new function. * src/comp.c (emit_limple_insn): Use `Fcl_type_of`. * lisp/emacs-lisp/cl-preloaded.el (subr): Demote it to `atom`. (subr-native-elisp, subr-primitive): Add `compiled-function` as parent instead. (special-form): New type. * lisp/obsolete/eieio-core.el (cl--generic-struct-tag): * lisp/emacs-lisp/cl-generic.el (cl--generic-typeof-generalizer): Use `cl-type-of`. cl--generic--unreachable-types): Update accordingly. --- etc/NEWS | 5 +++++ lisp/emacs-lisp/cl-generic.el | 6 ++--- lisp/emacs-lisp/cl-preloaded.el | 12 +++++----- lisp/emacs-lisp/eieio-core.el | 2 +- src/comp.c | 2 +- src/data.c | 40 ++++++++++++++++++++++++++++----- 6 files changed, 50 insertions(+), 17 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 2985169ea91..17f6916cebf 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1628,6 +1628,11 @@ values. * Lisp Changes in Emacs 30.1 +** New function 'cl-type-of'. +This function is like 'type-of' except that it sometimes returns +a more precise type. For example, for nil and t it returns 'null' +and 'boolean' respectively, instead of just 'symbol'. + ** Built-in types have now corresponding classes. At the Lisp level, this means that things like (cl-find-class 'integer) will now return a class object, and at the UI level it means that diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el index 613ecf82a92..62abe8d1589 100644 --- a/lisp/emacs-lisp/cl-generic.el +++ b/lisp/emacs-lisp/cl-generic.el @@ -1334,8 +1334,7 @@ cl-generic-generalizers (defconst cl--generic--unreachable-types ;; FIXME: Try to make that list empty? - '(fixnum bignum boolean keyword - special-form subr-primitive subr-native-elisp) + '(keyword) "Built-in classes on which we cannot dispatch for technical reasons.") (defun cl--generic-type-specializers (tag &rest _) @@ -1345,8 +1344,7 @@ cl--generic-type-specializers (cl--class-allparents class))))) (cl-generic-define-generalizer cl--generic-typeof-generalizer - ;; FIXME: We could also change `type-of' to return `null' for nil. - 10 (lambda (name &rest _) `(if ,name (type-of ,name) 'null)) + 10 (lambda (name &rest _) `(cl-type-of ,name)) #'cl--generic-type-specializers) (cl-defmethod cl-generic-generalizers :extra "typeof" (type) diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 515aa99549d..3e89afea452 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -339,8 +339,6 @@ cl--define-built-in-type ',parents)))))) ;; FIXME: Our type DAG has various quirks: -;; - `subr' says it's a `compiled-function' but that's not true -;; for those subrs that are special forms! ;; - Some `keyword's are also `symbol-with-pos' but that's not reflected ;; in the DAG. ;; - An OClosure can be an interpreted function or a `byte-code-function', @@ -428,15 +426,17 @@ compiled-function "Abstract type of functions that have been compiled.") (cl--define-built-in-type byte-code-function (compiled-function) "Type of functions that have been byte-compiled.") -(cl--define-built-in-type subr (compiled-function) +(cl--define-built-in-type subr (atom) "Abstract type of functions compiled to machine code.") (cl--define-built-in-type module-function (function) "Type of functions provided via the module API.") (cl--define-built-in-type interpreted-function (function) "Type of functions that have not been compiled.") -(cl--define-built-in-type subr-native-elisp (subr) - "Type of function that have been compiled by the native compiler.") -(cl--define-built-in-type subr-primitive (subr) +(cl--define-built-in-type special-form (subr) + "Type of the core syntactic elements of the Emacs Lisp language.") +(cl--define-built-in-type subr-native-elisp (subr compiled-function) + "Type of functions that have been compiled by the native compiler.") +(cl--define-built-in-type subr-primitive (subr compiled-function) "Type of functions hand written in C.") (unless (cl--class-parents (cl--find-class 'cl-structure-object)) diff --git a/lisp/emacs-lisp/eieio-core.el b/lisp/emacs-lisp/eieio-core.el index a2f7c4172a3..cf8bd749f2a 100644 --- a/lisp/emacs-lisp/eieio-core.el +++ b/lisp/emacs-lisp/eieio-core.el @@ -1046,7 +1046,7 @@ 'inconsistent-class-hierarchy (defun cl--generic-struct-tag (name &rest _) ;; Use exactly the same code as for `typeof'. - `(if ,name (type-of ,name) 'null)) + `(cl-type-of ,name)) (cl-generic-define-generalizer eieio--generic-generalizer ;; Use the exact same tagcode as for cl-struct, so that methods diff --git a/src/comp.c b/src/comp.c index 3f989c722d4..76cf1f3ab6e 100644 --- a/src/comp.c +++ b/src/comp.c @@ -2442,7 +2442,7 @@ emit_limple_insn (Lisp_Object insn) { Lisp_Object arg1 = arg[1]; - if (EQ (Ftype_of (arg1), Qcomp_mvar)) + if (EQ (Fcl_type_of (arg1), Qcomp_mvar)) res = emit_mvar_rval (arg1); else if (EQ (FIRST (arg1), Qcall)) res = emit_limple_call (XCDR (arg1)); diff --git a/src/data.c b/src/data.c index 35f4c82c68f..a961dd3108c 100644 --- a/src/data.c +++ b/src/data.c @@ -193,16 +193,37 @@ DEFUN ("null", Fnull, Snull, 1, 1, 0, DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, doc: /* Return a symbol representing the type of OBJECT. The symbol returned names the object's basic type; -for example, (type-of 1) returns `integer'. */) +for example, (type-of 1) returns `integer'. +Contrary to `cl-type-of' the returned type is not always the most +precise type possible, because instead this function tries to preserve +compatibility with the return value of previous Emacs versions. */) + (Lisp_Object object) +{ + return SYMBOLP (object) ? Qsymbol + : INTEGERP (object) ? Qinteger + : SUBRP (object) ? Qsubr + : Fcl_type_of (object); +} + +DEFUN ("cl-type-of", Fcl_type_of, Scl_type_of, 1, 1, 0, + doc: /* Return a symbol representing the type of OBJECT. +The symbol returned names the most specific possible type of the object. +for example, (object-type nil) returns `null'. +The specific type returned may change depending on Emacs versions, +so we recommend you use `cl-typep', `cl-typecase', or other predicates +rather than compare the return value of this function against +a fixed set of types. */) (Lisp_Object object) { switch (XTYPE (object)) { case_Lisp_Int: - return Qinteger; + return Qfixnum; case Lisp_Symbol: - return Qsymbol; + return NILP (object) ? Qnull + : EQ (object, Qt) ? Qboolean + : Qsymbol; case Lisp_String: return Qstring; @@ -215,7 +236,7 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, switch (PSEUDOVECTOR_TYPE (XVECTOR (object))) { case PVEC_NORMAL_VECTOR: return Qvector; - case PVEC_BIGNUM: return Qinteger; + case PVEC_BIGNUM: return Qbignum; case PVEC_MARKER: return Qmarker; case PVEC_SYMBOL_WITH_POS: return Qsymbol_with_pos; case PVEC_OVERLAY: return Qoverlay; @@ -224,7 +245,10 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, case PVEC_WINDOW_CONFIGURATION: return Qwindow_configuration; case PVEC_PROCESS: return Qprocess; case PVEC_WINDOW: return Qwindow; - case PVEC_SUBR: return Qsubr; + case PVEC_SUBR: + return XSUBR (object)->max_args == UNEVALLED ? Qspecial_form + : SUBR_NATIVE_COMPILEDP (object) ? Qsubr_native_elisp + : Qsubr_primitive; case PVEC_COMPILED: return Qcompiled_function; case PVEC_BUFFER: return Qbuffer; case PVEC_CHAR_TABLE: return Qchar_table; @@ -4202,7 +4226,9 @@ #define PUT_ERROR(sym, tail, msg) \ "Variable binding depth exceeds max-specpdl-size"); /* Types that type-of returns. */ + DEFSYM (Qboolean, "boolean"); DEFSYM (Qinteger, "integer"); + DEFSYM (Qbignum, "bignum"); DEFSYM (Qsymbol, "symbol"); DEFSYM (Qstring, "string"); DEFSYM (Qcons, "cons"); @@ -4218,6 +4244,9 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qprocess, "process"); DEFSYM (Qwindow, "window"); DEFSYM (Qsubr, "subr"); + DEFSYM (Qspecial_form, "special-form"); + DEFSYM (Qsubr_primitive, "subr-primitive"); + DEFSYM (Qsubr_native_elisp, "subr-native-elisp"); DEFSYM (Qcompiled_function, "compiled-function"); DEFSYM (Qbuffer, "buffer"); DEFSYM (Qframe, "frame"); @@ -4255,6 +4284,7 @@ #define PUT_ERROR(sym, tail, msg) \ defsubr (&Seq); defsubr (&Snull); defsubr (&Stype_of); + defsubr (&Scl_type_of); defsubr (&Slistp); defsubr (&Snlistp); defsubr (&Sconsp); -- 2.43.0 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Followup-changes-to-cl-type-of.patch >From 637b22ee275762e3a88342f7c0c1e9a997f2ed97 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Thu, 14 Mar 2024 12:49:08 -0400 Subject: [PATCH 2/2] Followup changes to `cl-type-of` These changes came up while working on `cl-type-of` but are not directly related to the new `cl-type-of`. The BASE_PURESIZE bump was needed at some point on one of my machine, not sure why. * src/puresize.h (BASE_PURESIZE): Bump up. * src/sqlite.c (bind_value): Don't use `Ftype_of`. * lisp/emacs-lisp/seq.el (seq-remove-at-position): Simplify. * lisp/emacs-lisp/cl-preloaded.el (finalizer): New (previously missing) type. * doc/lispref/objects.texi (Type Predicates): Minor tweaks. --- doc/lispref/objects.texi | 6 +++--- lisp/emacs-lisp/cl-preloaded.el | 1 + lisp/emacs-lisp/seq.el | 3 +-- src/lisp.h | 6 ++---- src/puresize.h | 2 +- src/sqlite.c | 17 ++++++----------- 6 files changed, 14 insertions(+), 21 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 279f449a994..804f52ba8ac 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -1485,8 +1485,8 @@ Type Descriptors @subsection Type Descriptors A @dfn{type descriptor} is a @code{record} which holds information -about a type. Slot 1 in the record must be a symbol naming the type, and -@code{type-of} relies on this to return the type of @code{record} +about a type. The first slot in the record must be a symbol naming the type, +and @code{type-of} relies on this to return the type of @code{record} objects. No other type descriptor slot is used by Emacs; they are free for use by Lisp extensions. @@ -2175,7 +2175,7 @@ Type Predicates function @code{type-of}. Recall that each object belongs to one and only one primitive type; @code{type-of} tells you which one (@pxref{Lisp Data Types}). But @code{type-of} knows nothing about non-primitive -types. In most cases, it is more convenient to use type predicates than +types. In most cases, it is preferable to use type predicates than @code{type-of}. @defun type-of object diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 3e89afea452..0e8704a93c1 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -365,6 +365,7 @@ frame (cl--define-built-in-type buffer atom) (cl--define-built-in-type window atom) (cl--define-built-in-type process atom) +(cl--define-built-in-type finalizer atom) (cl--define-built-in-type window-configuration atom) (cl--define-built-in-type overlay atom) (cl--define-built-in-type number-or-marker atom diff --git a/lisp/emacs-lisp/seq.el b/lisp/emacs-lisp/seq.el index 20077db9e60..a20cff16982 100644 --- a/lisp/emacs-lisp/seq.el +++ b/lisp/emacs-lisp/seq.el @@ -362,8 +362,7 @@ seq-remove-at-position The result is a sequence of the same type as SEQUENCE." (seq-concatenate - (let ((type (type-of sequence))) - (if (eq type 'cons) 'list type)) + (if (listp sequence) 'list (type-of sequence)) (seq-subseq sequence 0 n) (seq-subseq sequence (1+ n)))) diff --git a/src/lisp.h b/src/lisp.h index f353e4956eb..f86758c88fb 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -569,10 +569,8 @@ #define ENUM_BF(TYPE) enum TYPE your object -- this way, the same object could be used to represent several disparate C structures. - In addition, you need to add switch branches in data.c for Ftype_of. - - You also need to add the new type to the constant - `cl--typeof-types' in lisp/emacs-lisp/cl-preloaded.el. */ + In addition, you need to add switch branches in data.c for Fcl_type_of + and `cl--define-builtin-type` in lisp/emacs-lisp/cl-preloaded.el. */ /* A Lisp_Object is a tagged pointer or integer. Ordinarily it is a diff --git a/src/puresize.h b/src/puresize.h index ac5d2da30dc..2a716872832 100644 --- a/src/puresize.h +++ b/src/puresize.h @@ -47,7 +47,7 @@ #define SITELOAD_PURESIZE_EXTRA 0 #endif #ifndef BASE_PURESIZE -#define BASE_PURESIZE (2750000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) +#define BASE_PURESIZE (3000000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) #endif /* Increase BASE_PURESIZE by a ratio depending on the machine's word size. */ diff --git a/src/sqlite.c b/src/sqlite.c index 7a018b28aa4..261080da673 100644 --- a/src/sqlite.c +++ b/src/sqlite.c @@ -349,9 +349,7 @@ bind_values (sqlite3 *db, sqlite3_stmt *stmt, Lisp_Object values) value = XCAR (values); values = XCDR (values); } - Lisp_Object type = Ftype_of (value); - - if (EQ (type, Qstring)) + if (STRINGP (value)) { Lisp_Object encoded; bool blob = false; @@ -385,14 +383,11 @@ bind_values (sqlite3 *db, sqlite3_stmt *stmt, Lisp_Object values) SSDATA (encoded), SBYTES (encoded), NULL); } - else if (EQ (type, Qinteger)) - { - if (BIGNUMP (value)) - ret = sqlite3_bind_int64 (stmt, i + 1, bignum_to_intmax (value)); - else - ret = sqlite3_bind_int64 (stmt, i + 1, XFIXNUM (value)); - } - else if (EQ (type, Qfloat)) + else if (FIXNUMP (value)) + ret = sqlite3_bind_int64 (stmt, i + 1, XFIXNUM (value)); + else if (BIGNUMP (value)) + ret = sqlite3_bind_int64 (stmt, i + 1, bignum_to_intmax (value)); + else if (FLOATP (value)) ret = sqlite3_bind_double (stmt, i + 1, XFLOAT_DATA (value)); else if (NILP (value)) ret = sqlite3_bind_null (stmt, i + 1); -- 2.43.0 --=-=-=-- From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2024 09:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69739@debbugs.gnu.org Cc: eliz@gnu.org, monnier@iro.umontreal.ca X-Debbugs-Original-To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" X-Debbugs-Original-Cc: Eli Zaretskii , Stefan Monnier , 69739@debbugs.gnu.org Received: via spool by submit@debbugs.gnu.org id=B.171049581313764 (code B ref -1); Fri, 15 Mar 2024 09:44:01 +0000 Received: (at submit) by debbugs.gnu.org; 15 Mar 2024 09:43:33 +0000 Received: from localhost ([127.0.0.1]:52074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl469-0003Zw-94 for submit@debbugs.gnu.org; Fri, 15 Mar 2024 05:43:33 -0400 Received: from lists.gnu.org ([209.51.188.17]:57002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl466-0003Zn-J3 for submit@debbugs.gnu.org; Fri, 15 Mar 2024 05:43:32 -0400 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 1rl45V-00039d-Ma for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2024 05:42:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rl45V-0006PJ-0j; Fri, 15 Mar 2024 05:42:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=Vbd3mfPQpO6BM5SHfxQwpFu89L/H3PIFeV8WaZRtrYI=; b=JGqVAH5S4IWChMU5JZ37 gRGyIZBUem8ivn8KUlECTdqL91N4e3QvbJXvPqbyBu9oiCMjBfcWAShvX8fRKHIny8wIrVguxWhvL TwhPxy4pqlNt0V5AlslEGlr9m4KU1E+ZyqFJkwiIREg+NdNCsx1GeZh4zsmT5gwMBUTueEj6vywJK HwhOC8LeehfkWrQxM9E5DDTLQFIdvPjDaa9qNdfYbgMFYNEdiD67EayR+q6GvBQAODCoXMNdQLhtH Ah6n4B3Yxb/faajlvXQ5SwmnYFr+caHgtfRVB8mnNOSlx/Wd4c9Ubz/uyYss/huy6TxtIx6tvs4q0 VyKpFm/akEGCVA==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rl45U-0005eE-9s; Fri, 15 Mar 2024 05:42:52 -0400 From: Andrea Corallo In-Reply-To: (Stefan Monnier via's message of "Thu, 14 Mar 2024 12:56:03 -0400") References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> Date: Fri, 15 Mar 2024 05:42:52 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > OK, here's a new patch. > I ended up with `cl-type-of` as the name of the new function (after > all, it tries to better match the expected semantics of Common Lisp's > `type-of`). > > Comments? Objections? FWIW: I think this is a good change and agree `cl-type-of` is a good name for the new function. I'm just wondering if we should have some test this. Bests! Andrea From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2024 09:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Stefan Monnier , 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171049634014962 (code B ref 69739); Fri, 15 Mar 2024 09:53:02 +0000 Received: (at 69739) by debbugs.gnu.org; 15 Mar 2024 09:52:20 +0000 Received: from localhost ([127.0.0.1]:52091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl4Ed-0003tF-KP for submit@debbugs.gnu.org; Fri, 15 Mar 2024 05:52:19 -0400 Received: from mail-ej1-f50.google.com ([209.85.218.50]:40132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl4Eb-0003t2-9X for 69739@debbugs.gnu.org; Fri, 15 Mar 2024 05:52:18 -0400 Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a4692a301edso4412366b.0 for <69739@debbugs.gnu.org>; Fri, 15 Mar 2024 02:51:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710496295; x=1711101095; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BOXuZ4YFG/C4v6t+m+ILaFNhA9oQ8k2DWabKWCyXz6Q=; b=cdL0vWsVn2JUcIXssS1sLDdY1iPWkOA1gtnUYs35bEs4sQkalsConYjyXqEHKAHxbD l6f7p3Y/jPDvq9tGn208WqFF5lvV1YU1pD6xQc1q0pQzxdt+7B7yEla2rwvzUx4p6z14 LrLGbQM1BQ4vBYE2jAQp6+TYIbWPwW2/Fzjlryi8tAHCfFqyf75IknGXJv4+TDQGmUMV 5P3ubWCS6yAYtZHirroilfPvU18D63V2LLRrXk0aFUXvXSj1sqWh0B5Jqkw+RtPftdK3 Sm4N1FGpQn8hUjPKc0izzSWleNw51x6WQIABXK4JquvtA55eqZp8ZtFEpIVK9rECvMmr 84Ng== X-Forwarded-Encrypted: i=1; AJvYcCXPO0CdFUv+BBI1/3wUUXmdPw/kNFr99zge+pi/WBk8CX+44JS5MP6uVkJaiipoUGx2X3WFcBVnVu/DycYO4gP3Ns3eKW8= X-Gm-Message-State: AOJu0YzjbT0N5dGioiNCcRNVz22r2oNB3DMiutAcWWeitp6wHSaB5x0f EIqIMZW1oBOFyeQytJgd2tkCIiXKr7f3FlgpSRNYyTqsNn8oxQcs X-Google-Smtp-Source: AGHT+IFPyxy6Wu8IefognJpAZWdkHK9iwtzHhEVZKv40mY0IGNfWmgR8/2UDSBLKD48XD6AOHcPVzg== X-Received: by 2002:a17:907:7750:b0:a45:dd14:707a with SMTP id kx16-20020a170907775000b00a45dd14707amr3116756ejc.1.1710496294823; Fri, 15 Mar 2024 02:51:34 -0700 (PDT) Received: from localhost ([2001:620:618:5c0:2:80b3:0:e5c]) by smtp.gmail.com with ESMTPSA id my10-20020a1709065a4a00b00a46268fce59sm1534086ejc.165.2024.03.15.02.51.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 02:51:34 -0700 (PDT) From: "Basil L. Contovounesios" In-Reply-To: (Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors"'s message of "Thu, 14 Mar 2024 12:56:03 -0400") References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> Date: Fri, 15 Mar 2024 10:51:33 +0100 Message-ID: <877ci3stzu.fsf@epfl.ch> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Stefan Monnier [2024-03-14 12:56 -0400] wrote: > I ended up with `cl-type-of` as the name of the new function (after > all, it tries to better match the expected semantics of Common Lisp's > `type-of`). > > Comments? Objections? No objections here, just one question: did you consider extending type-of with an optional argument instead of introducing cl-type-of? Or would that be too messy? Thanks, -- Basil From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2024 10:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69739@debbugs.gnu.org Cc: eliz@gnu.org, monnier@iro.umontreal.ca Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171050012221768 (code B ref 69739); Fri, 15 Mar 2024 10:56:01 +0000 Received: (at 69739) by debbugs.gnu.org; 15 Mar 2024 10:55:22 +0000 Received: from localhost ([127.0.0.1]:52123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl5De-0005f2-JH for submit@debbugs.gnu.org; Fri, 15 Mar 2024 06:55:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl5Da-0005en-RV for 69739@debbugs.gnu.org; Fri, 15 Mar 2024 06:55:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rl5Cv-0002mU-8q; Fri, 15 Mar 2024 06:54:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=9DdI6T+lFO9H6sIgjc0YQWS5mLprm+z1qvOJE9d/Zo8=; b=MJbsCjMZ95TI72MUtNH+ R0xCcp24EPhJq2/h+/uNC0nvboG5L1kSVYS83rD0ymiddfoYsGnBEmP1fN8HztqUq+tMQ/AIwKTTK zL0XDlklbXbWfYyvy+A3huN7NaqlgYgyBd71KEtd73XaQecAlCSExIdi4l61C4vfxVEM67c89QWJz uKhUWpDFOQ5khVtMXIpDtSKFwt6mjXO9Ur+SEC/CC2BUDL13fb9h9XlzCTnisX+Hj7M6T2wCoxbN8 Lu9G149Kv5revySeG/5rkvHsD5aRtSoWBrkuZn23KPx92Cm/y+1rRHrYGzp2OmaLmiOSTWGSqc9Tn OIzek9ccyyfBfw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rl5Cu-0001fx-LW; Fri, 15 Mar 2024 06:54:36 -0400 From: Andrea Corallo In-Reply-To: (Andrea Corallo's message of "Fri, 15 Mar 2024 05:42:52 -0400") References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> Date: Fri, 15 Mar 2024 06:54:36 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Andrea Corallo writes: > Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >> OK, here's a new patch. >> I ended up with `cl-type-of` as the name of the new function (after >> all, it tries to better match the expected semantics of Common Lisp's >> `type-of`). >> >> Comments? Objections? > > FWIW: I think this is a good change and agree `cl-type-of` is a good > name for the new function. I'm just wondering if we should have some > test this. ^^^ to cover Andrea From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2024 11:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171050350516079 (code B ref 69739); Fri, 15 Mar 2024 11:52:02 +0000 Received: (at 69739) by debbugs.gnu.org; 15 Mar 2024 11:51:45 +0000 Received: from localhost ([127.0.0.1]:52219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl66C-0004BH-JS for submit@debbugs.gnu.org; Fri, 15 Mar 2024 07:51:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl66A-0004B2-23 for 69739@debbugs.gnu.org; Fri, 15 Mar 2024 07:51:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rl65T-0006bw-R9; Fri, 15 Mar 2024 07:50:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3pkrwDfsyy1x3DnJiSt1WfQXstQill77vf7oP3mI+Bk=; b=nGDsrEdfZ9n5 lpTzihUCWBViAGteJzoF838YoL+aluqxYHxkS6Qe/70202JgOKfrA+TzDMfmF29NXfZNkX3H4EJen Iefk6TcdkJwveYWEyS5g2xEG8Kgv1ao81TP6N2xwHCxltD9hOog5qa5vkT0KmQ6IbKUNPR9Vswy1W kc/iddsImkCdcvbK9KwX52QnemAbXMI98VJ2XrQB+MT81X8t9y1RPz6d9yoGQV7l8Nk2gAgK+VynS b2fKsu9qeZfBlfoQ0Y16Fhd2+K+LCZXTt56kHChiJOrwY00Crij3qV22Cz0EMJYMT5TWRmVoYtvBM a1/EqUk7KBFet3/JLQNxcA==; Date: Fri, 15 Mar 2024 13:50:56 +0200 Message-Id: <86frwr90in.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Thu, 14 Mar 2024 12:56:03 -0400) References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 69739@debbugs.gnu.org > Date: Thu, 14 Mar 2024 12:56:03 -0400 > > OK, here's a new patch. > I ended up with `cl-type-of` as the name of the new function (after > all, it tries to better match the expected semantics of Common Lisp's > `type-of`). > > Comments? Objections? Should we document this new function in the ELisp manual? From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2024 14:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Basil L. Contovounesios" , Andrea Corallo , Eli Zaretskii Cc: 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.17105118018746 (code B ref 69739); Fri, 15 Mar 2024 14:10:02 +0000 Received: (at 69739) by debbugs.gnu.org; 15 Mar 2024 14:10:01 +0000 Received: from localhost ([127.0.0.1]:53544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl8G0-0002H0-Tf for submit@debbugs.gnu.org; Fri, 15 Mar 2024 10:10:01 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl8Fw-0002Gl-Tr for 69739@debbugs.gnu.org; Fri, 15 Mar 2024 10:10:00 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C8D4180E77; Fri, 15 Mar 2024 10:09:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710511753; bh=nseZhX9PyL73HwOF12SIhTAtRn4H9Amc9arkcFT4BUw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SZooPtF+QVw0v3NTsT0dlzm+EwuN/lSNw67F8UCNJfwjrfDF0Dqior6/16QhvpoYn zt2aIVAa3tgfwH5Q6f58tjVyC3fSUsnqWr3oPqxN+TuFSXKJzMygLgLzsnXrf2vfnZ cRBJ5uHSsQkdALKvHKtHfpJ+Dfi0z76is4B6KrhYRrdOpA3NkjqgDWjDzYbpK1pE7z ieE1CfdrqHoSyWqj9I10O73uJbdapJLIQgeCss8TKj3OaFSYQUkXKT5qc8hyfWYxLc dJAOcoHCVUwBCuY0kmSrug+S/3PxONAldpjI6QObCjUVuCl3rYm7odZ5XmquWGOmj8 tyAiU5ubNtTBQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5D13580CD7; Fri, 15 Mar 2024 10:09:13 -0400 (EDT) Received: from pastel (unknown [216.154.27.181]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 30290120306; Fri, 15 Mar 2024 10:09:13 -0400 (EDT) From: Stefan Monnier In-Reply-To: <877ci3stzu.fsf@epfl.ch> (Basil L. Contovounesios's message of "Fri, 15 Mar 2024 10:51:33 +0100") Message-ID: References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> <877ci3stzu.fsf@epfl.ch> Date: Fri, 15 Mar 2024 10:09:11 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.084 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Basil L. Contovounesios [2024-03-15 10:51:33] wrote: > No objections here, just one question: did you consider extending > type-of with an optional argument instead of introducing cl-type-of? > Or would that be too messy? I did. I decided to introduce a new function for the following reasons: - The main use for the new function is in the dispatch code of `cl-generic` where it's on the critical path, so one less argument is better than one more argument. Not sure how much impact it would really have, tho, so it's not a very strong argument. - I don't know of a good reason to prefer the `type-of` behavior other than backward compatibility, and requiring a non-nil arg to get the "good" behavior would make it difficult to get rid of the legacy behavior. Andrea Corallo [2024-03-15 06:54:36] wrote: > FWIW: I think this is a good change and agree `cl-type-of` is a good > name for the new function. I'm just wondering if we should have some > test to cover this. Are you suggesting that my code can be anything else than perfect? More seriously, I couldn't think of a good test, but I'll try harder. Eli Zaretskii [2024-03-15 13:50:56] wrote: > Should we document this new function in the ELisp manual? I was thinking that we should do that only when/if we demote `type-of` (`(cl-)type-of` is an operation that's used very rarely, so I think it's best to keep it to a minimum in the manual), Of course, the name also begs the question whether it should be in the ELisp manual or in the CL manual. In a previous version of the patch I had it documented alongside `type-of`, so I can easily dig that up if you think it's best. Stefan From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2024 15:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: acorallo@gnu.org, basil@contovou.net, 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171051598127321 (code B ref 69739); Fri, 15 Mar 2024 15:20:02 +0000 Received: (at 69739) by debbugs.gnu.org; 15 Mar 2024 15:19:41 +0000 Received: from localhost ([127.0.0.1]:53595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl9LQ-00076b-ER for submit@debbugs.gnu.org; Fri, 15 Mar 2024 11:19:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rl9LH-00076B-LR for 69739@debbugs.gnu.org; Fri, 15 Mar 2024 11:19:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rl9Kb-0001CE-Ko; Fri, 15 Mar 2024 11:18:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=drgk5DDXfsbQRWqYReNo8vONLLHFdONDoWul1Tl0aX4=; b=UC9HTY1qQcaz jaxduOcu6+xV/nIBWG0QEYq/6Bs27g0/+ebfQalqeKz5JLnV5+In2Si7HcZDUFQW5q36uxhbVnlLr 0G2FOR3txL14+ZUWaVpvrbfolKn4+dSsEQP86PGqn9ZC7eXq72T/oI+V/L1YSPFZt7prdl1IwVNy6 e3WcTKo+gLoPzzKJgiG/K76xcXYeR9pB8NbJ9+sfC+QcZsxlgrDrlGf8uZGQKjOmyaITmKYB/O+bg LSudsLr1DKAaYneojLBRR5Mx0zkjQcYeAF8XVm6BNYnwd2CepngdTJV0lErgd8oXrnS7JjY34mtUr Dg9WCUJu9YLfmRog5AcRuQ==; Date: Fri, 15 Mar 2024 17:18:43 +0200 Message-Id: <86zfuz7cbw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 15 Mar 2024 10:09:11 -0400) References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> <877ci3stzu.fsf@epfl.ch> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 69739@debbugs.gnu.org > Date: Fri, 15 Mar 2024 10:09:11 -0400 > > Eli Zaretskii [2024-03-15 13:50:56] wrote: > > Should we document this new function in the ELisp manual? > > I was thinking that we should do that only when/if we demote `type-of` > (`(cl-)type-of` is an operation that's used very rarely, so I think it's > best to keep it to a minimum in the manual), > Of course, the name also begs the question whether it should be in the > ELisp manual or in the CL manual. > > In a previous version of the patch I had it documented alongside > `type-of`, so I can easily dig that up if you think it's best. Yes, I think we should document it near type-of, as the explanation when and why to prefer cl-type-of is quite simple and easily understandable. From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Mar 2024 22:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, basil@contovou.net, 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171071460110488 (code B ref 69739); Sun, 17 Mar 2024 22:30:03 +0000 Received: (at 69739) by debbugs.gnu.org; 17 Mar 2024 22:30:01 +0000 Received: from localhost ([127.0.0.1]:43641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rlz0y-0002j1-1W for submit@debbugs.gnu.org; Sun, 17 Mar 2024 18:30:01 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rlz0v-0002ic-FT for 69739@debbugs.gnu.org; Sun, 17 Mar 2024 18:29:58 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D41F380DB3; Sun, 17 Mar 2024 18:29:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710714551; bh=WT21MX+SQpSWK3shHl5wbE6pL1ztiZ89Bs/H8Laa56M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ME26K8luoYu94ToIRO3i07oQ9uX71ciF5fUvRihgUcXUwYNw3kg9kK2ueTdS0JlX8 1No8GU7CJgSh7R1eBGLMzn5B5d0bnTXgX8wjfwFTCsbQkOivO6sU9fzGGHkYdpY3y5 PrIQsb9PvGvsn9gTh8BYl79tBBm6QNWyOHxelKuKxLTYqkMhpi97tlhLstgY42Me8o SMnjY6JjPlaUeAmJj9tPo2KNYjexsKJGwA0tXrsMhCMa8stwFu3g6UI01SAzNNBlDm fbfhQqutWMOpDcFwOnP2alY5siciH5rY1fg+Y5irybocSVSCjim32ReX08nze9QWP1 sAXBKcHmjfskw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 42BD380C8F; Sun, 17 Mar 2024 18:29:11 -0400 (EDT) Received: from alfajor (unknown [104.247.238.200]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 04B0D120667; Sun, 17 Mar 2024 18:29:10 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86zfuz7cbw.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 Mar 2024 17:18:43 +0200") Message-ID: References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> <877ci3stzu.fsf@epfl.ch> <86zfuz7cbw.fsf@gnu.org> Date: Sun, 17 Mar 2024 18:29:10 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -1.013 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain > Yes, I think we should document it near type-of, as the explanation > when and why to prefer cl-type-of is quite simple and easily > understandable. OK, here's a new (set of) patches (also available in the `scratch/object-type` branch). I added the doc as well as a test (which pointed to the `subr-primitive-p` problem), and an additional hunk which fixes the `subr-primitive-p`. Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-cl-type-of-New-function-to-return-more-precise-types.patch >From 3917c4be34f5c1d6249da474337f8f23544dcc9b Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 12 Mar 2024 09:26:24 -0400 Subject: [PATCH 1/3] (cl-type-of): New function to return more precise types (bug#69739) * src/data.c (Fcl_type_of): New function, extracted from `Ftype_of`. Make it return more precise types for symbols, integers, and subrs. (Ftype_of): Use it. (syms_of_data): Define the corresponding new symbols and defsubr the new function. * doc/lispref/objects.texi (Type Predicates): Document it. * src/comp.c (emit_limple_insn): Use `Fcl_type_of`. * lisp/emacs-lisp/cl-preloaded.el (subr): Demote it to `atom`. (subr-native-elisp, subr-primitive): Add `compiled-function` as parent instead. (special-form): New type. * lisp/obsolete/eieio-core.el (cl--generic-struct-tag): * lisp/emacs-lisp/cl-generic.el (cl--generic-typeof-generalizer): Use `cl-type-of`. cl--generic--unreachable-types): Update accordingly. test/src/data-tests.el (data-tests--cl-type-of): New test. --- doc/lispref/objects.texi | 21 +++++++++++++++++ etc/NEWS | 5 +++++ lisp/emacs-lisp/cl-generic.el | 6 ++--- lisp/emacs-lisp/cl-preloaded.el | 12 +++++----- lisp/emacs-lisp/eieio-core.el | 2 +- src/comp.c | 2 +- src/data.c | 40 ++++++++++++++++++++++++++++----- test/src/data-tests.el | 37 ++++++++++++++++++++++++++++++ 8 files changed, 108 insertions(+), 17 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 279f449a994..6e92f9bcc2a 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2207,6 +2207,27 @@ Type Predicates @end example @end defun +@defun cl-type-of object +This function returns a symbol naming @emph{the} type of +@var{object}. It usually behaves like @code{type-of}, except +that it guarantees to return the most precise type possible, which also +implies that the specific type it returns may change depending on the +Emacs version. For this reason, as a rule you should never compare its +return value against some fixed set of types. + +@example +(object-type 1) + @result{} fixnum +@group +(object-type 'nil) + @result{} null +(object-type (record 'foo)) + @result{} foo +@end group +@end example +@end defun + + @node Equality Predicates @section Equality Predicates @cindex equality diff --git a/etc/NEWS b/etc/NEWS index b02712dd21c..b522fbd338b 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1647,6 +1647,11 @@ values. * Lisp Changes in Emacs 30.1 +** New function 'cl-type-of'. +This function is like 'type-of' except that it sometimes returns +a more precise type. For example, for nil and t it returns 'null' +and 'boolean' respectively, instead of just 'symbol'. + ** Built-in types have now corresponding classes. At the Lisp level, this means that things like (cl-find-class 'integer) will now return a class object, and at the UI level it means that diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el index 613ecf82a92..62abe8d1589 100644 --- a/lisp/emacs-lisp/cl-generic.el +++ b/lisp/emacs-lisp/cl-generic.el @@ -1334,8 +1334,7 @@ cl-generic-generalizers (defconst cl--generic--unreachable-types ;; FIXME: Try to make that list empty? - '(fixnum bignum boolean keyword - special-form subr-primitive subr-native-elisp) + '(keyword) "Built-in classes on which we cannot dispatch for technical reasons.") (defun cl--generic-type-specializers (tag &rest _) @@ -1345,8 +1344,7 @@ cl--generic-type-specializers (cl--class-allparents class))))) (cl-generic-define-generalizer cl--generic-typeof-generalizer - ;; FIXME: We could also change `type-of' to return `null' for nil. - 10 (lambda (name &rest _) `(if ,name (type-of ,name) 'null)) + 10 (lambda (name &rest _) `(cl-type-of ,name)) #'cl--generic-type-specializers) (cl-defmethod cl-generic-generalizers :extra "typeof" (type) diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 515aa99549d..3e89afea452 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -339,8 +339,6 @@ cl--define-built-in-type ',parents)))))) ;; FIXME: Our type DAG has various quirks: -;; - `subr' says it's a `compiled-function' but that's not true -;; for those subrs that are special forms! ;; - Some `keyword's are also `symbol-with-pos' but that's not reflected ;; in the DAG. ;; - An OClosure can be an interpreted function or a `byte-code-function', @@ -428,15 +426,17 @@ compiled-function "Abstract type of functions that have been compiled.") (cl--define-built-in-type byte-code-function (compiled-function) "Type of functions that have been byte-compiled.") -(cl--define-built-in-type subr (compiled-function) +(cl--define-built-in-type subr (atom) "Abstract type of functions compiled to machine code.") (cl--define-built-in-type module-function (function) "Type of functions provided via the module API.") (cl--define-built-in-type interpreted-function (function) "Type of functions that have not been compiled.") -(cl--define-built-in-type subr-native-elisp (subr) - "Type of function that have been compiled by the native compiler.") -(cl--define-built-in-type subr-primitive (subr) +(cl--define-built-in-type special-form (subr) + "Type of the core syntactic elements of the Emacs Lisp language.") +(cl--define-built-in-type subr-native-elisp (subr compiled-function) + "Type of functions that have been compiled by the native compiler.") +(cl--define-built-in-type subr-primitive (subr compiled-function) "Type of functions hand written in C.") (unless (cl--class-parents (cl--find-class 'cl-structure-object)) diff --git a/lisp/emacs-lisp/eieio-core.el b/lisp/emacs-lisp/eieio-core.el index a2f7c4172a3..cf8bd749f2a 100644 --- a/lisp/emacs-lisp/eieio-core.el +++ b/lisp/emacs-lisp/eieio-core.el @@ -1046,7 +1046,7 @@ 'inconsistent-class-hierarchy (defun cl--generic-struct-tag (name &rest _) ;; Use exactly the same code as for `typeof'. - `(if ,name (type-of ,name) 'null)) + `(cl-type-of ,name)) (cl-generic-define-generalizer eieio--generic-generalizer ;; Use the exact same tagcode as for cl-struct, so that methods diff --git a/src/comp.c b/src/comp.c index 3f989c722d4..76cf1f3ab6e 100644 --- a/src/comp.c +++ b/src/comp.c @@ -2442,7 +2442,7 @@ emit_limple_insn (Lisp_Object insn) { Lisp_Object arg1 = arg[1]; - if (EQ (Ftype_of (arg1), Qcomp_mvar)) + if (EQ (Fcl_type_of (arg1), Qcomp_mvar)) res = emit_mvar_rval (arg1); else if (EQ (FIRST (arg1), Qcall)) res = emit_limple_call (XCDR (arg1)); diff --git a/src/data.c b/src/data.c index 35f4c82c68f..a961dd3108c 100644 --- a/src/data.c +++ b/src/data.c @@ -193,16 +193,37 @@ DEFUN ("null", Fnull, Snull, 1, 1, 0, DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, doc: /* Return a symbol representing the type of OBJECT. The symbol returned names the object's basic type; -for example, (type-of 1) returns `integer'. */) +for example, (type-of 1) returns `integer'. +Contrary to `cl-type-of' the returned type is not always the most +precise type possible, because instead this function tries to preserve +compatibility with the return value of previous Emacs versions. */) + (Lisp_Object object) +{ + return SYMBOLP (object) ? Qsymbol + : INTEGERP (object) ? Qinteger + : SUBRP (object) ? Qsubr + : Fcl_type_of (object); +} + +DEFUN ("cl-type-of", Fcl_type_of, Scl_type_of, 1, 1, 0, + doc: /* Return a symbol representing the type of OBJECT. +The symbol returned names the most specific possible type of the object. +for example, (object-type nil) returns `null'. +The specific type returned may change depending on Emacs versions, +so we recommend you use `cl-typep', `cl-typecase', or other predicates +rather than compare the return value of this function against +a fixed set of types. */) (Lisp_Object object) { switch (XTYPE (object)) { case_Lisp_Int: - return Qinteger; + return Qfixnum; case Lisp_Symbol: - return Qsymbol; + return NILP (object) ? Qnull + : EQ (object, Qt) ? Qboolean + : Qsymbol; case Lisp_String: return Qstring; @@ -215,7 +236,7 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, switch (PSEUDOVECTOR_TYPE (XVECTOR (object))) { case PVEC_NORMAL_VECTOR: return Qvector; - case PVEC_BIGNUM: return Qinteger; + case PVEC_BIGNUM: return Qbignum; case PVEC_MARKER: return Qmarker; case PVEC_SYMBOL_WITH_POS: return Qsymbol_with_pos; case PVEC_OVERLAY: return Qoverlay; @@ -224,7 +245,10 @@ DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, case PVEC_WINDOW_CONFIGURATION: return Qwindow_configuration; case PVEC_PROCESS: return Qprocess; case PVEC_WINDOW: return Qwindow; - case PVEC_SUBR: return Qsubr; + case PVEC_SUBR: + return XSUBR (object)->max_args == UNEVALLED ? Qspecial_form + : SUBR_NATIVE_COMPILEDP (object) ? Qsubr_native_elisp + : Qsubr_primitive; case PVEC_COMPILED: return Qcompiled_function; case PVEC_BUFFER: return Qbuffer; case PVEC_CHAR_TABLE: return Qchar_table; @@ -4202,7 +4226,9 @@ #define PUT_ERROR(sym, tail, msg) \ "Variable binding depth exceeds max-specpdl-size"); /* Types that type-of returns. */ + DEFSYM (Qboolean, "boolean"); DEFSYM (Qinteger, "integer"); + DEFSYM (Qbignum, "bignum"); DEFSYM (Qsymbol, "symbol"); DEFSYM (Qstring, "string"); DEFSYM (Qcons, "cons"); @@ -4218,6 +4244,9 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qprocess, "process"); DEFSYM (Qwindow, "window"); DEFSYM (Qsubr, "subr"); + DEFSYM (Qspecial_form, "special-form"); + DEFSYM (Qsubr_primitive, "subr-primitive"); + DEFSYM (Qsubr_native_elisp, "subr-native-elisp"); DEFSYM (Qcompiled_function, "compiled-function"); DEFSYM (Qbuffer, "buffer"); DEFSYM (Qframe, "frame"); @@ -4255,6 +4284,7 @@ #define PUT_ERROR(sym, tail, msg) \ defsubr (&Seq); defsubr (&Snull); defsubr (&Stype_of); + defsubr (&Scl_type_of); defsubr (&Slistp); defsubr (&Snlistp); defsubr (&Sconsp); diff --git a/test/src/data-tests.el b/test/src/data-tests.el index ad3b2071254..9d76c58224d 100644 --- a/test/src/data-tests.el +++ b/test/src/data-tests.el @@ -838,4 +838,41 @@ data-tests-bare-symbol (dolist (sym (list nil t 'xyzzy (make-symbol ""))) (should (eq sym (bare-symbol (position-symbol sym 0))))))) +(require 'cl-extra) ;For `cl--class-children'. + +(ert-deftest data-tests--cl-type-of () + ;; Make sure that `cl-type-of' returns the most precise type. + ;; Note: This doesn't work for list/vector structs since those types + ;; are too difficult/unreliable to detect (so `cl-type-of' only says + ;; it's a `cons' or a `vector'). + (dolist (val (list -2 10 (expt 2 128) nil t 'car + (symbol-function 'car) + (symbol-function 'progn) + (position-symbol 'car 7))) + (let* ((type (cl-type-of val)) + (class (cl-find-class type)) + (alltypes (cl--class-allparents class)) + ;; FIXME: Our type DAG is affected by `symbols-with-pos-enabled'. + ;; (e.g. `symbolp' returns nil on a sympos if that var is nil). + (symbols-with-pos-enabled t)) + (dolist (parent alltypes) + (should (cl-typep val parent)) + (dolist (subtype (cl--class-children (cl-find-class parent))) + (unless (memq subtype alltypes) + (unless (memq subtype + ;; FIXME: Some types don't have any associated + ;; predicate, + '( font-spec font-entity font-object + finalizer condvar terminal + native-comp-unit interpreted-function + tree-sitter-compiled-query + tree-sitter-node tree-sitter-parser + ;; `functionp' also matches things of type + ;; `symbol' and `cons'. + ;; FIXME: `subr-primitive-p' also matches + ;; special-forms. + function subr-primitive)) + (should-not (cl-typep val subtype))))))))) + + ;;; data-tests.el ends here -- 2.43.0 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-primitive-function-New-type.patch >From 41184670fd4b720350da58f6051212e5cb3ea7a7 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Sun, 17 Mar 2024 17:29:02 -0400 Subject: [PATCH 2/3] (primitive-function): New type The type hierarchy and `cl-type-of` code assumed that `subr-primitive` only applies to functions, but since it also accepts special-forms it makes it an unsuitable choice since it can't be a subtype of `compiled-function`. So, use a new type `primitive-function` instead. * lisp/subr.el (subr-primitive-p): Fix docstring (bug#69832). (primitive-function-p): New function. * lisp/emacs-lisp/cl-preloaded.el (primitive-function): Rename from `subr-primitive` since `subr-primitive-p` means something else. * src/data.c (Fcl_type_of): Return `primitive-function` instead of `subr-primitive` for C functions. (syms_of_data): Adjust accordingly. * test/src/data-tests.el (data-tests--cl-type-of): Remove workaround. --- etc/NEWS | 4 ++++ lisp/emacs-lisp/cl-preloaded.el | 2 +- lisp/subr.el | 9 ++++++++- src/data.c | 4 ++-- test/src/data-tests.el | 4 +--- 5 files changed, 16 insertions(+), 7 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index b522fbd338b..69e61d91b0e 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1652,6 +1652,10 @@ This function is like 'type-of' except that it sometimes returns a more precise type. For example, for nil and t it returns 'null' and 'boolean' respectively, instead of just 'symbol'. +** New function `primitive-function-p`. +This is like `subr-primitive-p` except that it returns t only if the +argument is a function rather than a special-form. + ** Built-in types have now corresponding classes. At the Lisp level, this means that things like (cl-find-class 'integer) will now return a class object, and at the UI level it means that diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index 3e89afea452..d11c97a3e3a 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -436,7 +436,7 @@ special-form "Type of the core syntactic elements of the Emacs Lisp language.") (cl--define-built-in-type subr-native-elisp (subr compiled-function) "Type of functions that have been compiled by the native compiler.") -(cl--define-built-in-type subr-primitive (subr compiled-function) +(cl--define-built-in-type primitive-function (subr compiled-function) "Type of functions hand written in C.") (unless (cl--class-parents (cl--find-class 'cl-structure-object)) diff --git a/lisp/subr.el b/lisp/subr.el index 38a3f6edb34..9e63e409349 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -312,11 +312,18 @@ unless cond '(empty-body unless) t))) (defsubst subr-primitive-p (object) - "Return t if OBJECT is a built-in primitive function." + "Return t if OBJECT is a built-in primitive written in C." (declare (side-effect-free error-free)) (and (subrp object) (not (subr-native-elisp-p object)))) +(defsubst primitive-function-p (object) + "Return t if OBJECT is a built-in primitive function." + (declare (side-effect-free error-free)) + (and (subrp object) + (not (or (subr-native-elisp-p object) + (eq (cdr (subr-arity object)) 'unevalled))))) + (defsubst xor (cond1 cond2) "Return the boolean exclusive-or of COND1 and COND2. If only one of the arguments is non-nil, return it; otherwise diff --git a/src/data.c b/src/data.c index a961dd3108c..fe631b27ccc 100644 --- a/src/data.c +++ b/src/data.c @@ -248,7 +248,7 @@ DEFUN ("cl-type-of", Fcl_type_of, Scl_type_of, 1, 1, 0, case PVEC_SUBR: return XSUBR (object)->max_args == UNEVALLED ? Qspecial_form : SUBR_NATIVE_COMPILEDP (object) ? Qsubr_native_elisp - : Qsubr_primitive; + : Qprimitive_function; case PVEC_COMPILED: return Qcompiled_function; case PVEC_BUFFER: return Qbuffer; case PVEC_CHAR_TABLE: return Qchar_table; @@ -4245,7 +4245,7 @@ #define PUT_ERROR(sym, tail, msg) \ DEFSYM (Qwindow, "window"); DEFSYM (Qsubr, "subr"); DEFSYM (Qspecial_form, "special-form"); - DEFSYM (Qsubr_primitive, "subr-primitive"); + DEFSYM (Qprimitive_function, "primitive-function"); DEFSYM (Qsubr_native_elisp, "subr-native-elisp"); DEFSYM (Qcompiled_function, "compiled-function"); DEFSYM (Qbuffer, "buffer"); diff --git a/test/src/data-tests.el b/test/src/data-tests.el index 9d76c58224d..daa49e671b5 100644 --- a/test/src/data-tests.el +++ b/test/src/data-tests.el @@ -869,9 +869,7 @@ data-tests--cl-type-of tree-sitter-node tree-sitter-parser ;; `functionp' also matches things of type ;; `symbol' and `cons'. - ;; FIXME: `subr-primitive-p' also matches - ;; special-forms. - function subr-primitive)) + function)) (should-not (cl-typep val subtype))))))))) -- 2.43.0 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-Followup-changes-to-cl-type-of.patch >From 3bab41044eb2c3c9ec373eae4efb92832c2fe6c3 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Thu, 14 Mar 2024 12:49:08 -0400 Subject: [PATCH 3/3] Followup changes to `cl-type-of` These changes came up while working on `cl-type-of` but are not directly related to the new `cl-type-of`. The BASE_PURESIZE bump was needed at some point on one of my machine, not sure why. * src/puresize.h (BASE_PURESIZE): Bump up. * src/sqlite.c (bind_value): Don't use `Ftype_of`. * lisp/emacs-lisp/seq.el (seq-remove-at-position): Simplify. * lisp/emacs-lisp/cl-preloaded.el (finalizer): New (previously missing) type. * doc/lispref/objects.texi (Type Predicates): Minor tweaks. --- doc/lispref/objects.texi | 6 +++--- lisp/emacs-lisp/cl-preloaded.el | 1 + lisp/emacs-lisp/seq.el | 3 +-- src/lisp.h | 6 ++---- src/puresize.h | 2 +- src/sqlite.c | 17 ++++++----------- 6 files changed, 14 insertions(+), 21 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 6e92f9bcc2a..50dddf9f0e5 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -1485,8 +1485,8 @@ Type Descriptors @subsection Type Descriptors A @dfn{type descriptor} is a @code{record} which holds information -about a type. Slot 1 in the record must be a symbol naming the type, and -@code{type-of} relies on this to return the type of @code{record} +about a type. The first slot in the record must be a symbol naming the type, +and @code{type-of} relies on this to return the type of @code{record} objects. No other type descriptor slot is used by Emacs; they are free for use by Lisp extensions. @@ -2175,7 +2175,7 @@ Type Predicates function @code{type-of}. Recall that each object belongs to one and only one primitive type; @code{type-of} tells you which one (@pxref{Lisp Data Types}). But @code{type-of} knows nothing about non-primitive -types. In most cases, it is more convenient to use type predicates than +types. In most cases, it is preferable to use type predicates than @code{type-of}. @defun type-of object diff --git a/lisp/emacs-lisp/cl-preloaded.el b/lisp/emacs-lisp/cl-preloaded.el index d11c97a3e3a..cba56e0bbd4 100644 --- a/lisp/emacs-lisp/cl-preloaded.el +++ b/lisp/emacs-lisp/cl-preloaded.el @@ -365,6 +365,7 @@ frame (cl--define-built-in-type buffer atom) (cl--define-built-in-type window atom) (cl--define-built-in-type process atom) +(cl--define-built-in-type finalizer atom) (cl--define-built-in-type window-configuration atom) (cl--define-built-in-type overlay atom) (cl--define-built-in-type number-or-marker atom diff --git a/lisp/emacs-lisp/seq.el b/lisp/emacs-lisp/seq.el index 20077db9e60..a20cff16982 100644 --- a/lisp/emacs-lisp/seq.el +++ b/lisp/emacs-lisp/seq.el @@ -362,8 +362,7 @@ seq-remove-at-position The result is a sequence of the same type as SEQUENCE." (seq-concatenate - (let ((type (type-of sequence))) - (if (eq type 'cons) 'list type)) + (if (listp sequence) 'list (type-of sequence)) (seq-subseq sequence 0 n) (seq-subseq sequence (1+ n)))) diff --git a/src/lisp.h b/src/lisp.h index f353e4956eb..f86758c88fb 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -569,10 +569,8 @@ #define ENUM_BF(TYPE) enum TYPE your object -- this way, the same object could be used to represent several disparate C structures. - In addition, you need to add switch branches in data.c for Ftype_of. - - You also need to add the new type to the constant - `cl--typeof-types' in lisp/emacs-lisp/cl-preloaded.el. */ + In addition, you need to add switch branches in data.c for Fcl_type_of + and `cl--define-builtin-type` in lisp/emacs-lisp/cl-preloaded.el. */ /* A Lisp_Object is a tagged pointer or integer. Ordinarily it is a diff --git a/src/puresize.h b/src/puresize.h index ac5d2da30dc..2a716872832 100644 --- a/src/puresize.h +++ b/src/puresize.h @@ -47,7 +47,7 @@ #define SITELOAD_PURESIZE_EXTRA 0 #endif #ifndef BASE_PURESIZE -#define BASE_PURESIZE (2750000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) +#define BASE_PURESIZE (3000000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA) #endif /* Increase BASE_PURESIZE by a ratio depending on the machine's word size. */ diff --git a/src/sqlite.c b/src/sqlite.c index 7a018b28aa4..261080da673 100644 --- a/src/sqlite.c +++ b/src/sqlite.c @@ -349,9 +349,7 @@ bind_values (sqlite3 *db, sqlite3_stmt *stmt, Lisp_Object values) value = XCAR (values); values = XCDR (values); } - Lisp_Object type = Ftype_of (value); - - if (EQ (type, Qstring)) + if (STRINGP (value)) { Lisp_Object encoded; bool blob = false; @@ -385,14 +383,11 @@ bind_values (sqlite3 *db, sqlite3_stmt *stmt, Lisp_Object values) SSDATA (encoded), SBYTES (encoded), NULL); } - else if (EQ (type, Qinteger)) - { - if (BIGNUMP (value)) - ret = sqlite3_bind_int64 (stmt, i + 1, bignum_to_intmax (value)); - else - ret = sqlite3_bind_int64 (stmt, i + 1, XFIXNUM (value)); - } - else if (EQ (type, Qfloat)) + else if (FIXNUMP (value)) + ret = sqlite3_bind_int64 (stmt, i + 1, XFIXNUM (value)); + else if (BIGNUMP (value)) + ret = sqlite3_bind_int64 (stmt, i + 1, bignum_to_intmax (value)); + else if (FLOATP (value)) ret = sqlite3_bind_double (stmt, i + 1, XFLOAT_DATA (value)); else if (NILP (value)) ret = sqlite3_bind_null (stmt, i + 1); -- 2.43.0 --=-=-=-- From unknown Fri Aug 15 02:04:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69739: 30.0.50; `type-of` is not precise enough Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Mar 2024 12:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: acorallo@gnu.org, basil@contovou.net, 69739@debbugs.gnu.org Received: via spool by 69739-submit@debbugs.gnu.org id=B69739.171076667411856 (code B ref 69739); Mon, 18 Mar 2024 12:58:01 +0000 Received: (at 69739) by debbugs.gnu.org; 18 Mar 2024 12:57:54 +0000 Received: from localhost ([127.0.0.1]:51164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmCYs-00035A-A1 for submit@debbugs.gnu.org; Mon, 18 Mar 2024 08:57:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmCYp-00034w-Bb for 69739@debbugs.gnu.org; Mon, 18 Mar 2024 08:57:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmCY5-0006pS-NL; Mon, 18 Mar 2024 08:57:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4CkAX34Z+GIRATjB4L8tm+L+gzG4D+SbguVCXJYT+UY=; b=JjHDBlLnBrWj EBR2N8hpNqK5EjS+GQ1hxbHj+xkmEbKnfk+EmZxgWhM7198kqp8k4lm8QbImTXy0JBvz0P7La+RWm 2JnvSsSSrnTu54OT4lGQRFYOkYcIM4YAF7DEuhWSgyJZpYvkE6GkLVOQn09fRbuuykiLDv5HHbHp3 8CNnuiA2yJbY2b37b2+kYtO2TDXYKBoFWwtPFmMIq4BO768UK/O+CXisSNJP1j5v0PHQHVNXayeeq UyQD5+GHZKZmGOSxdirLONEGxY3pisLsN9lUg1pCetHQV6A1vNyqgNQR9xBin9/EzSQ+3I9Wg+X9K g7LK6Re356iLHtVs1LiIAg==; Date: Mon, 18 Mar 2024 14:56:58 +0200 Message-Id: <86r0g74s11.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sun, 17 Mar 2024 18:29:10 -0400) References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> <877ci3stzu.fsf@epfl.ch> <86zfuz7cbw.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: basil@contovou.net, acorallo@gnu.org, 69739@debbugs.gnu.org > Date: Sun, 17 Mar 2024 18:29:10 -0400 > > > Yes, I think we should document it near type-of, as the explanation > > when and why to prefer cl-type-of is quite simple and easily > > understandable. > > OK, here's a new (set of) patches (also available in the > `scratch/object-type` branch). I added the doc as well as a test > (which pointed to the `subr-primitive-p` problem), and an additional > hunk which fixes the `subr-primitive-p`. Thanks, a few nits below. > +@defun cl-type-of object > +This function returns a symbol naming @emph{the} type of > +@var{object}. It usually behaves like @code{type-of}, except > +that it guarantees to return the most precise type possible, which also > +implies that the specific type it returns may change depending on the > +Emacs version. For this reason, as a rule you should never compare its > +return value against some fixed set of types. > + > +@example > +(object-type 1) > + @result{} fixnum > +@group > +(object-type 'nil) > + @result{} null > +(object-type (record 'foo)) > + @result{} foo "object-type"? > DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, > doc: /* Return a symbol representing the type of OBJECT. > The symbol returned names the object's basic type; > -for example, (type-of 1) returns `integer'. */) > +for example, (type-of 1) returns `integer'. > +Contrary to `cl-type-of' the returned type is not always the most ^^ I think we want a comma there. > +DEFUN ("cl-type-of", Fcl_type_of, Scl_type_of, 1, 1, 0, > + doc: /* Return a symbol representing the type of OBJECT. > +The symbol returned names the most specific possible type of the object. ^^^^^^^^^^^^^^^^^^^ I think "The returned symbol" is better here, as it prevents a possible confusion (whether "returned" alludes to "symbol" or to "names"). > +for example, (object-type nil) returns `null'. ^^^^^^^^^^^ "object-type"? > (defsubst subr-primitive-p (object) > - "Return t if OBJECT is a built-in primitive function." > + "Return t if OBJECT is a built-in primitive written in C." > (declare (side-effect-free error-free)) > (and (subrp object) > (not (subr-native-elisp-p object)))) > > +(defsubst primitive-function-p (object) > + "Return t if OBJECT is a built-in primitive function." > + (declare (side-effect-free error-free)) > + (and (subrp object) > + (not (or (subr-native-elisp-p object) > + (eq (cdr (subr-arity object)) 'unevalled))))) Should these doc strings mention the special case of special form, which each one of them treats differently? From unknown Fri Aug 15 02:04:59 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Stefan Monnier Subject: bug#69739: closed (Re: bug#69739: 30.0.50; `type-of` is not precise enough) Message-ID: References: X-Gnu-PR-Message: they-closed 69739 X-Gnu-PR-Package: emacs Reply-To: 69739@debbugs.gnu.org Date: Mon, 18 Mar 2024 13:35:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1710768902-17666-1" This is a multi-part message in MIME format... ------------=_1710768902-17666-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #69739: 30.0.50; `type-of` is not precise enough which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 69739@debbugs.gnu.org. --=20 69739: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D69739 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1710768902-17666-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 69739-done) by debbugs.gnu.org; 18 Mar 2024 13:34:47 +0000 Received: from localhost ([127.0.0.1]:53022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmD8Y-0004aB-QJ for submit@debbugs.gnu.org; Mon, 18 Mar 2024 09:34:47 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rmD8W-0004Zn-1z for 69739-done@debbugs.gnu.org; Mon, 18 Mar 2024 09:34:44 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 171F4100046; Mon, 18 Mar 2024 09:34:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710768839; bh=6BOdS6p0QZBXEDC/A+BWyRru4KDU5SDg3gJDyrGUt4g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DPU4EBsmjuYHm3RjK4LlVuziv247x8akkZqSYliLXbIvRryspua9RYN5nq8STwori 03LMsMQ7Htcxbl/To45ZczIGdNd1ritQdTMG0MdmwM/PmKgBjnf3hDIKvEfGXu3Ro1 TBMf4Pxt7kLCAtRfVB/HY2pp3aF9dlgDvg6Lp11xc/pUE3e6p/IuFIp565V06KgVnZ mV8AoM+2EB8BM3WExMKbJKhC/HcIKdTvCt82f7K55n2KKslv/JKhzT9P27OD5o6jVr uX7eAHqwlsgYYNSFUXYt2oilduTZF1aUhLDjxAHounfCVFwdstnslwqEkviFLkPyFy 5iloiC2z/pgVw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 14C101000DD; Mon, 18 Mar 2024 09:33:59 -0400 (EDT) Received: from alfajor (bras-base-mtrlpq42zf4-grc-23-70-29-179-140.dsl.bell.ca [70.29.179.140]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F0650120235; Mon, 18 Mar 2024 09:33:58 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#69739: 30.0.50; `type-of` is not precise enough In-Reply-To: <86r0g74s11.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 18 Mar 2024 14:56:58 +0200") Message-ID: References: <86o7bjtuvj.fsf@gnu.org> <86il1rtrvm.fsf@gnu.org> <86a5n2tkga.fsf@gnu.org> <877ci3stzu.fsf@epfl.ch> <86zfuz7cbw.fsf@gnu.org> <86r0g74s11.fsf@gnu.org> Date: Mon, 18 Mar 2024 09:33:58 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69739-done Cc: acorallo@gnu.org, basil@contovou.net, 69739-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> +@example >> +(object-type 1) >> + @result{} fixnum >> +@group >> +(object-type 'nil) >> + @result{} null >> +(object-type (record 'foo)) >> + @result{} foo > > "object-type"? Oops! thanks. >> DEFUN ("type-of", Ftype_of, Stype_of, 1, 1, 0, >> doc: /* Return a symbol representing the type of OBJECT. >> The symbol returned names the object's basic type; >> -for example, (type-of 1) returns `integer'. */) >> +for example, (type-of 1) returns `integer'. >> +Contrary to `cl-type-of' the returned type is not always the most > ^^ > I think we want a comma there. >> +DEFUN ("cl-type-of", Fcl_type_of, Scl_type_of, 1, 1, 0, >> + doc: /* Return a symbol representing the type of OBJECT. >> +The symbol returned names the most specific possible type of the object. > ^^^^^^^^^^^^^^^^^^^ > I think "The returned symbol" is better here, as it prevents a > possible confusion (whether "returned" alludes to "symbol" or to > "names"). Agreed. >> +for example, (object-type nil) returns `null'. > ^^^^^^^^^^^ > "object-type"? As you can see I had used `object-type` instead of `cl-type-of` in some prior version of the code :-) >> (defsubst subr-primitive-p (object) >> - "Return t if OBJECT is a built-in primitive function." >> + "Return t if OBJECT is a built-in primitive written in C." >> (declare (side-effect-free error-free)) >> (and (subrp object) >> (not (subr-native-elisp-p object)))) >> >> +(defsubst primitive-function-p (object) >> + "Return t if OBJECT is a built-in primitive function." >> + (declare (side-effect-free error-free)) >> + (and (subrp object) >> + (not (or (subr-native-elisp-p object) >> + (eq (cdr (subr-arity object)) 'unevalled))))) > > Should these doc strings mention the special case of special form, > which each one of them treats differently? OK. Pushed, thanks, Stefan ------------=_1710768902-17666-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 11 Mar 2024 23:21:21 +0000 Received: from localhost ([127.0.0.1]:41468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjoxI-00048Q-W1 for submit@debbugs.gnu.org; Mon, 11 Mar 2024 19:21:20 -0400 Received: from lists.gnu.org ([209.51.188.17]:57726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjoxC-000483-4s for submit@debbugs.gnu.org; Mon, 11 Mar 2024 19:21:14 -0400 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 1rjowW-0005kI-2z for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2024 19:20:28 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rjowJ-0000Yz-Hp for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2024 19:20:24 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8D351442C81 for ; Mon, 11 Mar 2024 19:20:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710199201; bh=QRkYvZ+UJHnYRPIGUOwQfw9e1IsIAkf5xRTK/vLYfwY=; h=From:To:Subject:Date:From; b=E3THFMtfxsPnnJtEnf4ghfxHzRAjWsyu+7YZC1i+4TgO+FuXBc7d44/UCCgoRe8VL Teg3MenyrGKRpadCCdxOKZvC8SP+xv3CKAZjjQLHFzEbQDXQ5nXKXwCxqZvsuZp/8J TSdOSf3lYAGB+GmKVZ0Y01XXub3zxZnDYN/wgZ8UBFRtTH2O8VOK4aCXrAcyQTEK8r VEDDCMVtLNoZQL1tUr5czIfFywRSHCz4TVJKtX4Vf5tj1ZaW+mtXxGF9wOarQ+q136 1yNm91Rl4rLFSeohUq0wq/9k7hPnQiROHLSM0e6pLzDI7FZY4UdOLJdVjFydAaYfDp zJmu9V0cpFn5w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BD5DC4447A8 for ; Mon, 11 Mar 2024 19:20:01 -0400 (EDT) Received: from pastel (69-165-147-56.dsl.teksavvy.com [69.165.147.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9DECE120403 for ; Mon, 11 Mar 2024 19:20:01 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 30.0.50; `type-of` is not precise enough X-Debbugs-Cc: monnier@iro.umontreal.ca Date: Mon, 11 Mar 2024 19:19:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.038 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Package: Emacs Version: 30.0.50 `type-of` is supposed to return "the" type of its argument. Given that ELisp has a notion of subtyping, "the" type is expected to mean "the most precise type". This is used in `cl-generic` to decide which method to apply, so it's important that it returns precise information. Currently, there `type-of` fails to return precise enough information in a few cases: - When the argument is nil, it returns `symbol`. The problem here is that `symbol` is not a subtype of `list`, whereas nil is a list. - When the argument is a special form, a C primitive, or a native-compiled function it returns `subr`. Currently our type hierarchy says that `subr` is a subtype of `compiled-function` (and hence of `function`), but a special form is *not* a function (it fails the `functionp` test and can't be `funcall`ed). Currently `cl-generic` works around the first point above by using (if FOO (type-of FOO) 'null) instead of calling `type-of` directly. Suggestion: I suggest we change `type-of` to return `null` for `nil`, `special-form` for subrs that are special forms, `subr-primitive` for C primitives, and `subr-native-elisp` for native-compiled subrs. There are a few other cases where we could improve the precision, tho they are less important because they don't cause problems w.r.t subtyping like the above does. Further improvements could include: - Return `boolean` for `t`. This would be nice otherwise (with the above suggestion) `cl-generic` can dispatch on "nil is a boolean" but not on "t is a boolean". - Return `keyword` for symbols that are keywords. - Return `fixnum` or `bignum` rather than just `integer`. Probably not worth the trouble. - We could go crazy and return `keyword-with-pos` for `symbols-with-pos` that are keywords. Of these further improvements, only the first (return `boolean` for `t`) seems worth the trouble. Still, any change as suggested here would be an incompatible change, so there's risk it'll break some code out there (`type-of` is not used very often, but it *is* used). Another option is to introduce a new function which does the same as `type-of` but with changes like the ones above. (we could even decide to give it a `cl-generic-` prefix to discourage its use elsewhere so we can be more free to change its return value in the future). Stefan ------------=_1710768902-17666-1--