From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Sun, 3 May 2020 18:36:13 +0100 Message-ID: References: <87ftchy0go.fsf@gnus.org> <0EF66D20-6EDE-427C-AF19-918E7003C85F@icloud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="124334"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Stefan Kangas , Richard Stallman , Stefan Monnier , Emacs developers To: =?UTF-8?B?7KGw7ISx67mI?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 03 19:37:15 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 1jVIYF-000WGY-3y for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 19:37:15 +0200 Original-Received: from localhost ([::1]:59132 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVIYE-0004dK-3j for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 13:37:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVIXV-0002Xk-8h for emacs-devel@gnu.org; Sun, 03 May 2020 13:36:29 -0400 Original-Received: from mail-il1-x12d.google.com ([2607:f8b0:4864:20::12d]:40071) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVIXS-00058O-WD; Sun, 03 May 2020 13:36:28 -0400 Original-Received: by mail-il1-x12d.google.com with SMTP id e8so9145413ilm.7; Sun, 03 May 2020 10:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CSKIMtXvWP1ymDdQLqoi4l0OZkgScG2HwHTzub7VdM4=; b=I+DJGitHLNUqtKIa93bNlqUVtj9R8tIWlOe7cIiRJCCrF7DD9G+m2cznSebuFyKlcr AQwgQ5Io4Nvx51Ro7JrDJh7kPwk35jgz3X1ei146KNL3R9AA2N3FlXLbU/547w50zOnH tiXz7pxJgzmYR7UNXNZNeMtsk1XMq7tQW2vVWoMxFr9zBEQyW5dNiXegpIkfQ0E4Y19u JG3xzkMM9nXuKPOL50G/fQ7cHKbBvnNJ2H2kjjVK6rAF0VyCcMmlYepq2rrdNxVUpupb wTq1dPRHpaCLfUJEqSZPNX+27ceGUaFxPxQo8Jjt60u0BznPI/ij6YahA97mx3vQln/H dCUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CSKIMtXvWP1ymDdQLqoi4l0OZkgScG2HwHTzub7VdM4=; b=ItfGLT726tBnbxOLRfnJPihUhpFhADs++Vf4R/oObnjMQBjps93ZwHQagImyiAWhGr abOUU16TdCU11mFzr/tcWb26NzODINL+wmrwA6830Ji/alFrEvgVPADUPmaFMMbQcq6d IakVHfSQboX9gvC+RKY6HvGMCSkLS12leJsnoJSO2dwC6hqcC9SxEJUkhUr5uVjZrz1z WqiY5gYUDCSkP7lHTK9UhWjrhGWQBbMEvBWNuxPNgrMYXm0fmAIL3wVOy2U2FALPMh+S ht8xp2SvSVtgsB0e3eIuQ9qOUYBU1DFgydjlOGIuUAd+a/nM3CyvQB333/bh6CrnM5hU cnNQ== X-Gm-Message-State: AGi0PubS1vcZ093JIakgnELefSKnzFnnGJmfgMxlkg1e63wUEYi4d6jS rXBP+8rGezktgkS6SOrJjrZ+CaHZOBzHocF8gfY= X-Google-Smtp-Source: APiQypKehfxPiF2H2CjLHy7H+s9S/gZT6tNCGBst5aM7wYuWgI8DtFdJU0x0fvdcxFW4jwENytZeQRQwoLj0m+exEG8= X-Received: by 2002:a92:4a11:: with SMTP id m17mr12407668ilf.125.1588527385470; Sun, 03 May 2020 10:36:25 -0700 (PDT) In-Reply-To: <0EF66D20-6EDE-427C-AF19-918E7003C85F@icloud.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::12d; envelope-from=joaotavora@gmail.com; helo=mail-il1-x12d.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:248727 Archived-At: On Sun, May 3, 2020 at 3:52 PM =EC=A1=B0=EC=84=B1=EB=B9=88 wrote: > > Jo=C3=A3o T=C3=A1vora =EC=9E=91=EC=84=B1: > > The problem here is current Elisp isn=E2=80=99t predictable enough. Is it > string-trim or is it trim-string? Is it string-join or is it join-string= ? > Is it string-split or is it split-string? And that=E2=80=99s the problem = this > proposal is trying to solve. OK I see. And I agree to a point. It's just Lisp doesn't care so much about it. For a newcomer to Perl, there is _no way_, unless super lucky, to know that 'chomp' will remove the boring parts of a string. Predictability from names is not useless, but is overrated, because it will only tell you so much and it works better in some languages versus others. And introducing new conventions that clash with the existing idiosyncrasy is _not_ the best way to solve it. And people have demonstrated here over and over how it fails. Say you don't like an hypothetical "frob" and you decide to make a "string-frob" or "frob-string". Now can you predict from that name if it's destructive or not? And can you use return value? What if you can "frob" more things than a string? Sequences, multi-dimensional arrays, characters? What if frob already exists and can be both a verb or a property (like "match"). It's a losing game. Yes, some people have played it (and mostly lost) and these names are burned in the namespace. Because culture. Nothing to do about those. If you start renaming things for predictability it'll: 1. be quite hard to get right, if at all possible. And doing it on the type is a bad idea, because polymorphism; 2. make many new symbols that will confuse existing users. Even new users ask: why does this have two/three names?; 3. encourage you to deprecate and eventually remove names, which breaks programs and is a shame. > BTW, a quick check from sly shows me that cl:split-string doesn=E2=80=99t= exist > - while cl:string-trim, cl:string-left-trim, cl:string-right-trim exists. > Which probably means that it=E2=80=99s not really a foreign convention in= Lisp. > (And Elisp already adopted the convention of prefixing the module name > in the front, which was the reason this discussion started.) CL is foreign to Elisp, whether you like it or not (I don't, of course but hey...). It's just not _as_ foreign. If we're going to import things from CL I'd rather bring in specific CL features like restarts, packages, streams, multiple values. Definitely _not_ function names. I'm not in love with CL's names: I just know them and don't question them so much, like names of people. Lisp is a language of symbols and symbols have names you learn. The function of a symbol is only _one_ of its many facets anyway. So when bringing new symbols into the world you shouldn't try to be too clever about the name. Be just moderately clever. BTW Aren't there more interesting parts of Clojure other than the symbol names? And "module name" is a broken convention. It's the best we have so we might as well, but what is the module for 'car'? Again, for the sixteenth time, if we had packages, it would be solved: nobody touches the :EL package but everyone can make their own fancy "predictable" utilities package. _THE_ way to solve is is to transform s.el into magnar-string.el _BUT_ because of the lack of a package system, that means we have to (magnar-string-truncate 42 s) which is a pain in the s, I'll readil= y admit that. You should be able to say: "I want to use magnar-string.el _here_ because great Clojure god". And then type (truncate 42 s), (left s 3), and be done with it. Or use the local "s" nickname and type (s:truncate 42 s) and (s:left s 3). But you can't, so you want to shove it, figuratively ;-), in the main library but that's really hard and controversial and for every compromise you make you start doing the original s.el library less and less justice. > Seriously, a consistent std is *not* Java. See almost every programming > language - consistency is something that people value. It=E2=80=99s not a= lways > the answer, but it=E2=80=99s something that people value & appreciate. A std that changes according to the language-du-jour is not a std by definition. Jo=C3=A3o