From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thuna Newsgroups: gmane.emacs.devel Subject: Unify make-closure, make-interpreted-closure, and make-byte-code Date: Mon, 11 Nov 2024 17:04:29 +0100 Message-ID: <875xotsqnm.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15849"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 11 17:40:19 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tAXSd-0003ue-Pn for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Nov 2024 17:40:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tAXRn-0007ln-GJ; Mon, 11 Nov 2024 11:39:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tAWu6-0002AZ-SI for emacs-devel@gnu.org; Mon, 11 Nov 2024 11:04:38 -0500 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tAWu4-0001aX-Un for emacs-devel@gnu.org; Mon, 11 Nov 2024 11:04:38 -0500 Original-Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-37d4ac91d97so4471637f8f.2 for ; Mon, 11 Nov 2024 08:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731341073; x=1731945873; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=SI0olruF8KIGl4WGvY5gPJFylEt7PBwb/vo887fZ2yI=; b=jVWdcVS7MFjA90aMVwa8svs6lFYg0B/9yYZI2W+tncux03re3FGg57NQMNpoMbJFix kKnW/bK362hLYtbT+dAKdKHgwqMV288Q2LzKo+SW+kpdG8JJrHFGPfbDb+4D9GKPCWeD JZjVJkM4HWB6bQew9QwsFCpzPhSt22R6Q1GU+pyzumIXjzL++I0QdxNYrBnS/Q2jRDa5 MdIfNGoRjIHrt9onREudwpWruSjPw1l5mia3Qqzdr3FhIN0i0/D5PrS4I9F4B5GiLXNx 7CQXLaom3bZZkPzm1t3CVyivE/laJAJy5gvlaOO4WfGoZ7Nwk8JYVKJqj56VlYYJLEdq /kAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731341073; x=1731945873; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SI0olruF8KIGl4WGvY5gPJFylEt7PBwb/vo887fZ2yI=; b=Svjts6rxMoXjYx42CM22oTsH53RzsSWIU6w4mG/aCuSoIpi5p5bCtVUY+yRchwlLLm s4fCN4KRmB1ke/95YwDBL1S1YNWhazB+wMQ15WLBXJ5eNeJdbUFo8ROUMic4FyL9PW95 ar5CG32ssVE6SVoTJDCsO0e8p58NjXMEgzXmXuekPNmagQBPu+Yoj3SPp1KWAExsvOTE 6+dG4Hfew9l55hPFQamAL2TgN6cvbTxkAorvJl1xUOZQgAoZHiJU3JIMYjWKZ/8NH4fP 9vtse6DaIkvFF1D6k/TjZ1HcSQPEOwOxGlK5lz9Ai5PmxV0O+DblI/vyqJkYe1GGHBEb GIHQ== X-Gm-Message-State: AOJu0Yzd4Rw0uX/pIJO/XWzU0oXdqYu1Q8wcCzPs5025uFvv+2lmCYTp 3sfuJRNfnmuG7OGAQ2nbTDypXITKhwMSuboan1Vb4OIPbLsAPmqG9TvOjg== X-Google-Smtp-Source: AGHT+IGD45H3HrsS2HqpwjY1HLVJiUn5eJb3T/cIKyUfoZpb4qwMAlZMAo/z4LouKDMZegdv3HJZTA== X-Received: by 2002:a05:6000:385:b0:37d:4a16:81d7 with SMTP id ffacd0b85a97d-381f1866abfmr12968537f8f.8.1731341070577; Mon, 11 Nov 2024 08:04:30 -0800 (PST) Original-Received: from thuna-lis3 ([90.147.71.144]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-381ed9ea3cbsm13405946f8f.74.2024.11.11.08.04.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2024 08:04:30 -0800 (PST) Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=thuna.cing@gmail.com; helo=mail-wr1-x430.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 11 Nov 2024 11:39:26 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325407 Archived-At: My understanding is that interpreted closures and bytecode are both closures, just with different restrictions on what each slot can hold. Given this, I can't help but wonder why we have three functions which implement the same thing and do so in a completely different manner: - `make-interpreted-closure' checks each argument individually, makes a vector of length 6, and passes it to Fvector with NARGS as small as possible. - `make-byte-code' checks every relevant argument in one if statement (and signals an error that nothing else signals), and makes an arbitrary-long vector via Fvector. - `make-closure' seems to (unless I am misreading it) copy a closure (and not a bytecode object as it says), change the constants, and return the copy. `make-byte-code' and `make-closure' are essentially copiers. `make-closure' straightforwardly so, and `make-byte-code' effectively so, as it is primarily used (in core) in some variation of (apply #'make-byte-code (concat closure nil)) and on that note, I can't see any reason for `make-byte-code' to allow an arbitrary number of arguments other than to support the above pattern, and I personally don't find that to be a compelling case. Putting aside concerns of backwards compatibility for a moment, what I would expect is to have a `make-closure', a `copy-closure', and functions for retrieving (and/or setting) each slot of closures (we already have something like that in `interactive-form' and `documentation'), with `make-interpreted-closure' and `make-byte-code' being very small wrappers around `make-closure'. I lean more towards the current `make-interpreted-closure' as what `make-closure' should look like, as that lends itself better to changing the slots around without breaking code. I think that it would be agreeable to backwards incompatibly change `make-closure', as I see exactly one use of `make-closure' in core in oclosure.el and exactly no uses in melpa or elpa. `make-byte-code' can also be deprecated in favor of a `make-compiled-closure' with better interface, so as not to break existing code using `make-byte-code' (though of course, any moving slots around will break almost all code using `make-byte-code' regardless; that's why I want this change to begin with). This doubly so given the structure of closures is supposed to be an implementation detail. Some other solution is also fine; my motivation is to make it as painless as possible to add a new slot to (the middle of) closures (see https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg01229.html and https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00039.html for context).