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: Sat, 2 May 2020 22:30:49 +0200 Message-ID: References: <5f91c6e5-b4af-4478-b221-4ca37f0fb74c@default> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f7719605a4b02ded" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="106859"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Richard Stallman , Emacs developers To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 22:32:07 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 1jUynu-000RiA-Ph for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 22:32:06 +0200 Original-Received: from localhost ([::1]:51352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUynt-00070r-SA for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 16:32:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUynC-0005mr-Kq for emacs-devel@gnu.org; Sat, 02 May 2020 16:31:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUynC-0007Pr-1n for emacs-devel@gnu.org; Sat, 02 May 2020 16:31:22 -0400 Original-Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]:41145) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUyn8-0007Lh-NJ; Sat, 02 May 2020 16:31:18 -0400 Original-Received: by mail-lf1-x12a.google.com with SMTP id a9so1059169lfb.8; Sat, 02 May 2020 13:31:17 -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=wbCMVCspaYvwIzmQ3BS+j11WMVtiHKfpK3lFDG0K7HY=; b=daJcmU9rYh4lvFNUlJ2PrrMRh/HUzIMPP2wT6A3HCGZD9cuJLWmYu7iI9HoT0c7ju8 UvRsURuP2DPfiDAtA+D6zFWeBYQQ8Av3VA7hHXqpAC3nXDTUoGB/E1sJ72/z+uMo20JX Zj+R5rK5DPCYiKSPKkwCRju+GmhfCd8w+HQqsX+mDkdqX7oanC8x6sF3kB0NGUYltSpg 7GEnmJnt1Bkt+D3dPecD6kz5TKhzH8+K8mzm+WhyNKhAKWIDchEJsKLlbchc0rTLNwDp /MBOIoggWggvNHQ5roc6GE2eFqTe1E6CwRqOKFcXiqqt2jLeJ1Ljc7Cw/5zY5DU2PqCH x04g== 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=wbCMVCspaYvwIzmQ3BS+j11WMVtiHKfpK3lFDG0K7HY=; b=FbGiEzC6Ef0NziUvj4djcgNJG3QpmOzAplJK8hxsPIJ09RafevNSEFFiiHAgxAdh/0 JjLAGSlAU88xBfv8YQTTDSwdykOnMsjZr2DzhdL5+VG+wxpMZPF8Z42GnjrRH2yOyMd1 bAf7at+eNYVxf1KsMepiHxrbRNBDaPLJPpXOBDjX7z/7HEh9Jy3NQntGc42E2l5FLYb0 nVv6ZZGvtpdfiGo939f3dtthkLYyOoKkD9r3iFP8q+IbNPBhH/KM9tLyyO3izmXWkGsb PJ/0nw71+gYJC1X8ijiy3LXUjB+T9415tOLIK+zHakFCou5DBwRMe1Lv6+KgGjVuYi/X jV2w== X-Gm-Message-State: AGi0PuZ9xoNlwGtFNXOcjUO/kQMltyltcwkSOSSMAo+FVPrfP+LdP6EA Y7qSgQjeXrRb1/pKHvlqeBOruch/7vqCjzC8xsE= X-Google-Smtp-Source: APiQypJqGUj/dX/pCui6Zrp3WHA+eDOY6VIA3viFoGh1VLoyNl0WPvDnvNQ7ScFrJqwssceWyZLElG4RbJnBD4bwaDg= X-Received: by 2002:ac2:5482:: with SMTP id t2mr5543605lfk.202.1588451475942; Sat, 02 May 2020 13:31:15 -0700 (PDT) In-Reply-To: <5f91c6e5-b4af-4478-b221-4ca37f0fb74c@default> Received-SPF: pass client-ip=2a00:1450:4864:20::12a; envelope-from=philippe.vaucher@gmail.com; helo=mail-lf1-x12a.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::12a 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:248562 Archived-At: --000000000000f7719605a4b02ded Content-Type: text/plain; charset="UTF-8" > > In Haskell, do you name every function with a > prefix that advertises the type of its return > value or one of its main arguments? No, of course > not. How do you find functions that return or use > a value of a given type? You check signatures > or doc. > Except if I'm missing somethign Haskell also groups related functions together: https://hackage.haskell.org/package/strings-1.1/docs/Data-Strings.html > As for "alist", "ass(q|oc)", and the like: each > such choice has its drawbacks. But yes, some name > consistency can help, in general. But no, because > history. And no, because different uses/contexts. > > The discussion was motivated by considering new > users, in particular. Well then, what does a new > user look for, when it comes to alists? Does s?he > know the term "alist"? Or is the thought about > "association"? "key-value"? "pair"? "relation"? > "attribute-value"? "property-value"? > It has already been said that alist was a bad example. Consider process or regexp instead. > Consider `C-h f alist', with substring matching. > In my current session I get 156 candidates, all > of which are relevant to alists. Great. > > If I match `ass' instead, I get 235 candidates, > many of which are about alists, but many of which > are not. If I then chip away from those matches > the matches for `class' and `pass', I get only 51 > matches, of which 34 are about alists. > > If I use `C-h d alist' I find 560 functions > whose doc mentions "alist". > `C-h d association list' finds 56 functions. > `C-h d assoc' finds 52 functions. > When I see this it only confuses me. Sure those are great tools to find things in a broad sense, but there are so much noise that you have to filter. The only relevant functions I'd like to find are: assoc, rassoc, assq, alist-get, rassq, assoc-default, copy-alist, assq-delete-all, assoc-delete-all, rassq-delete-all Anything else listed there is noise IMHO, except if searching in a broad scope. > Finally, the habit of assuming that functions > should be grouped only by argument or return > type, either in terms of name or doc, is not > a guide. API doc (e.g. JavaDoc) does have its > uses. And it's especially useful, perhaps > even necessary, for certain kinds of languages > (e.g. OOP). But it's certainly not the be-all > and end-all. > Agreed. Still I think there is a lot of room for improvement, without going "all the way". Philippe --000000000000f7719605a4b02ded Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In Haskell, do you name every function with a
prefix that advertises the type of its return
value or one of its main arguments?=C2=A0 No, of course
not.=C2=A0 How do you find functions that return or use
a value of a given type?=C2=A0 You check signatures
or doc.

