From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Lispref add-to-list - doc is unnecessary convoluted Date: Fri, 04 Dec 2020 04:29:10 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2934"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Robin Tarsiger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 04 04:30:14 2020 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 1kl1nP-0000cB-KI for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Dec 2020 04:30:11 +0100 Original-Received: from localhost ([::1]:40724 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kl1nO-000305-Hv for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 22:30:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kl1mW-0002UW-P6 for emacs-devel@gnu.org; Thu, 03 Dec 2020 22:29:16 -0500 Original-Received: from mail-vi1eur05olkn2058.outbound.protection.outlook.com ([40.92.90.58]:60129 helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kl1mU-0003JE-I9 for emacs-devel@gnu.org; Thu, 03 Dec 2020 22:29:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PZLdRgkjyfXJ6DUJcFmeBlsh1UEJozYbEvE6lBPrb3CRwi4Z03CNMUBqiAyVwiK4BiLXDOdovByu+COVCnUJxLMMcx7Zm9sssi50Pxtp6p8yo51bvW4fx0BEARaV30YCZ/tT5ffvL7bp07Exg3JQhD3fEiUoP//AehpOoU+xibQY7QuxaNcswBQKXkzppzQUaelw4Ku0HtHhSSsIHKgB3KbEP1B5aY5yNLj/wAvycDAkCXOUyp06MccBW97sQtbx4HLl/O+5Jb/AIelch/x0c9Nu9aMBFnK0Ed3G4zDAXOkvwXWrBxcIHD7J+3LopmIVRI7aGVeKdFHv8JFiJifTow== 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-SenderADCheck; bh=+9tFWR/r4OYN9gBTfzEN25QJjp6HrzFqvLTsvRyV2hE=; b=VhaCKNgE4q5g431MsE9vBM1r9dVjvmF98D0488hj+Lpgu/Ks0JHFVTto19F6ilNlJpmwW2meWRrVriaVSUAPINUHj0g4JTjM8DiLbkKenGNq+uXwCj1FMrO1BDs8EarYvwZ3ZlNUhXu3DNcCnkty/9rZi8RsuYyKJ4cQvnUFQeQTmyho6g8+5+iZ3pgAFYM0+JhYJga7zelFKdYZWn69k6t19P4yMyNh8LB2pbKgLPJ5pzWdvfBdoILQqR4tPNxeLJZ77mRwD2LpfBqf1LKW+yLLSv9cfySFhvVIdlR7HDqaqFppOjHIAC3wsHX+oTyCYrCklzboe+0vVDp3p/g1kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+9tFWR/r4OYN9gBTfzEN25QJjp6HrzFqvLTsvRyV2hE=; b=b+eqILvL4rBoRoDHqMZ/qxXMNH6lMlQdHuchRdeqsXvX+GaQIMEKRMqVfnWeghcc0pzAp1/pAovDk5eloUAYqQ13Y7kiWpmQbQZIo3CLEBqtXRFbYjf1oW+2FG1y5XFE1QCUjkMjS8x3ttp+MJLlEwGNphSXPanpJ3wQOwMG1nDFig29RjgYutZRlqX7jIUudBaqPsgAKthXTIAJz+Zzfua2byBg3QMn6eJzkysDqyNqDbJJScRhG+LNTpiopduE2QOJTq8EgbkO+fRr+Arp9G3roVzIevPs72Dyu+VJciz7pRucg625AFOq0+7UwX9BOat6/2SQ5DiNcCK7ZsI0Ww== Original-Received: from AM6EUR05FT021.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::48) by AM6EUR05HT064.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Fri, 4 Dec 2020 03:29:11 +0000 Original-Received: from AM0PR06MB6577.eurprd06.prod.outlook.com (2a01:111:e400:fc11::52) by AM6EUR05FT021.mail.protection.outlook.com (2a01:111:e400:fc11::237) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Fri, 4 Dec 2020 03:29:11 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:928ED131037F6569BB6C1136B2EEF18B88500B4C33C815C17AB32A82254E04AD; UpperCasedChecksum:C162505F8666E42B49E756FA94B051DD9E6A7B60A56A8A43AA3F87914E6F1AE8; SizeAsReceived:7512; Count:46 Original-Received: from AM0PR06MB6577.eurprd06.prod.outlook.com ([fe80::9487:8c7d:da00:4993]) by AM0PR06MB6577.eurprd06.prod.outlook.com ([fe80::9487:8c7d:da00:4993%7]) with mapi id 15.20.3632.018; Fri, 4 Dec 2020 03:29:11 +0000 In-Reply-To: (Robin Tarsiger's message of "Thu, 3 Dec 2020 20:36:49 -0600") X-TMN: [X/yElRV+f6zxjQS15dRz3XAp+ilPsBar] X-ClientProxiedBy: AM6P195CA0065.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::42) To AM0PR06MB6577.eurprd06.prod.outlook.com (2603:10a6:208:19a::23) X-Microsoft-Original-Message-ID: <87h7p2b661.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (90.230.29.56) by AM6P195CA0065.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Fri, 4 Dec 2020 03:29:10 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 46 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 0766a3fa-e3c6-4cf3-a43e-08d89804c3f0 X-MS-TrafficTypeDiagnostic: AM6EUR05HT064: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DfEzhx0BaVYjtAJbg0AS7pp5ZQp+vWCYTXLnF395lyjJU8MJbGVJHC7C4rZ3qOKFQZhEV3bI5OlJie49H8XbuVEhGlEmhL33q9h261QO0p89OrlGItHd57ktQb8HuEoGSR5plR4SRflERj3lPoUz/XGrWpggMDVok/6qbcrbC9Yzz3IcEGyt6WDyR/QijlQZ8vQdsBNe4eXKfO5CPv9xXA== X-MS-Exchange-AntiSpam-MessageData: aawUy/RXTaXgnqXFd7lhE3rj1gEvEoW24LKNZT+it6uOnj7YjAx1u7gpUE8pGPG6c1KNxxR3Zct1L96oqkIGPuOjZMKILqcdADoK8ZzMB49yQ8pFZOigF5cy88Y5TLhFskIs2qFXGooChiZ2jn98Nw== X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0766a3fa-e3c6-4cf3-a43e-08d89804c3f0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2020 03:29:11.1914 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: AM6EUR05FT021.eop-eur05.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6EUR05HT064 Received-SPF: pass client-ip=40.92.90.58; envelope-from=arthur.miller@live.com; helo=EUR05-VI1-obe.outbound.protection.outlook.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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:260267 Archived-At: Robin Tarsiger writes: > Arthur Miller wrote: >> I think it is more clear to use word 'list' instead of 'symbol' (element >> is a symbol too for example). Not least because docs later says: "better >> be a list". It clarifies intentions, and hopefully removes the need to say >> things like 'better be a list'. > > The first argument is not itself a list. The value (as in symbol-value) of > the first argument is expected to be a list. The first sentence of the > documentation has that many levels of indirection because that's how many > levels of indirection there actually are in the behavior of the > function. > Your new text does not describe it correctly. Ok, I agree; my explanation is not that pedantic as you are describing it; thank you for pointing it out, I wasn't so pedantic when I was thinking about it, even if implicitly understand it is so. However, I must ask is that distinction important in this particular case? I understand you think so; but if you think twice or maybe three time? I am not an lisp expert, and obivously I needed to look up exactly how the thing worked, so I red it, despite being using it for very long now; and I will try to explain how I percieve the issue: This pedantic treatize of the language, which is more correct than what I use, is surely correct and has merits, but is it necessary for the end user; in this particular case? I think that pedancy in this case adds more confusion then clarification. I think that conceptually we think of adding to a list, not to a symbol or to a list-var. At least me. The function name itself suggests we are adding to a list. When we add to a linked list in C, we are actually copying a value of an address into some other address in memory; but we use term "add to list", because that term let us reason in terms of higher abstraction. In this case cons is the primitve, symbol is our pointer; so what is wrong to reason about that operation in higher abstraction as of adding to the list? I don't think LIST-VAR sounds much better (or worse), per se. It sounds better in combination with "to the value of": "Add ELEMENT to the value of LIST-VAR if it isn't there yet" Maybe that should be in lispref docs instead; entire sentence. It is still more clear than the current version. In my opinion. Opinions are subjective :-). > "cons onto" a list is more specific than "add to" in terms of where the new > element winds up, I agree that "cons onto" is more specific to how the operation is implemented; but I don't think it is necessary for the user of the API, nor is actually position really necessary; it just says "adds"; but as you self note, it is mentioned afterwards anyway, which was one of reasons I reflect over it. We can add it to the comment below the function, where it shows alternative implementation. I can agree that it is illustrative and more of a "tutorial approach" so we don't need to throw it away completely; but I think it is also important to be clear and concise, especially in the opening to a function, which add-to-list is not. I can rewrite and add that info to the end. > But while looking at this, I notice that the C-h f docstring for add-to-list > that I see on my Emacs names the first argument more clearly as LIST-VAR > (neither the correct-but-overbroad SYMBOL nor the incorrect LIST), and has > the first sentence "Add ELEMENT to the value of LIST-VAR if it isn't there > yet", which seems to hit both of the points you're dissatisfied with. > Might that be a better starting point if making the elisp Info entry > more readable is desired? It is always desired to make any programming documentation more readable! :-).