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: Imports / inclusion of s.el into Emacs Date: Mon, 4 May 2020 09:08:31 +0200 Message-ID: References: <83368ivmym.fsf@gnu.org> <5f91c6e5-b4af-4478-b221-4ca37f0fb74c@default> <2afdde98-4d71-4847-8ee4-b0eee677baef@default> <8d649ffd-c60e-4cb5-ae21-413cc39ae409@default> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006407e405a4cd3417" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="130293"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , Richard Stallman , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 04 09:09:35 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 1jVVEM-000XoW-Vp for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 09:09:35 +0200 Original-Received: from localhost ([::1]:58304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVVEL-0000c8-V1 for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 03:09:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVVDp-0008W8-JW for emacs-devel@gnu.org; Mon, 04 May 2020 03:09:01 -0400 Original-Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:46968) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVVDo-0008Fb-Nd; Mon, 04 May 2020 03:09:01 -0400 Original-Received: by mail-lf1-x12f.google.com with SMTP id g10so8741420lfj.13; Mon, 04 May 2020 00:08:59 -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=RCk5tzsN6wIe8Jy55EKyZgJ5XbTwIcHztqSojQb7nkw=; b=QYsejaZLXyq+JP0we37t+oVJ+hNmNAV+XHzd8jv31KNiR9knZfjGWXkxIuCL6mn74e VSDAbFli+t+RRuaS0JaLvPONi+Qha95KbBAR3JozS+Md+8A0jevFyYoUr0HpO4AolKVA CkA8UJpIrzIHnUUfHEQLqFA4mWbgXz4WIkN5eHx4BE2b4oxYDQap5CW/kE1WPdgHX0qC MNVehPKTNPJqK8zStnI4TLxctGMo0UQfSBk2XlqySDosb0anBaPcqtmA7/zg+IbQRXvr Lg5DO13MKr5Z7FO+0OnRfSZdIsFBY8EOhQjmml1lGm76krEUGbISR3OokDcvPhsb6zch IyMg== 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=RCk5tzsN6wIe8Jy55EKyZgJ5XbTwIcHztqSojQb7nkw=; b=Q5Rkr90Q5f5ioHg0WnP+tVghgfwQXeHtpQcPakj6T6UZoX0agerTwjh4QugTn2kqZn sBA2F1Amk2k5Vo1AKelJFILuy/Tw4hWIUqtsp5+RT3+stXNCWmA8X1SwepM3WXbNlbme aUDJg6tfbJ5BSI+ri0uD9QCHBzVyZTLokln5d35O4Ic6cWHOrJ7t1OLfEMG1Yu6dRZcS phSDHbryg20ppxbFe4AMPRwsEqeQZ0EP5oF3cGBCuRgzNZkhmM7cfrFRaWxsCMcyUaFN y/h19zrdpjnmKi7B2Yi8l0zRrT0apeJBjODrRKQlkzpNc7WPlXkJGmnZIb8waci2u5Nj f5bg== X-Gm-Message-State: AGi0PubegOH0JJmK7uB6pxEV9em397vDYaKsOsDlIeHiLvMrKUqVKvHj 9Oiph8QO7rkM5xxyqz7U9g7DYc2Upjd52Ryp32yWrgkc X-Google-Smtp-Source: APiQypK8aXYu46MMohGzJA7W2k3eANG+PNq7glG4X58a6jMwycdZXtU+yuGxh/z4HX6l9HZiHV3fDB8dwxNpqAQtd6c= X-Received: by 2002:a19:f719:: with SMTP id z25mr3115982lfe.76.1588576137772; Mon, 04 May 2020 00:08:57 -0700 (PDT) In-Reply-To: <8d649ffd-c60e-4cb5-ae21-413cc39ae409@default> Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=philippe.vaucher@gmail.com; helo=mail-lf1-x12f.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: -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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:248790 Archived-At: --0000000000006407e405a4cd3417 Content-Type: text/plain; charset="UTF-8" > > notice how in Haskell there is a strong will to > > group things together. That's what you'd take out > > of the example. > > Of course. In Haskell and in life generally. Things > that are alike generally belong together. > > But this discussion is about _naming_ functions, vars, > etc., not just grouping them. In Elisp, grouping them > in a library already gives them a library prefix. And > in general that has nothing to do with the type of > objects they use or return. No, to me this discussion is about _grouping_ things, that's why we push for library prefixes. > It can make sense to adopt a prefix convention for > functions that define a type of thing (e.g. buffer, > window, vector, string) than it does to impose it > willy-nilly way on functions that might just return > such a thing or accept it as one of their args. Just to be clear, "type-grouping" you more or less see the point but "topic-grouping" (e.g regexp, string) not so much? > Most functions do not fit that bill of defining a > thing type. And many (most?) do not fit the bill > of acting only/mainly on one particular type of > thing or having as their main purpose to return > such a thing. > > That was really the point. Perhaps there are some > cases in Elisp where it would make sense to prefix > more functions that involve a particular kind of > thing. I've acknowledged that. And others have > said the same thing, citing strings as a type that > might be looked at more in this regard. Okay, but I think we already agree on this? I propose to alias/rename functions where it's "obvious", but as we saw that what is obvious for me is not obvious for everyone, so that's complicated. I think we reached a point where everything proposed was rejected so this is a dead end. > The corner cases for me are the relatively few > functions whose names cry out for labeling as > specific to some type, and I'd propose fixing > their names, case by case. The ones I proposed were all rejected :-/ Do you have one in mind? --0000000000006407e405a4cd3417 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > notice how in Haskell there is a strong will to<= br>> > group things together. That's what you'd take out
&= gt; > of the example.
>
> Of course.=C2=A0 In Haskell and in= life generally.=C2=A0 Things
> that are alike generally belong toget= her.
>
> But this discussion is about _naming_ functions, vars,=
> etc., not just grouping them.=C2=A0 In Elisp, grouping them
>= ; in a library already gives them a library prefix.=C2=A0 And
> in ge= neral that has nothing to do with the type of
> objects they use or r= eturn.

No, to me this discussion is about _grouping_ things, that= 9;s why we push for library prefixes.

> It can make sense to adop= t a prefix convention for
> functions that define a type of thing (e.= g. buffer,
> window, vector, string) than it does to impose it
>= ; willy-nilly way on functions that might just return
> such a thing = or accept it as one of their args.

Just to be clear, "type-grou= ping" you more or less see the point but "topic-grouping" (e= .g regexp, string) not so much?

> Most functions do not fit that = bill of defining a
> thing type.=C2=A0 And many (most?) do not fit th= e bill
> of acting only/mainly on one particular type of
> thin= g or having as their main purpose to return
> such a thing.
>> That was really the point.=C2=A0 Perhaps there are some
> case= s in Elisp where it would make sense to prefix
> more functions that = involve a particular kind of
> thing.=C2=A0 I've acknowledged tha= t.=C2=A0 And others have
> said the same thing, citing strings as a t= ype that
> might be looked at more in this regard.

Okay, but I= think we already agree on this? I propose to alias/rename functions where = it's "obvious", but as we saw that what is obvious for me is = not obvious for everyone, so that's complicated. I think we reached a p= oint where everything proposed was rejected so this is a dead end.

= > The corner cases for me are the relatively few
> functions whose= names cry out for labeling as
> specific to some type, and I'd p= ropose fixing
> their names, case by case.

T= he ones I proposed were all rejected :-/ Do you have one in mind?
--0000000000006407e405a4cd3417--