Except if I'm missing somet= hign=C2=A0Haskell also groups related functions together:=C2=A0https://hackage.haskell.org/package/strings-1.1/docs/Data-Str= ings.html

=C2=A0
As for "alist", "ass(q|oc)", = and the like: each
such choice has its drawbacks.=C2=A0 But yes, some name
consistency can help, in general.=C2=A0 But no, because
history.=C2=A0 And no, because different uses/contexts.

The discussion was motivated by considering new
users, in particular.=C2=A0 Well then, what does a new
user look for, when it comes to alists?=C2=A0 Does s?he
know the term "alist"?=C2=A0 Or is the thought about
"association"? "key-value"? "pair"? "rel= ation"?
"attribute-value"? "property-value"?

It has already been said that alist was a bad example. Co= nsider process or regexp instead.

=C2=A0
Consider `C-h f alist', w= ith substring matching.
In my current session I get 156 candidates, all
of which are relevant to alists.=C2=A0 Great.

If I match `ass' instead, I get 235 candidates,
many of which are about alists, but many of which
are not.=C2=A0 If I then chip away from those matches
the matches for `class' and `pass', I get only 51
matches, of which 34 are about alists.

If I use `C-h d alist' I find 560 functions
whose doc mentions "alist".
`C-h d association list' finds 56 functions.
`C-h d assoc' finds 52 functions.

W= hen I see this it only confuses me. Sure those are great tools to find thin= gs in a broad sense, but there are so much noise that you have to filter. T= he only relevant functions I'd like to find are:

as= soc, rassoc, assq, alist-get, rassq, assoc-default, copy-alist, assq-delete= -all, assoc-delete-all, rassq-delete-all
Anything else listed there is noise IMHO= , except if searching in a broad scope.
=C2=A0
Fin= ally, the habit of assuming that functions
should be grouped only by argument or return
type, either in terms of name or doc, is not
a guide.=C2=A0 API doc (e.g. JavaDoc) does have its
uses.=C2=A0 And it's especially useful, perhaps
even necessary, for certain kinds of languages
(e.g. OOP).=C2=A0 But it's certainly not the be-all
and end-all.

Agreed. Still I think ther= e is a lot of room for improvement, without going "all the way".<= /div>

Philippe
--000000000000f7719605a4b02ded--