From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Proper namespaces in Elisp Date: Mon, 4 May 2020 23:34:06 +0100 Message-ID: References: <237fe643-c14d-5406-b35d-a30dcd42c5ed@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="129868"; mail-complaints-to="usenet@ciao.gmane.io" Cc: nic@ferrier.me.uk, =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel , Stefan Monnier , Helmut Eller To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 00:35:16 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 1jVjgB-000Xff-IM for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 00:35:15 +0200 Original-Received: from localhost ([::1]:35008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVjgA-000763-Fe for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 18:35:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVjfO-0006gW-7D for emacs-devel@gnu.org; Mon, 04 May 2020 18:34:26 -0400 Original-Received: from mail-io1-xd41.google.com ([2607:f8b0:4864:20::d41]:40630) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVjfK-0006n0-7i for emacs-devel@gnu.org; Mon, 04 May 2020 18:34:25 -0400 Original-Received: by mail-io1-xd41.google.com with SMTP id c2so14149489iow.7 for ; Mon, 04 May 2020 15:34:19 -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:content-transfer-encoding; bh=AowJ+PEerSZCWSWSIXH1lLormRUdNXgPaRrXIce+w0M=; b=PL4cr0oTJfWL/JJOBtPVbRVYRR6gufRJt3Lk8fVye89/e7VPmy5oWJF0Z/Bn5UEXBL A/w/odDPuEmWPNKfqsmXq/p4T7Dg5K9HaJDtJx9TUywB3WqxR5hPZhTypWxshL5Yyfnu uYE8yviZ0LkNxljHQBzFl3pwpD+0rNlzyMhj0hagkFLwQLtjG83mEYvTGcrLO2yhXJqw dVCqq7AMrLhRBhPPpT++a/1tkGDjDf0bzOGcxwBL+NlPqCWTN0O2nFlpAxAxM/R1Q47t +eZGiMEjGIhzSdG7b67p5V4PCyPuu/F4E0YGNJfBxyozdbKJg6+UJTuSSf09Q/o/4RRn cx3w== 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:content-transfer-encoding; bh=AowJ+PEerSZCWSWSIXH1lLormRUdNXgPaRrXIce+w0M=; b=QIYqHyh+9PuCsaFCEe8M86IbsPnuHWN8XpN0mPH/dRNWBxP3aUxm2JZJ7mrhzImzHO EdKZQbPRjXRlaKlylMrrUDztXh2w8TAfRPeAMians05pIJ8BbeuVkUr1YZ2prCYASUZT hZ17F5fSxKIRIkGG4N8/drFKc0pjs6g8Y5e3x70ICDaaiMs+hmKl71MFkkD0hYcPYCYX 5DEzZPxtj66wUhrdVVpqnOFfc74NNq3Msx0aEDNShmO3fHOpXCgbi4dTOF1PQon++2rZ K1ivg6ee0q9jzX38xqWKVQkBw+n0MkF4iZm6EVfTDmC2bnHNc2vvxGcRKWmu7q1pMHa6 ZVBg== X-Gm-Message-State: AGi0PuZaxwj/8fJHtBAdTu1rZioLnj1j36vjCn408RdoRdcdC04t0QjK /+oXN7u9RtwMR0xtaJQqqk2umFGRIteeVn8eOdo= X-Google-Smtp-Source: APiQypIFC5+SOWHVC1RO82gQCz02udJ5k69VrYdk2TIdlwBYjkUMGknT0eDKBm2CS58m424duO7aLmYhLKf/8I+YmTM= X-Received: by 2002:a6b:6a13:: with SMTP id x19mr517127iog.175.1588631657950; Mon, 04 May 2020 15:34:17 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::d41; envelope-from=joaotavora@gmail.com; helo=mail-io1-xd41.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: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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:248917 Archived-At: On Mon, May 4, 2020 at 10:59 PM Andrea Corallo wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > > On Mon, May 4, 2020 at 7:30 PM Helmut Eller wr= ote: > >> should be done by the compiler (like lexical scoping). In other words= , > >> those people would like a mechanism to manage the names of variable > >> bindings not a mechanism to manage symbols. > > > > That last sentence sounds clever but I can't fully grok it. Do you > > really mean "variable bindings" or just "bindings"? (including function= 's). > > > > On Mon, May 4, 2020 at 7:39 PM Stefan Monnier wrote: > >> Richard mentioned his profound dislike of solutions that operate in > >> the reader. I'm not sufficiently familiar with Common Lisp's package > >> system to have a strong opinion on that, but Richard's criticism does > >> appeal to me (I've been brought up on namespace systems more like > >> Standard ML's structures). > > > > I can't even imagine what a solution that _doesn't_ operate on the read= er > > looks like. Are you talking about form walking macros that walk the > > forms and switch the short version of names into the long versions > > and intern everything into the same obarray? Hmmm. > > Namespaces in the read time is a bad idea because it does not affect > only bindings but effectively all symbols. I, as many others, do not > like CL package system too for this reason and all its implications. Well, let's have "all its implications" then. Because you've done nothing more than describe in simplified fashion what it does, and that's not an argument to support the contention that "it is a bad idea". I think it's a great idea, but I admit I've become so accustomed to it I never have problems. I've recently started working with some CL newbies that caught on pretty fast, too. What are concrete cases where having a CL-like package system would cause bugs, confusion, time wasted, etc. Can you present a hypothetical "horror story"? Oh, but to be fair you have to present it against a system that also has namespaces, otherwise it's not fair. Actually, I can give you an argument against CL packages. Because Emacs is also missing restarts, a symbol conflict is hard to fix interactively. Most Lisps will ask the user what do to when a symbol conflict is found and a good debugger interface with proper restarts is very useful. But let's not pretend that any namespacing system is exempt from symbol conflicts. Indeed in Elisp we deal with them every day, by inventing contortionist prefixes and dealing with fun bugs at run-time. > I think Emacs has most of the infrastructure to implement this already > in the codebase but right now I've not time to work on a prototype ( I too think a dumb man's namespacing can be implemented, just to alleviate this alias-all-the-functions pressure. Did you read my shorthand idea, I think it could fly. > I'm not sure either how much this feature is really desired). Neither am I but If it's not desired, it should be, because it's hampering Elisp. Did you notice that the request that started this all, to integrate s.el in Emacs is all bug forgotten and people are thinking about giving extra names to longstanding functions? I for one think that users that like s.el should use it, I just don't want it polluting and crashing with everything else. If we had packages or dumb namespacing that could happen and no-one would get hurt. Jo=C3=A3o