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 20:41:09 +0100 Message-ID: References: <87ftchy0go.fsf@gnus.org> <0EF66D20-6EDE-427C-AF19-918E7003C85F@icloud.com> <7B8AEA49-60BA-43DE-95B4-5B9FBAEEFB6C@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="116119"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Emacs developers , Stefan Kangas , Richard Stallman , Stefan Monnier To: =?UTF-8?B?7KGw7ISx67mI?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 03 21:41:59 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 1jVKUx-000U6E-DM for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 21:41:59 +0200 Original-Received: from localhost ([::1]:57062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVKUw-0001ED-6M for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 15:41:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36642) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVKUQ-0000oV-I4 for emacs-devel@gnu.org; Sun, 03 May 2020 15:41:26 -0400 Original-Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]:33371) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVKUN-0000Zd-Uj; Sun, 03 May 2020 15:41:26 -0400 Original-Received: by mail-io1-xd44.google.com with SMTP id k18so10199881ion.0; Sun, 03 May 2020 12:41:23 -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=JUh3/tkjOm2TxYjbosGkCcxrxaQg8e5+pSOKvpB4EO4=; b=OPRwxDnbHgA3We/rSo0cpNBL8KXgwVloGFyOJS2rXd3Hicwioyz/0GriJs2oTHCP99 dfzb/vhGHLNp8Unyv0CysSCJ/j3CmUc09JIXDnCqtNY2WZpTfQyjlMwCdxLXS+J8drdj MQ223HbjADrgPq7kLcGoOtxShu5kdlk51RpQLNN2UFF0x4lAp1TOqVz/JqqZRyIglLuX kHyCGIR3kHhAXxkt53vbuOXDGbvc/Do+XkuMqa37Uqjw1o1Zst0fy2U/Kef7ha5ahBzl p0ukMhj3n2Z9Te4XKqrmXYVk/363SFtImzzQVjQLz35Q+DL+BOJA+dc1BCV2bIR2mQQH NnOA== 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=JUh3/tkjOm2TxYjbosGkCcxrxaQg8e5+pSOKvpB4EO4=; b=XdksMpY5Y3V2vFOeG9P3zAquwCE97GC/+DEqLDx8czumkoYJ3FyARo/CkNL24QM8UE jf0wSCF18CMmRt9kvGkhWgfLhqEXCOueglGXBINE11jiDx/kJ3n9gxjACgWzEjpAGsCW BB31zpObX32Dsp+KOQTK9HSi6nIBySH0Fc9dMoETUtiIso+ldND4Log4cvrDjeoplyEL iow+J/lVJbfyMs081tuuBwMmlPLqYtFrwm4WTx2toUmRwI4Lm9kNlfRwVbRkjLWc97fx f+n/dKBU+kO70yL0WG7WHjUKztb+a54YetX/wNizmrY5aIz/+bsCdJh8lWkF6h5xX6dW V21A== X-Gm-Message-State: AGi0PubKDeB8pITukJjk0N8zm0aR8W9+hHX5EKyF/d+skO6tWynA1bRf CGpK/pAefsXqwVVHxauDI+0Xk26l83hl6qnW7Is= X-Google-Smtp-Source: APiQypL4RDtyLDi0wB+gbTcdEAcAwpe9n8YN6gapKH8MOn6whZ4BFKqZUsbcBA3pRYc+gFLBKOaMtjwlU9zlsbX0EdI= X-Received: by 2002:a02:205:: with SMTP id 5mr11658242jau.78.1588534882125; Sun, 03 May 2020 12:41:22 -0700 (PDT) In-Reply-To: <7B8AEA49-60BA-43DE-95B4-5B9FBAEEFB6C@icloud.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::d44; envelope-from=joaotavora@gmail.com; helo=mail-io1-xd44.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:248735 Archived-At: On Sun, May 3, 2020 at 7:12 PM =EC=A1=B0=EC=84=B1=EB=B9=88 wrote: > Are you calling Elisp Lisp, or are you calling the Lisp family? > I personally think that both Scheme and Clojure has a pretty consistent > std naming scheme. As far as I know, Scheme is minimalist, and has modules. Common Lisp and Elisp are not minimalist. And Elisp doesn't have modules, possibly because no-one ever thought it would be one of the most popular Lisps. And Clojure as far as I understand, doesn't have to deal with a class of problems such as mutable version of each function, and crucially, has namespaces. So you have multiple reverse's apparently. One in clojure.string, another in clojure.core. You _don't_ have string-reverse and seq-reverse (again, I may be wrong). > =E2=80=A6 which is definitely one reason why Perl is called =E2=80=98line= noise=E2=80=99. > (Disclaimer: I have never used Perl enough to know it=E2=80=99s syntax, s= o > I might be wrong about it.) Perl has lots of flaws, but its terse names are not it, IMO. > > And introducing new conventions that clash with the existing > > idiosyncrasy is _not_ the best way to solve it. > > If you=E2=80=99re saying that new conventions should not clash with exist= ing > conventions, that I can agree - I can=E2=80=99t agree that new convention= s > shouldn=E2=80=99t clash with idiosyncrasies. That=E2=80=99s the point of = conventions, to > remove idiosyncrasies! But the one you're proposing is too ambitious and flawed. > Maybe it=E2=80=99s not a literal question, but in my ideal world, functio= ns that > aren=E2=80=99t destructive should read as nouns (e.g. trim-string or stri= ng-trim), > and ones that are destructive should read as verbs (e.g. trimmed-string o= r > string-trimmed). Yes, I've used that convention in the past. C.f sort and sorted. But it doesn't always work, because English is irregular. > > 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"). > > Well, those bike shedding can happen in this mailing list. It already does to a point. But we tend to leave old stuff alone. > (FYI, I don=E2=80=99t think that polymorphic functions like concat should= be renamed > now.) I would think the value of s.el comes from the consistency between its members. I would really just like for Elispers to be able to use it without encroaching on the legacy namespace. > > 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. > > Yes, it=E2=80=99s hard to be perfect - but that=E2=80=99s not a reason to= be better. [To _not_ want to be better, you mean. ] Yes, than I will turn that argument around. We're not that far away from perfection that it warrants new names. > > And doing it on the > > type is a bad idea, because polymorphism; > > I agree that prefixing types on polymorphic functions aren=E2=80=99t a go= od idea. Once you start thinking of by operations rather than by types, many functions become generic. A big flaw in CL is not having gone far enough with generic functions. i.e. most people agree that generic arithmetic +, -, would be a tremendous gain. I guess the money ran out :-), so now +, - etc only work with numbers. Should we rename them number-+ and number-- in Elisp, for predictability? :-) > > 2. make many new symbols that will confuse existing users. > > Even new users ask: why does this have two/three names?; > > Which has a plausible explanation: it=E2=80=99s been renamed. There are a= lot of > functions/variables that are already in similar state, IIRC. In specialized domains, but not in the base general purpose library. > > 3. encourage you to deprecate and eventually remove names, > > If the old name=E2=80=99s use reduces and eventually becomes close to zer= o, yes one > might deprecate & remove names. How can it become close to 0? What about old programs? > My personal view on this is that if one hates breaking things, one should > just not upgrade. However, considering that Emacs don=E2=80=99t really re= move much, > I think just marking them obsolete will work, without breaking anything. Couldn't disagree more. Old programs are useful. I want them and their dependencies to load cleanly, so I can study them. The real-world equivalent to your idea is just throwing away old books. > I=E2=80=99m not saying that we should bring string-trim, string-left-trim= , etc=E2=80=A6 It > was a response to this: > > > Shoving this foreign > > convention down Lisp's throat is cruel. And ignorant, sorry. > > It=E2=80=99s definitely not a foreign convention to Lisp. Doing it in the scale that you originally proposed would be. And string-trim etc, already exist in Elisp. In the "foreign" purgatory of subr-x.el. Curiously, there is this comment there: ;; Less commonly used functions that complement basic APIs, often implement= ed in ;; C code (like hash-tables and strings), and are not eligible for inclusio= n ;; in subr.el. ;; Do not document these functions in the lispref. ;; https://lists.gnu.org/r/emacs-devel/2014-01/msg01006.html > I think you don=E2=80=99t need to question them much is mostly because yo= u=E2=80=99re > already familiar with the CL names. I actually feel this same problem whe= n I > try to write some CL - I like the language, but the std is too inconsiste= nt. It's the weight of history. But in CL there are multiple attempts (curious= ly not particularly successful) to write a modernized library. You can use one of those, and they fit snugly in a package. You can make that package your default package, if you wish and enjoy its benefits. > Cl21=E2=80=99s author Fukamachi explains this well on cl21.org: > > > Is Common Lisp sufficiently well-designed? I don't think so. You use > > different functions to do the same thing to different data types (elt, > > aref, > > nth). You have long names for commonly used macros (destructuring-bind, > > multiple-value-bind). There is no consistency in argument order (getf a= nd > > gethash). To put it simply, the language is time-consuming to learn. Oh, so you did find it. That is one of those attempts. But there have been more, I think. But I disagree with Fukamachi, or at least I think it is very naive. CL21 i= s an interesting project, but CL is time-consuming because it is big, not becaus= e of function names or signatures., but the many programming paradigms in one language: functional, imperative, OO, meta, exceptions, systems programming... It's enormous. It's not CL21 that's going to "fix" that. Really, the "learning names" problem is vastly overstated. It's only for p= eople who use the language once in a while. But that also happens for other languages. I just quickly skim a manual before I get back to them. Of cours= e CL21's authors are trying to appeal to that new impatient blood that's floc= king to Clojure. But they're flocking to Clojure mainly for the libraries, Java interop, concurrency features, and the real-life jobs, not really the names= . By comparison, the only language as ambitious as CL that I know is C++. Same hunger for general-purpose, multi-paradigm, meta-functional-system, imperative-type-hungry language . All backward-compatible. A work of art. _That's_ a time-consuming programming language. And they're adding and adding to it, to make it sexy for the cool kids. Are they succeeding? Open question. > > BTW Aren't there more interesting parts of Clojure other than the > > symbol names? > Nobody is trying to bring Clojure inside Elisp, nor CL. This is not somet= hing > like make Elisp look like an another language project. Oh but I wouldn't think it that to be a bad thing, on the contrary. I was asking honestly: is the best thing in Clojure the names of the functions? I find that hard to believe. Jo=C3=A3o