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: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) Date: Tue, 28 Sep 2021 16:15:29 +0100 Message-ID: <87y27gd94e.fsf@gmail.com> References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <87ee99dv34.fsf@gmail.com> <07cf50ddddb5a9556aa94201a7ac88c9@webmail.orcon.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26729"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 28 17:17:20 2021 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 1mVEr9-0006jO-Vy for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 17:17:20 +0200 Original-Received: from localhost ([::1]:38734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVEr8-0006sL-Uy for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 11:17:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVEpT-0005JF-J8 for emacs-devel@gnu.org; Tue, 28 Sep 2021 11:15:37 -0400 Original-Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:34364) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mVEpQ-000610-Hh for emacs-devel@gnu.org; Tue, 28 Sep 2021 11:15:35 -0400 Original-Received: by mail-wr1-x432.google.com with SMTP id t8so58799143wri.1 for ; Tue, 28 Sep 2021 08:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=x/TBsHcYkIr0+eniXUBEgGEv85y7Kiw9P8vTI72E2/4=; b=cymrja2Px/WGdyFBA2iCbeBup3DRLrN73NJn3qygn8ioQp/Zsiv8u8rRtwZgJSUA6C 7LpbE83lmrA86fvDjFnMA4TghG7obHSyq5zQumt720o6YW6w3WI1QjsBM1/5XGQHbzkd XMeYklc6uzTe5sUyFZ0GEqF8LijUDeK9IeOwxc1jCFC8JononUsBrS2qdcXD1EveKsI+ V/secHcw5/Dh4RxCyXtf0AunY40cTzNsuhV+nMUI0Htn8ECLQ3Hx2AUXD97mCQ3GlBFo 5ogPENSouZk6yUfOH5oEyRx7Jd8Cq/yrQGKbgwYDgwh4saDFk/NIH91RrN0pikP59ywu LtBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=x/TBsHcYkIr0+eniXUBEgGEv85y7Kiw9P8vTI72E2/4=; b=Dpiru0iDqgzM+E7so6oDMCJR5lb/NevLRpvdNdQuOVlkHnyESV+8yb/X+U8+y9c34y qrqqByVKptB9+Va7lD7r8gpxa0e0EedFlEPkwb/88y5CbT/vAaEV9ZD8Bp09v7vI+Ock xIxqtmA1fTiK+sot0Gilaevczhry0hIQGHsRbMqY061TL31/5wLkXRRhc4oy8v1OtDGH 9WDnS1tj1E8GHLhlqTIVTNwoGZ6o5ah47smjyeWxVs3FOQrio15uQOxYcSTXZ3ShWlof LDnbAXkWl+/oQfxdE5LsRzF4pAPA3kWsUyCdBRUIJm5B6MpkX1LqmHN9IW3orjCdNFIv 61bQ== X-Gm-Message-State: AOAM530VzO0y9PFm5a1ow1MXexi4LOxBf2GmYiUw0yk5YEfDkb9P3PYO jdVFXzlIXpuWBHAT7YkZ8EQn+B5vtFo= X-Google-Smtp-Source: ABdhPJzTgx44saSgx1RUa5jHA1bVVZ5c05a04NY0dcPL2WekmXQtO8Ig7RxcyaPSPyepUt+xC6AYlQ== X-Received: by 2002:adf:d0cc:: with SMTP id z12mr746504wrh.72.1632842130158; Tue, 28 Sep 2021 08:15:30 -0700 (PDT) Original-Received: from krug (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id w1sm3051216wmc.19.2021.09.28.08.15.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Sep 2021 08:15:29 -0700 (PDT) In-Reply-To: <07cf50ddddb5a9556aa94201a7ac88c9@webmail.orcon.net.nz> (Phil Sainty's message of "Wed, 29 Sep 2021 01:49:59 +1300") Received-SPF: pass client-ip=2a00:1450:4864:20::432; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x432.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, 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.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:275698 Archived-At: Phil Sainty writes: > On 2021-09-28 20:21, Jo=C3=A3o T=C3=A1vora wrote: >> So it sounds like you're arguing against namespaces in general, > > Yes, I would vote against adding this to elisp. > > >> and you're right, they have disadvantages, in any language. >> But the advantages are immense. > > Are they? I don't see how they add anything at all of genuine worth. > > (FWIW I'm sorry that this sounds harsh, as I'm certain that a lot of > effort has gone into this. I just have really strong misgivings about > the feature.) No problem. We can be harsh and polite to each other. And, surprisingly, "not much effort" went into this :-) if you see the source code, you'll see that is fairly terse. Certainly much less than other features I've added to Emacs. A good thing. > I agree that they make code a little nicer to write for the author > who knows what everything is. I think this is an *extremely* minor > benefit which everyone can easily manage without (as they have done > for decades); and AFAICS it is the only benefit, and so I don't see > how it is worth all of the trouble that comes with it. > > I firmly disagree with the notion that it makes code easier to read > for other people. Other people actually now have to mentally account > for the fact that every symbol they see might not actually exist by > that name. I know you don't like these analogies, but when you are with your family, do you qualify everybody by their full names? You don't right. It's tedious to you, as a speaker, and I suppoe it's tedious to your counterparts as a listener. Humans use shorthands for lots and lots of things. Hence the common phrase "context is everything". My position is that human languages are no different from artificial ones in their interaction with humans (reading and writing). For interactions between programs (compilers, etc) I fully agree with Stefan Monnier that they don't care, and neither should we. (or should we? Have you ever needed to debug a C++ program without a name unmangler?) > The manual even talked about the ability for different people to use > different shorthands for the same library, so a symbol might actually > have *many* names in the codebase. This makes things harder. Namespace systems in all languagues I know are about the ability to refer to the same thing by different names in different contexts. I guess I have to refer you to some recent decade's worth of language design. > Allowing things to not be what they seem adds an additional cognitive > load to *everything* you look at, I don't deny that. There is an additional cognitive load. My point is that that load is comparatively smaller, MUCH smaller, than the load incurred by reading repetitive code. Don't forget that typing this-long-symbol-prefix is a way of code duplication, however primitive. And this duplication is bad, not for storage reasons, but because it slows down the human parser tremedously. > It makes it harder for users to share code because, even if you know > which libraries are used, copied and pasted code can now be completely > broken without knowledge of the magic file-local variable. That's true, yes. You can't share code without context. But listen, that already happen in a myriad of situations. I can't paste a snippet that refers to a global variable or funtion and expect it to work UNLESS I give you that context. No really, the problem you bring about is not new. > From what I've seen it doesn't seem that the shorthand symbols even > exist (they are translated at read time), so if someone reads some > shorthand code and tries to look up the symbols they see, will they > find them? No. In Lisp there is the form and there the symbol. These are not interchangeable. A symbol is an object, which is much more than just its print name. A form is a written down version of the symbol. Shorthands are just the forms.=20 > If they C-h v and use TAB completion for the prefix they are seeing in > the code, will they see all the completions? No. The shorthands are local context. So if they type C-M-i they will see it, but with C-h v you see the full name of the symbol. Which is always valid, of course. > If so, will that work in all buffers, in all locations? No. You may be known under different nicknames in your family, your Yatch clubetc. Mixing up your nicknames in those different contexts would be disastrous. > If they get to the help buffer and they try another look-up, will it > then fail? You lost m at this point. > Or if they simply have split windows and are reading code from the > other window? What if different libraries specify the same shorthand > for different dependencies? Can people only look up certain symbols > from certain places? Again, it seems you are against the idea of namespaces in general in any language. But indirections is what hight-level programming is about. You don't have to use all of them, and neither should you, but I firmly believe you should have access to them. Namespaces, generic functions, advice, hooks, macros, functions. All these things to "hidden" things that you have to chase down. If you don't want any of it, you have to be ultra-literal. You have to use machine code, not even assembly. >> To organize complex problems utilizing many libraries, I cannot >> imagine a decent language that does not have them. > > How do namespaces help with that? By allowing you to compose programs from many different libraries in a way that you don't write a mammoth prefix all the time. You can choose what prefix you assign to each library's symbols. "fn" for the bunch of "file-name" stuff you're going to do. "s" for the bunch of "magnars-string" stuff you're going to do. "phil" for the bunch of "phils-incredible-library-of-utils.el" stuff you're going to do. That is how. > Furthermore Emacs Lisp is not other languages, and Emacs is unusual. Yes, Emacs is unsual. Especially in the developers ahahah (me included, of course). But Emacs Lisp is not much different than other languages. It's a Lisp-2 with many features of Common Lisp. Probably has more much devs than Common Lisp, and a younger generation at that. Probably has more future, I'd say. Needs a better GC. > It combines a very large amount of global state (which most programs > do not do) Obviously that depends on the programs you write and how you write them. > with dynamic binding (which most languages do not have). And which shouldn't be abused, BTW (and here you go dynamic binding! Another super-useful feature with lots of tricky hidden behaviour. Oh the cognitive load!) > Surely "other languages have this" isn't a reason to add something to > elisp unless there is a clear net win to doing so, and all I'm seeing > are net losses. What are the advantages that I'm not seeing which are > so immense that they make all the problems worthwhile? I've described them. Again I refer you to all major languages that have namespacing systems. Or to the fair number of people that have expressed want of a namespacing system in Emacs. It's like you're asking me to describe to your why global variables are useful. Some people avoid them like the plague, they hide behaviour. You need context. There's cognitive load to understand a problem with global variables. But just like shorthands, they're opt-in. You don't _have_ to use them in your programs. You can object to them in other peoples programs, same thing. > programming language; and I couldn't figure out what the "expressive > power" of shorthands might be. That is quite clear to see :-) Jo=C3=A3o