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?7KGw7ISx67mI?= Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Mon, 4 May 2020 03:12:09 +0900 Message-ID: <7B8AEA49-60BA-43DE-95B4-5B9FBAEEFB6C@icloud.com> References: <87ftchy0go.fsf@gnus.org> <0EF66D20-6EDE-427C-AF19-918E7003C85F@icloud.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="10298"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Stefan Kangas , Richard Stallman , Stefan Monnier , Emacs developers To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 03 20:13:12 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 1jVJ71-0002Zz-Ok for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 20:13:11 +0200 Original-Received: from localhost ([::1]:49446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVJ70-0006rR-RM for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 14:13:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56380) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVJ6A-0006SP-S5 for emacs-devel@gnu.org; Sun, 03 May 2020 14:12:18 -0400 Original-Received: from pv50p00im-ztdg10012101.me.com ([17.58.6.49]:47879) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVJ68-0004Fw-VB for emacs-devel@gnu.org; Sun, 03 May 2020 14:12:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1588529535; bh=ncakIQApE27PSRVELMwdsktgQezQM/qCQxaT1qL/BAU=; h=Content-Type:Subject:From:Date:Message-Id:To; b=TqGIb2cV26W0kEqLBAWdFf0wneugYokBnw6Unqr94E1WO0DODK++5knpQANe8R1z+ lTVX4Ax2bu0p6fQgxcF9J/38X2S5SoHdbPi5jBA0p52OEStf3tJ0oZ5/hcu4zbQZNG 88fUJ3oE/SX74iRg/153pkHraVd3eNmlM4HcQGXsi2lmvaRRZNB1h2bNCU4FCojmmL Yd6LOWF8GPFgoTE8+LdNILFJ1bEJOz3R7pCiWEhvxi5BCXFr+iOwNgaG5/R/m6auAU n1G+BwPojp9BzgGrxeaGZZnqsJotc8wG+uI2U0HXuz+m8kSG06bIlWtTYzn/GCxFSl bktg7OE43fhkA== Original-Received: from [192.168.0.2] (unknown [1.230.108.64]) by pv50p00im-ztdg10012101.me.com (Postfix) with ESMTPSA id 08FFA84015E; Sun, 3 May 2020 18:12:12 +0000 (UTC) In-Reply-To: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-03_09:2020-05-01, 2020-05-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2005030165 Received-SPF: pass client-ip=17.58.6.49; envelope-from=pcr910303@icloud.com; helo=pv50p00im-ztdg10012101.me.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/03 14:12:15 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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:248732 Archived-At: João Távora 작성: > On Sun, May 3, 2020 at 3:52 PM 조성빈 wrote: >> João Távora 작성: > >> The problem here is current Elisp isn’t 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’s 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. 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. > For a newcomer to Perl, there is _no way_, > unless super lucky, to know that 'chomp' will remove the boring > parts of a string. … which is definitely one reason why Perl is called ‘line noise’. (Disclaimer: I have never used Perl enough to know it’s syntax, so I might be wrong about it.) > 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. If you’re saying that new conventions should not clash with existing conventions, that I can agree - I can’t agree that new conventions shouldn’t clash with idiosyncrasies. That’s the point of conventions, to remove idiosyncrasies! > 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? Maybe it’s not a literal question, but in my ideal world, functions that aren’t destructive should read as nouns (e.g. trim-string or string-trim), and ones that are destructive should read as verbs (e.g. trimmed-string or string-trimmed). > 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. (FYI, I don’t think that polymorphic functions like concat should be renamed now.) > 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’s hard to be perfect - but that’s not a reason to be better. > And doing it on the > type is a bad idea, because polymorphism; I agree that prefixing types on polymorphic functions aren’t a good idea. > 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’s been renamed. There are a lot of functions/variables that are already in similar state, IIRC. > 3. encourage you to deprecate and eventually remove names, If the old name’s use reduces and eventually becomes close to zero, yes one might deprecate & remove names. > which breaks programs and is a shame. My personal view on this is that if one hates breaking things, one should just not upgrade. However, considering that Emacs don’t really remove much, I think just marking them obsolete will work, without breaking anything. >> BTW, a quick check from sly shows me that cl:split-string doesn’t exist >> - while cl:string-trim, cl:string-left-trim, cl:string-right-trim exists. >> Which probably means that it’s 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 saying that we should bring string-trim, string-left-trim, etc… It was a response to this: > Shoving this foreign > convention down Lisp's throat is cruel. And ignorant, sorry. It’s definitely not a foreign convention to Lisp. > 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. I think you don’t need to question them much is mostly because you’re already familiar with the CL names. I actually feel this same problem when I try to write some CL - I like the language, but the std is too inconsistent. Cl21’s 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 and > gethash). To put it simply, the language is time-consuming to learn. I think this applies similar to Elisp. > 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 something like make Elisp look like an another language project. > 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 > readily > 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’s not always >> the answer, but it’s something that people value & appreciate. > > A std that changes according to the language-du-jour is not a std > by definition. > > João