From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring Date: Fri, 25 Aug 2023 14:50:57 +0000 Message-ID: References: <877cpqs6vi.fsf@web.de> <87wmxqs0ti.fsf@web.de> <616b60fc-9f68-14ae-d262-716eb0cc685d@gmail.com> <87h6ot19av.fsf@web.de> <878ra3q4kk.fsf@web.de> <87il97obdi.fsf@web.de> <87edju4mzd.fsf@web.de> <87edjsghyf.fsf@web.de> <87il93kbn0.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14993"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , "brandon.irizarry@gmail.com" , Eli Zaretskii , "65344@debbugs.gnu.org" <65344@debbugs.gnu.org> To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 25 16:52:17 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qZYAb-0003cO-1i for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Aug 2023 16:52:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZYAK-0006wO-2E; Fri, 25 Aug 2023 10:52:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZYAI-0006wE-Ab for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 10:51:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qZYAH-0001On-63 for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 10:51:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZYAL-0006BJ-Oq for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 10:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Aug 2023 14:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65344 X-GNU-PR-Package: emacs Original-Received: via spool by 65344-submit@debbugs.gnu.org id=B65344.169297507323683 (code B ref 65344); Fri, 25 Aug 2023 14:52:01 +0000 Original-Received: (at 65344) by debbugs.gnu.org; 25 Aug 2023 14:51:13 +0000 Original-Received: from localhost ([127.0.0.1]:41045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZY9Y-00069u-Ch for submit@debbugs.gnu.org; Fri, 25 Aug 2023 10:51:12 -0400 Original-Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:61322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZY9T-00069j-FC for 65344@debbugs.gnu.org; Fri, 25 Aug 2023 10:51:11 -0400 Original-Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 37PDOC1W021100; Fri, 25 Aug 2023 14:51:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=FvKkMLtxUi8G0F5kqtIr1vUlfYM2bFXnLYAwbqwruz8=; b=WEHYT+PiwcFXt/dilF6DhqaHL/qNiIWR/GUKvvoSmLu7zA8BjrvuROjQ5tCe/qmQI5nF xYcDJ6QlKtQpJISOFsuH3yS8uLv4UmsGsGS5llZehbOEz2fKWkEYW/y7piIkc+QPisok ZhI7goc/Uc0W85LKQQWIy98jIrQEGBcJbhEHAef1YdnE0TQ/v+vMkwXS9mZDqM4yhdtw GnwKhPEYdbKoqq3wnMPwDInQFjhXJsMPKwOKy512MrcHD3OhdAcD3OkyHF73Qrv0mlEz GVx67gSouUhofVPxOcz2CZzmNo2UICBu0yxo9MsPf1ZwRJE8yH36oht/BZKQXrvb2bK7 7A== Original-Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3sn1yvxk18-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Aug 2023 14:51:01 +0000 Original-Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 37PDXuWR035838; Fri, 25 Aug 2023 14:51:00 GMT Original-Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2171.outbound.protection.outlook.com [104.47.55.171]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3sn1yqx3km-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Aug 2023 14:51:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVFeYll7ZYGjcFY9czouxnCJuLWqYfffnHIcCi9aNmFfokjTwEMET77CqR/kfeid8LSO3zbP2QuUSzi0MNyZdpPVuz4yXb+BbPrbWJZCG8+e+9K3t3aC2aENzAKmAOQyBCjYCQrXlpKwS0EYcGwaKM957PkJ51clTb1JL4+m95uVAyAv7WclvIg2G9X3b2V/XhKM9Uh8r//WQv2Xy2beU/Bhsfs1e0i4Ii/wX8awHAD9Syh3dUKJlNusdXSGLphcTnGH80gmGlT38KO+LlyhSNiFHbmQMLCTZNuQHwCuJvhikqHv+1pJJDYW+pNWmUvD1kz2Hht+dbDpHpF5gD0bXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FvKkMLtxUi8G0F5kqtIr1vUlfYM2bFXnLYAwbqwruz8=; b=fwLewsBcUwGzkR4c9qeBHi7f5nZKfwdKo5cXNODgmeoWWAKm2WNDPQlYgyQWaLFqYl6FtapTiefdvHu66FSp8oAfr5m/7huV3bPzwIQzWSyNZTq1Co2XEfb/WJ/P3dVb0FclVxmenOLPwCt8BrZMaWbaxzVOujW0N0iHwDNeVlmqYj2LvvhefN7MD7qkpy3PoFxgKVEFZSPHOTu9QF7i6UobxlnpNVTu4UUZDS5zux0iO80kmvZI1Izfr0vN+UmEIV0AELceAoGQb+b0udAaKZwycOQ1IdlNx43GzDoPXhXD1t9k2lS0DLwuWZII+Tl4XFnPwQMKwlH5I95WC8bcRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FvKkMLtxUi8G0F5kqtIr1vUlfYM2bFXnLYAwbqwruz8=; b=NTj0cdAEuL6xZQNXYXC8tyihd+gWRxdiNdSrGzVo2zHXD6YfK0l9T1ydeDiwhrM8PwwCMseZ66I/L4YC8OrayxsxZbQpjgHzWBaie54XEPDejCwzJgpmpw74dTWHZCb026hxYhSqB/v+4Cu/zwAHQVQpMW2FWd41AFd3I/uS2io= Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by DM4PR10MB6814.namprd10.prod.outlook.com (2603:10b6:8:10a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.30; Fri, 25 Aug 2023 14:50:57 +0000 Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::7da3:721d:d706:8496]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::7da3:721d:d706:8496%6]) with mapi id 15.20.6699.028; Fri, 25 Aug 2023 14:50:57 +0000 Thread-Topic: [External] : Re: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring Thread-Index: AQHZ1wm66kul9q3GU0+5SbjRqhCvOK/7DrMg In-Reply-To: <87il93kbn0.fsf@web.de> Accept-Language: en-US Content-Language: en-US x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR10MB5488:EE_|DM4PR10MB6814:EE_ x-ms-office365-filtering-correlation-id: d77fb2be-ac1e-47be-5512-08dba57ab0d0 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QQoICRUa2xzNWkQ1/6Q6ZczUU52S9t2ecMj0YTtnMqGGTMmBf/OApdgq5ErXjKqC5iKlVOTTdfAPR89O0qAePhrrFvWf8T50S/FCVHh+NJXTdtY69UUg5ILADZH/PzMVV6M19pqhswubA49U3LR7m0qBG+DCZiYpyM4OpWCDRHCMlzq1TTzMBgOrFEuYBdWsu+ddENLdzjPgDMb5gsEVbN15VJ2z0ws/3brWR6bkzljCeHglqQMWoEsrUUXbl7aT9QFQlA8wjavncIBSkQ4vNDC8BO02bWMJ2FbfTSk6CLhFK2i8kVeGMwDiKxVfiZ9cXJJ22HtJcz+IQr5octwlMYYN12SZk8QgTLCut1nNbtmxA8psGQzTLL6XL9GXaTpJdCnw6k+UKV82OXGQCMgeDAyOwm8tyM345gyyOjzGNoHjky0uzbSPUYs1L8W3pLyk9kNhbsjkTKJex3h9Fi7RGp0ZtzjdbiQjhwXdVudQKQRVYFRk6OPfM+ciWOOopaLl5azXupQLAEi4WZSJQjE8DONXRlidyFkLBQ0UrSzSwzEJ99P8JEQGO+WNVRbR3odkez/+YDq7fYnllJl7T/XKcn1gyEsuHqK1u1o0FopQdNeLnETPfeXfuYcsS2wkDP7/ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(396003)(366004)(136003)(346002)(376002)(39860400002)(1800799009)(451199024)(186009)(5660300002)(8936002)(8676002)(4326008)(52536014)(316002)(26005)(41300700001)(66476007)(2906002)(66946007)(76116006)(54906003)(66446008)(66556008)(64756008)(6916009)(44832011)(478600001)(71200400001)(7696005)(6506007)(9686003)(55016003)(83380400001)(122000001)(38100700002)(38070700005)(86362001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: pMvNXD5o65Ssu2hoEQ3Yt4BZnzrrNqVGprWMGhpZBCjWLDkKgtcVSwSpb5AnoKOZdYu8DF4GAhL3ajCdSKFMrzmHHs1ayPMUWqyZYNVPffASrqlaXejEmY5fObiMeGj3Cq+BV9EzBMRY05oSMsLDQ1SBcAbxDBvLP1fMLC6fsj1jQOIKdd7BQoClSbDcEynoTyyyUPzvv05zgDILzuXtDkSsiHj2TA7eedRLzL68FyaagiL7JjP8ETYjx2VT0lvLDZYmXnb6uRi1nik0kKXrotyD0tfh5LUUqqYQdm7hZFfbYk4klkEqqqPNnLcXJuQrRITeMDUP4pPocljPs0ufCLt4MbTuGaMJhd+/5ELF/pZgmvHRCyn7Dau1bNdtp97XG8wSaBMncFwR9eeScdezUAJMxeSzf8x5b5EmLVWIk8viTxPv8ngTBA52Tv2hXVxqLBRcoLK4FUbOI/W//i4e60ve9ZzS3FV+8qQzdluzMhjuaN9hfUrUI9eY7rW6nls5nOsa4r7HTxlCHHD7YbmHJQhGo6TrXFw6iZIIcFk0xZB2GcQ6mOwQLGwjGwsOtSlE5Vycrkcf14KHkkdbtV6SW21YP5QUE+m3iWlp8vRx6REA8DUBsVxWmyjGzxZOZjHFVv54TlShFiYw4RDnTL3p9h9Sc7sce48ERTqqi76dKmaD8rOzMqHk2vaqM2EDVoGY5gn8d3H6hFcTASdwYWz7Dc51aEPGVZBIOsCvEFmW1mXusZotW5Q7DOrFF8 s/i2LmbdvVZQmBjrbWM1K44CVRJM0F974zj/zWF6gi0V2GZQxmxidBwEySs258DT2ELSQMyrXx4S3Rbp3k2ZEnCo+WcNtO2bfb X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 3L4g7GqS3WVfiExAxgrpo6SVi1T1Wqq8zB/eZb1IHVxtMSTK8TLsOSjdBp/6zHrlnOF86euamnXB1efrYReQAi/EVFkfGGfErA+H0GH5dRr6YOBo8yXV0KMVtiOjLbpC3PIwxEfZjL9zWMLUYlxUkB0Z+lEHrLRi0bvhKiwrBxFi9tGAOAyu8oYj67N3cH3qEY6sbFe/Sy0RdqmGGCQ3WnlkPe9C9D1K8DvgzLVtHnKloDGoyoyNOdVRGi66Rzsb4+gRMTXdty3SsCVqpweaK2GAY2mlvFh1ZDAtDIVm7lDEnLMufNa405GBSVlEk1lm1HBiio7uQiysjqS9dDn5h4h5cPzb8UfzIChNuTZ2H5ih8LKmeqx9KUdtkcSMXv9ZTMO9z/MT2B58/w5djAOYw1THELb7I/Z7sF6PUWJvzD9xU+IfesCpuYNZu4XM4exrMqo3e04dmcnwN6ijVOEsy5vs5G0gOscJGRpziWk+0cFuJYtW+1szgUROgjvyEeMig4QlgSEKDs8PBrSI7j5QrJ7IgN7JjRBAf+SnjTq/lL2JiMHaSiK+VjZcGaOW7pD/lYcqvqaLElJY1Cwh1hVMxjjgdysbcKVUHPS0DrKoxUy03dj2U1GrbXU3wwrMCJDLfNMKFwFOEQbEwoVgp5OZtglWVzEnN7MS5Rk68VaAJr+J1htg7Awaz/qaQ86/HFonyTYfbXBNX28JhiKM9ngiUQBflrvvpzyehWDFqTm44F8RZX UdC8s4e/jfukWahE+tfFAfy7O3DR5NYE5tnL8rXNuKHXbAjNgb1fiykQNCqdKUdUGTuFL0N4nofmjPEp1WReLDPJfO1H12luQy X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d77fb2be-ac1e-47be-5512-08dba57ab0d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2023 14:50:57.4075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QQaB4GJlvwY6W3COzGVdxNGS3fwG8eb2s1D916ovc7EH+X167xGXal9Zf1Ls7zknkc28iejDiC4dz+bMucMhYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR10MB6814 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-08-25_13,2023-08-25_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=811 malwarescore=0 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2308100000 definitions=main-2308250132 X-Proofpoint-GUID: qoX7GB1M19qsUTr-wk2E5Hngbgrop6Bz X-Proofpoint-ORIG-GUID: qoX7GB1M19qsUTr-wk2E5Hngbgrop6Bz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268437 Archived-At: > > If something is somewhat like a CL construct, > > but it is intentionally different in some way > > (and not just because we've implemented only > > partial support for it), then why use the > > prefix `cl-' for it? Why not use the prefix > > `el-' or whatever? >=20 > That would be much more confusing IMO. `cl-flet' is not just "somewhat > like a CL construct". "cl inspired" would be a bad description. The > manual clearly describes the limits of the "emulation", and, as I said, > even more limiting incompatibilities do not stem from such extensions. You seem to be guessing that by "something" I meant `cl-flet' or at least I meant to include `cl-flet'. I did not. I was speaking generally - the "If something" is key. Yes, I can tell from the Subject that this thread is specifically about `cl-flet'. I tried to make clear that my comment was not really on-topic, but was more general: about our handling of CL and non-CL stuff.=20 =20 > > Nothing says that Elisp needs to have the > > same things as CL. But why call something > > different "CL support" or "CL emulation", and > > use the same prefix, `cl-', that we use for > > things that are really intended to emulate > > CL constructs? >=20 > The library is somewhere between an "CL emulation" and a "CL inspired > extension library". It is hard to find a really good name and > description. Exactly my point. Instead of "the library", which is a congeries and can become a catch-all, let's work toward having two (or more, if needed) separate libraries: for (1) CL emulation, however limited or complete and (2) other, non-CL constructs, however much they may have been inspired in some way by something in CL. > > It's like we have no guideline or map now. >=20 > Naming being hard or not satisfactory doesn't imply anything. I doesn't > tell what we must do. It just means it is hard to find a "perfect for > everybody" name. That naming something is hard might mean that there is > a problem with that thing, or it might mean nothing. Agreed that naming is hard. But that's not what my point is about. Currently, we don't have two separate bins in which to place things: (1) CL-emulation and (2) other. So there's no reflection at the name level that's preceded by deciding _what_ something is: (1) CL support or (2) non-CL. > > To what avail? There's no shortage of > > prefixes and nothing forcing things with > > different purposes or natures to be in the > > same file. >=20 > Changing this prefix would cause work and trouble. I wasn't speaking of changing any specific name or its prefix. I wasn't speaking of `cl-flet', for example. I was speaking in general, proposing a policy of trying to avoid mixing in stuff that doesn't support our CL emulation with stuff that does. > If you think it is worth it - what's your > suggestion? "el-" is much worse. I don't care what the non-CL library or libraries might be called, or what prefixes they might use - other than not using `cl-'. And it might well be that some such constructs would belong in existing standard files. And maybe, as such, some might not need any prefix. > What in `flet' is more "Emacs Lisp"y than in > `let'? Again, I haven't said a word about `flet' or `let' or ANY specific `cl-*' construct. Dunno what gave you that impression; apologies if I said something that could be misread to make someone think that. As for `let': IIUC it's pretty close to the `let' in CL now (but yes, we have buffer-local etc.). I also don't have a problem with Emacs _not_ using any `cl-' prefix for something that does the same as what's in CL. We don't call our `if' `cl-if', but (I think?) it's the same as the `if' of CL. Likewise, our `cond' etc. And rightfully so. > Everything in Emacs Lisp is Emacs > Lisp. The "Emacs Lisp" version of `flet'? Of which `flet'? Ahh - of > the Common Lisp `flet' - but it's only 99.9% compatible, so we don't > call it "cl-". FWIW (as kinda said above), I'm OK with 99% (or even less) support for some CL construct, and I'm even OK with dropping the `cl-' prefix. The `cl-' prefix distinguishes something that emulates a CL construct from something else that might otherwise have the same name but is not CL. E.g., our regular `defun' is different from `cl-defun'. If we didn't have our own macro named `defun' and we had only `cl-defun' then (IMO) it would be OK to call that just `defun'. And for clarity - to let users know that it's essentially CL `defun', we'd alias it to `cl-defun'. What I disagree with, as expressed in this thread, is the addition to a `cl*.el' library of something that's _not_ a CL construct, and giving it a `cl-' prefix. _Why do that?_ That's the question I asked - to what avail? > This line of argument is not convincing me. If a user has looked at the > documentation (one has to anyway to get a start), the "cl-" is also > hardly a source of confusion. So I still don't see a relevant problem. OK, so you don't see a problem. Do you see a reason why we would add some `cl-foobar' to `cl-lib.el', if it's a function that has no relation to Common Lisp? Does it make any sense to you that someone might expect it to be housed elsewhere, with a different prefix (or with no prefix)? That's all I'm trying to say here. Let's avoid stuffing non-CL stuff in `cl*.el' files. Is it necessary to clean house wholesale, moving and renaming things to fix this mixup? No. I'm not proposing disruption or extra work - just a recognition of a will to avoid adding not CL stuff to `cl*.el' files and giving it prefix `cl-'. Nothing revolutionary or heavy-handed intended.