From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: A short defense of shorthands.el (but CL packages are still better) (Was: Help sought understanding shorthands wrt modules/packages) Date: Thu, 3 Nov 2022 20:04:18 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009ae65705ec967266" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12021"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: =?UTF-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 03 21:04:05 2022 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 1oqgRZ-0002vo-DU for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Nov 2022 21:04:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqgQr-0003PS-P2; Thu, 03 Nov 2022 16:03:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqgQp-0003NG-Kx for emacs-devel@gnu.org; Thu, 03 Nov 2022 16:03:19 -0400 Original-Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oqgQn-00029i-Dy for emacs-devel@gnu.org; Thu, 03 Nov 2022 16:03:19 -0400 Original-Received: by mail-oi1-x233.google.com with SMTP id m204so3171427oib.6 for ; Thu, 03 Nov 2022 13:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=muPRY3HBevPuCyutm04Vu0sOyRighSxb4chRXRz8oI8=; b=Yl16UAveN8g9/XX9GzjiExGEx7msW/uihs+isMuj8pfDqlzmoNbOGOFFjoUYevpciX b3LYS3acr1W0WgfcwT7MkD5g7SfX9HoInUYP68XOQjNiv/eDO1IdPksE0gZk7w7+gQ7x HTA9/uCJDV86gsHrN6OYvYR3qknTOur5rdfq5FOLn+1xQcr8tQZp7esJJ1PpVXuIiHxt sT/ZTXjcaXqQhax1ALwZ3TsTumm0VyjpIZdox5Zm1gXRNWnnRPbh9hq2Pa6k0IfSkfSO 5Nn8QE+EpF/p/7pmVvTwH3N0miAOt8PDOEmE8Sl8MJ8jATxkDh7Mo6zi6YyNbSUlXu+w aE5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=muPRY3HBevPuCyutm04Vu0sOyRighSxb4chRXRz8oI8=; b=shlw8zDJcdeOIC6MGVaPZdJrWhtuke2Pc2ih6Kq0pCyoU6kUz4qGPGEBwm+M5HUFpG svXGH+KyvoI3ppD0Hrfpp8IdYSoI7lz2wQW+dQH6MRXQLoEmUbYSaz4of99xv9k+c0t7 ksoFg3HaP4hWcJPbhlO7+YTGTx9Bk2nnQeGQkVol1nRe4CiGYHJppc6+ZqV5kY78R2c0 Z7CgYmHUTOK+vuxl/cUvSUU3hhNCyn52uXC5TDZktB5t5KAKNWI/JlvE1MBEq4eu2wGk J8Tf/jjaz0YF5hGi7XajDzjoWcQrR8pV3qXY00jlllq1N43PRchf2jAIlLIlviBtKV4+ /iKQ== X-Gm-Message-State: ACrzQf1KseB8reaWZAaJIcg4yVsgrt4dmY2gm8r1/JQc7iZ2ZTIh7pPf t5z3FMMLafNx1wTi6fA9ntpWKA1JMdUJ9bRmINQ= X-Google-Smtp-Source: AMsMyM7K3hCPGOnw39Hox6VdcjDcB0iwvwIqvGKmo5GtWNLGCrjiiP4UU9dH2q8HzrQeHQZEes7Q/9pqbNKfCMDepBA= X-Received: by 2002:a05:6808:144b:b0:35a:41f9:445f with SMTP id x11-20020a056808144b00b0035a41f9445fmr4863855oiv.171.1667505795555; Thu, 03 Nov 2022 13:03:15 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::233; envelope-from=joaotavora@gmail.com; helo=mail-oi1-x233.google.com 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_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299100 Archived-At: --0000000000009ae65705ec967266 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 3, 2022 at 5:12 AM Gerd M=C3=B6llmann wrote: Jo=C3=A3o T=C3=A1vora writes: > Hi Gerd, I'm there one who implemented shorthands in Emacs, and i sur= e > don't think they are a substitute for CL packages. Thanks for letting me know, Joao. No problem. Allow me to mount a short defense of shorthands. In doing so, I don't mean to imply -- by any measure -- that CL packages are a much welcomed addition to Emacs. They are, absolutely. * shorthands are designed to perform namespacing operations with minimal or even no changes to the Lisp forms of an Elisp file. The hypothetical file x.el: (defvar x--bar 42) (defun x-foo () x--bar) (provide 'x) ;; x.el ends here ;; Local Variables: ;; read-symbol-shorthands: (("x-" . "xenomorph-")) ;; End: which will pollute the global namespace when loaded into Emacs 27, will, when loaded into Emacs >28, intern xenomorph--bar and xenomorph-foo instead of x--bar and x-foo. Its user file yummy.el (require 'x) (defun yummy () (x-foo)) ;; yummy.el ends here ;; Local Variables: ;; read-symbol-shorthands: (("x-" . "xenomorph-")) ;; End: can also be loaded into Emacs 27 and Emacs 28. The interaction between the two packages works in both cases, but in Emacs 28 the global namespace won't be polluted. * The above use case was motivated by the s.el, dash.el and f.el libraries which incur in this namespace pollution. To be clear, all packages pollute the namespace but these short prefixed ones were especially heavy polluters, since short names naturally appear more frequently in completion lists. * If CL packages had been used instead, this "double duty" wouldn't have been possible, because x.el and y.el would have to be changed considerably (admittedly in a rather straightforward fashion) * When shorthands were presented, much criticism was leveled at it, some stemming from a misunderstanding of the specific problem this attempts to solve. * But one of the criticisms is pretty reasonable: this "breaks grep" because the same symbol can now be referenced by two different character strings from two different contexts. Also two different symbols are designated by the same character string, again in two different contexts. However, the same is true for every namespacing facility by definition. This is what namespacing systems do. * Anyway, the problem is that grep xenomorph-foo x.el yummy.el doesn't return anything, even though xenomorph-foo is really the name of the symbol in obarray. Obviously, grep doesn't understand ELisp. * In my opinion, the part that is missing from shorthands is a tool that replaces grep (for Lisp symbolic uses, of course) and understands and can be used as a backend for xref-find-references. One can think of different approaches for realizing this tool * The most promising approach, IMO, to fix this is to create a new binary program, call it 'sexgrep' (for "Symbolic Expression Grep") which can be run separately from Emacs but which uses Emacs's reader syntax. It could reuse lread.c maybe, or reimplement relevant parts of it. The program's input is a full symbol name and a number of Elisp files. By using a source-tracking reader and understanding the relatively simple syntax of shorthand definitions, it'll make sexpgrep xenomorph-foo yummy.el x.el find matches for the search pattern in those two files (on line 2) respectively. * Taking the approach with CL packages would be more difficult, because the program would need to have a Lisp evaluator that understands CL:DEFPACKAGE and CL:IN-PACKAGE, not just a reader. This is why, in the Common Lisp implementations that I've used, a global in-memory database of symbols is used instead. The database is kept up-to-date whenever the code is read and loaded (which may occur in two different moments in time, if compiled files are used). This also works nicely (SLIME and SLY use it to great effect). But it fails to search code that isn't loaded and is subject to some annoying but resolvable problems (like when loading CL fasls that were compiled on a different machine, for example. Maybe Helmut Eller, SLIME author, has some good input in this regard) --0000000000009ae65705ec967266 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 3, 2022 at 5:12 AM Gerd M=C3=B6llmann <gerd.moellmann@gmail.com> wr= ote:

=C2=A0 =C2=A0 Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> writes:

=C2=A0 =C2=A0 = > Hi Gerd, I'm there one who implemented shorthands in Emacs, and i = sure
=C2=A0 =C2=A0 > don't think they are a substitute for CL pac= kages.

=C2=A0 =C2=A0 Thanks for letting me know, Joao.

No pro= blem.=C2=A0 Allow me to mount a short defense of shorthands.=C2=A0 In doing=
so, I don't mean to imply -- by any measure -- that CL packages are= a
much welcomed addition to Emacs. They are, absolutely.

* short= hands are designed to perform namespacing operations with minimal
=C2=A0= or even no changes to the Lisp forms of an Elisp file.=C2=A0 The
=C2=A0= hypothetical file x.el:

=C2=A0 (defvar x--bar 42)
=C2=A0 (defun = x-foo () x--bar)
=C2=A0 (provide 'x)
=C2=A0 ;; x.el ends here
= =C2=A0 ;; Local Variables:
=C2=A0 ;; read-symbol-shorthands: (("x-&= quot; . "xenomorph-"))
=C2=A0 ;; End:

=C2=A0 which will= pollute the global namespace when loaded into Emacs 27,
=C2=A0 will, wh= en loaded into Emacs >28, intern xenomorph--bar and
=C2=A0 xenomorph-= foo instead of x--bar and x-foo.

=C2=A0 Its user file yummy.el
= =C2=A0
=C2=A0 (require 'x)
=C2=A0 (defun yummy () (x-foo))
=C2= =A0 ;; yummy.el ends here
=C2=A0 ;; Local Variables:
=C2=A0 ;; read-s= ymbol-shorthands: (("x-" . "xenomorph-"))
=C2=A0 ;; = End:

=C2=A0 can also be loaded into Emacs 27 and Emacs 28.=C2=A0 The= interaction
=C2=A0 between the two packages works in both cases, but in= Emacs 28 the
=C2=A0 global namespace won't be polluted.

* Th= e above use case was motivated by the s.el, dash.el and f.el
=C2=A0 libr= aries which incur in this namespace pollution.=C2=A0 To be clear, all
= =C2=A0 packages pollute the namespace but these short prefixed ones were=C2=A0 especially heavy polluters, since short names naturally appear more=
=C2=A0 frequently in completion lists.

* If CL packages had been= used instead, this "double duty" wouldn't have
=C2=A0 bee= n possible, because x.el and y.el would have to be changed
=C2=A0 consid= erably (admittedly in a rather straightforward fashion)

* When short= hands were presented, much criticism was leveled at it, some
=C2=A0 stem= ming from a misunderstanding of the specific problem this attempts
=C2= =A0 to solve.

* But one of the criticisms is pretty reasonable: this= "breaks grep"
=C2=A0 because the same symbol can now be refer= enced by two different
=C2=A0 character strings from two different conte= xts.=C2=A0 Also two different
=C2=A0 symbols are designated by the same = character string, again in two
=C2=A0 different contexts.

=C2=A0 = However, the same is true for every namespacing facility by
=C2=A0 defin= ition.=C2=A0 This is what namespacing systems do.

=C2=A0* Anyway, th= e problem is that

=C2=A0 =C2=A0 grep xenomorph-foo x.el yummy.el
=
=C2=A0 =C2=A0doesn't return anything, even though xenomorph-foo is = really
=C2=A0 =C2=A0the name of the symbol in obarray.=C2=A0 Obviously, = grep doesn't
=C2=A0 =C2=A0understand ELisp.

* In my opinion, = the part that is missing from shorthands is a tool that
=C2=A0 replaces = grep (for Lisp symbolic uses, of course) and understands and
=C2=A0 can = be used as a backend for xref-find-references.=C2=A0 One can think
=C2= =A0 of different approaches for realizing this tool

* The most promi= sing approach, IMO, to fix this is to create a new
=C2=A0 binary program= , call it 'sexgrep' (for "Symbolic Expression Grep")
= =C2=A0 which can be run separately from Emacs but which uses Emacs's re= ader
=C2=A0 syntax.=C2=A0 It could reuse lread.c maybe, or reimplement r= elevant parts
=C2=A0 of it.=C2=A0 The program's input is a full symb= ol name and a number of
=C2=A0 Elisp files.=C2=A0 By using a source-trac= king reader and understanding the
=C2=A0 relatively simple syntax of sho= rthand definitions, it'll make

=C2=A0 =C2=A0 sexpgrep xenomorph-= foo yummy.el x.el

=C2=A0 find matches for the search pattern in thos= e two files (on line 2)
=C2=A0 respectively.

* Taking the approac= h with CL packages would be more difficult, because
=C2=A0 the program w= ould need to have a Lisp evaluator that understands
=C2=A0 CL:DEFPACKAGE= and CL:IN-PACKAGE, not just a reader.=C2=A0 This is why, in
=C2=A0 the = Common Lisp implementations that I've used, a global in-memory
=C2= =A0 database of symbols is used instead.=C2=A0 The database is kept up-to-d= ate
=C2=A0 whenever the code is read and loaded (which may occur in two = different
=C2=A0 moments in time, if compiled files are used).

= =C2=A0 This also works nicely (SLIME and SLY use it to great effect).=C2=A0= But it
=C2=A0 fails to search code that isn't loaded and is subject= to some annoying
=C2=A0 but resolvable problems (like when loading CL f= asls that were compiled
=C2=A0 on a different machine, for example.=C2= =A0 Maybe Helmut Eller, SLIME
=C2=A0 author, has some good input in this= regard)
--0000000000009ae65705ec967266--