From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Distinguishing `consp` and `functionp` Date: Sun, 28 Jan 2024 16:27:27 -0500 Message-ID: References: <86msssble8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19465"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 22:28:12 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 1rUChH-0004ly-2a for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 22:28:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUCgh-000362-TB; Sun, 28 Jan 2024 16:27:35 -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 1rUCgg-00035e-5L for emacs-devel@gnu.org; Sun, 28 Jan 2024 16:27:34 -0500 Original-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 1rUCge-0005bU-Eh; Sun, 28 Jan 2024 16:27:33 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EA0304422B2; Sun, 28 Jan 2024 16:27:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706477248; bh=Jh3900qdQb/RHE0cgRBQSaEpDlpB+RvrNsIkl/9agqQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NQ1klgNlmsJnqIadlclZ2usgjHYO47br5FGaQ3xOj/AISG4r2kg+TD4C/7qZ2f5sf wDfTlaTG+DW0C30m8/CcuCCTS00eH2JCgaeM8W2Ixv02lQ16YDG0vcKsv7MtXxBlCX r6hcJQJEzFt4ItcDPIBxOVhUXETljAikOEfRseRG3uOHrCR0Y09O4058KfMRBYhdcF gptnTXCQh1dGsacvkpmbv0oLVbMLSvDb1OL7+ikDMdVzgNT622V21LtHAXd+OvysZt YvAbW7xl2NsjXfQb6u2yM8qnWENVVhTU/VoWpezYzQimX79dG/4YZywM9QGpUmIUzh UoRHZ1UKsGrlA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BCF5644229B; Sun, 28 Jan 2024 16:27:28 -0500 (EST) Original-Received: from alfajor (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 96668120C61; Sun, 28 Jan 2024 16:27:28 -0500 (EST) In-Reply-To: <86msssble8.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Jan 2024 09:31:59 +0200") 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-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:315572 Archived-At: > Maybe I'm missing something, but I always thought that having code and > data indistinguishable is one of the strong sides of Lisp. Are we now > going to make this advantage smaller, by deprecating the use of lists > to represent functions? A function *value* contains code in some representation that depends on lots of factors. In practice most function values in most Lisp implementations are not just plain lists but are somewhat opaque data. This is also the case in ELisp where most function values are actually compiled either as bytecode or as native code: we do have tools to look inside, but they're definitely not plain old lists. The "code and data indistinguishable" is something that usually refers to various things: - the source code (which gives us powerful macros). - the availability of `read`able print representations of functions (tho that doesn't apply to native-compiled functions, sadly). - the ability to embed any value (including a function) into source code via `quote`. Those three are mostly independent from each other (and are not affected by my patch). And if you ask other people, they may give you different answers. But looking inside a function *value* (i.e. what is returned at run time by the evaluation of `#'(lambda ...)`) with `car/cdr` is rarely supported in the Lisp world. Stefan