From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: transient Date: Thu, 30 Apr 2020 21:26:07 +0200 Message-ID: References: <87368npxw4.fsf@bernoul.li> <87v9ljo5d0.fsf@bernoul.li> <87ftcnxu5m.fsf@bernoul.li> <83y2qezlpd.fsf@gnu.org> <83tv12zjx1.fsf@gnu.org> <837dxyz83p.fsf@gnu.org> <978f970b-b5c2-bd83-39da-f632d069d7d5@yandex.ru> <98ab19cf-680b-9cd2-7c42-89dd0b2f470a@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ea61ff05a4870ad7" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="84320"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jonas Bernoulli , Emacs developers , Stefan Monnier , Adam Porter , Eli Zaretskii , Kyle Meyer To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 30 21:27:21 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 1jUEq8-000LnC-KM for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 21:27:20 +0200 Original-Received: from localhost ([::1]:45430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUEq7-00036A-Ik for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 15:27:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46440) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUEpa-0002Yk-Pg for emacs-devel@gnu.org; Thu, 30 Apr 2020 15:26:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUEpa-00028S-CD for emacs-devel@gnu.org; Thu, 30 Apr 2020 15:26:46 -0400 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:39885) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUEpQ-0001zE-6d; Thu, 30 Apr 2020 15:26:36 -0400 Original-Received: by mail-lf1-x12b.google.com with SMTP id v28so2201063lfp.6; Thu, 30 Apr 2020 12:26:35 -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; bh=yTCvTftFitCV6oVO9Hvit7M/FiVQLOqIho2l+mjsgM4=; b=G8MZuCsf5zWcXBiAUVWaetQ6HyoLuiVdNoakcLD/+FVW2axk6kUwaSNO9LxOwCo4cc LtI4GiJZpD0XwH6qhO8BHtrP8wRn+8If0Zo9d+oIAEgWW+I24Y7OjdTpw8nw4e2fIGhl fSIttIWFJB+RMGVUtCR/1yUIRwZ6j5JFbQnC9Vtd8ExAn6pM35kFsciWo+0q6+t4yFUN 22v3DBk+TrIkWgeZpe68V41wf+USl/ebuIhBs8ZUAv8Jf7dpp94gTAWitR8Z+P27zecG KIXEH6z24GO5pct1k5dmEJm3JXRe80s4TpWA7yLTaGn03vHZPk9fRLXGA4rziuAjq2XH rRaA== 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; bh=yTCvTftFitCV6oVO9Hvit7M/FiVQLOqIho2l+mjsgM4=; b=KUgv5ueYWw684/kujvSe1oT9Iq5n4g86UiMO6BydCkNh8ii7lbmnTBvb3myV9GpUWP d8AusAO/uGCg3gDZiKPMFKLwwDgyC7J1DB/tGHafgm7ru1w6Ic2Eg9txbgiAfi+hNxqV 68uLO524P4VScAQyg5qNRsTqwOpGB93qTudYNAXcVNd0ducyENRkFK29/bPn8J7gZfKX q8CEe39zZyfJ/rQJcBHA/xZMNUfJsnmrmSiuBYAisKRefJZaa6myAR9O2m0E6TZbEe0Y z5sD17VphuwqLhuS5+1lNS12q2BgB+rPpUoQwyyc/PkqrF1dHmjTmms70ng9gAPHkWX/ bRgg== X-Gm-Message-State: AGi0PuaJQDmmeCLgFz0EqzYPiwg8Lj3l9grRLsGEXMdfzUu12ZsyTIz9 rSNVGYzjkXVEd9kOTB7fUf1WKhEdCV+gy242Grs= X-Google-Smtp-Source: APiQypJrT8QJCQxm6xA8nd8vjyXP3yTKnwK0AqiozYrG64FmPk4heaQ0HTTGWtYT1t/6s+RBIYg4ik4aktUldSObC5U= X-Received: by 2002:ac2:50ce:: with SMTP id h14mr134527lfm.76.1588274794224; Thu, 30 Apr 2020 12:26:34 -0700 (PDT) In-Reply-To: <98ab19cf-680b-9cd2-7c42-89dd0b2f470a@yandex.ru> Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=philippe.vaucher@gmail.com; helo=mail-lf1-x12b.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::12b 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:248270 Archived-At: --000000000000ea61ff05a4870ad7 Content-Type: text/plain; charset="UTF-8" > I haven't used dash/s/f much, but from what I see they do try to bring a > more "flat" style of APIs, following the style of Clojure. There are a > lot of utility functions in there too (like extra abstractions on top of > the basics that the authors found to be useful). So when you ask the > core library to be more like f.el, you'll have to specify what exactly > you'd like to see changed: rename existing functions dealing with files > to start with file-* or to add new ones. Then we can work out some sort > of policy to adopt (or not) such changes. > I think the crux of the issue regarding existing Emacs lisp would be "should all file related apis start with file- ?" If we decide the answer is yes (as advised by the coding conventions) we could start by simply aliasing the existing API that does not follow this convention. That'd mean `copy-alist` would be aliased as `alist-copy`, do you think people would be strongly against this? > Also, quite a bit of functions seem to be named with the purpose of > keeping the names short, perhaps too short, like the author came over > from Clojure, found out that you can't simply > > (require '[string-utils :as s]) > Yes, I think "string-" is better than "s-", but I understand the author didn't want to clash with the existing "string-" functions so he picked "s-". In this case I think a simple proposal would be to list all the "s-" functions that don't have a corresponding "string-" function (s-truncate, s-left, s-right, etc) and propose them for inclusion but named under the "string-" namespace. Regards, Philippe --000000000000ea61ff05a4870ad7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
I haven't used dash= /s/f much, but from what I see they do try to bring a
more "flat" style of APIs, following the style of Clojure. There = are a
lot of utility functions in there too (like extra abstractions on top of the basics that the authors found to be useful). So when you ask the
core library to be more like f.el, you'll have to specify what exactly =
you'd like to see changed: rename existing functions dealing with files=
to start with file-* or to add new ones. Then we can work out some sort of policy to adopt (or not) such changes.

I think the crux of the issue regarding=C2=A0existing Emacs lisp would b= e "should all file related apis start with file- ?"
If we decide the answer is yes (as advised by the coding conven= tions) we could start by simply aliasing the existing API that does not fol= low this convention. That'd mean `copy-alist` would be aliased as `alis= t-copy`, do you think people would be strongly against this?
=C2= =A0
Also, quite a bi= t of functions seem to be named with the purpose of
keeping the names short, perhaps too short, like the author came over
from Clojure, found out that you can't simply

=C2=A0 =C2=A0(require '[string-utils :as s])

<= /div>
Yes, I think "string-" is better than "s-", b= ut I understand the author didn't want to clash with the existing "= ;string-" functions so he picked "s-".

<= div>In this case I think a simple proposal would be to list all the "s= -" functions that don't have a corresponding "string-" f= unction (s-truncate, s-left, s-right, etc) and propose them for inclusion b= ut named under the "string-" namespace.=C2=A0=C2=A0
Regards,
Philippe
--000000000000ea61ff05a4870ad7--