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: Wed, 6 May 2020 20:38:14 +0100 Message-ID: References: <237fe643-c14d-5406-b35d-a30dcd42c5ed@gmail.com> <87v9lb1irk.fsf@t510.orion.oneofus.la> <87sggf193f.fsf@t510.orion.oneofus.la> <87k11q1ghn.fsf@t510.orion.oneofus.la> <87k11pzqw7.fsf@t510.orion.oneofus.la> 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="17284"; mail-complaints-to="usenet@ciao.gmane.io" Cc: nic@ferrier.me.uk, =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel To: Vladimir Sedach Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 06 21:39:38 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 1jWPtI-0004NJ-UD for ged-emacs-devel@m.gmane-mx.org; Wed, 06 May 2020 21:39:37 +0200 Original-Received: from localhost ([::1]:46242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWPtH-0000PB-Sc for ged-emacs-devel@m.gmane-mx.org; Wed, 06 May 2020 15:39:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47670) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWPsC-0007dC-R0 for emacs-devel@gnu.org; Wed, 06 May 2020 15:38:28 -0400 Original-Received: from mail-il1-x142.google.com ([2607:f8b0:4864:20::142]:40176) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jWPsB-0004Ub-Mp for emacs-devel@gnu.org; Wed, 06 May 2020 15:38:28 -0400 Original-Received: by mail-il1-x142.google.com with SMTP id e8so1164621ilm.7 for ; Wed, 06 May 2020 12:38:27 -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=aZorq0ObtA5FD5KdUibJfpsRpVvOKMfYfXFq3W/tmas=; b=l0YTtsc2PScU0B51iXiRZaldMzqyb58220eV2k7NPF9BvYNOp9WgBzOGUAL7S8CMqf vNnHM6VcEYS86sF1P9tNxBHwHABh2KoksqxDxvMne6Iq0XosnRZ5Ay2mTx6RzVk+07s0 AgQjrUtKnksXi5jXPz2AdzIU0uDurIfIj76l7Nqhhqv0no+MLRWJIJyrIFaqC7vMNN2J lcx6nbUa2Np4+SKrMRRZoQ0cXuUbU+cJsKzj25fxkaH2qjXem15/4ZXlTyUVmuiFjzwk A+ZKi1a79sjSEZrKnW5CeaY1kRagLAbx+YsvN++IBjKjIqh0ziCBT24oFhNnt+yXzgGa dNzA== 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=aZorq0ObtA5FD5KdUibJfpsRpVvOKMfYfXFq3W/tmas=; b=AP0XZ4lD4aOXUkD/0jvVe6iz/U6sBM/9exI9JTuY4iDOAUzPmF2sxs2P8PQNupbSKS ixRRZvTNmjKvNnyftIXTQ5vGivMXxsZ3OmeRXylxqkduwzJeTg38Nsi3pqdsDVVX+lPT Nd5SPVr48Cky2vnu4iJ5A638gMo5MnY5vyPSzYm4LhKlrZzmaPT8qIWV6i4szRirI6cY CXJX7eb7KPUFq8e2Y2NwDK4MCrGpt6hdSxuKyDGyBRScBRuEvfJpN4aXXuf/2Rt31vkW GYIOHGkMAmqC4w7eo/Y3gPVC0AoxnxIWmEF/VRxw0VWwYUr2rcQpi2mn+9dAR+l6p0zn C0eA== X-Gm-Message-State: AGi0PuYhBrlqHSKVcdQw+GLm6ceyQ4b6o6T4AS7hqPb3PQKseALHB7jn RuMPCMDeyLqu0lneMyeKp1WpT16TtaXkSZzEV6Y= X-Google-Smtp-Source: APiQypI5qcLv1Q+7ntl23iH0+PWwUL915yFhK2OTj15VL4/1YyJgPWmfk+aV+8VTH1L5TPBsZz/VHND89MvEsq0Y34M= X-Received: by 2002:a92:4a11:: with SMTP id m17mr10262548ilf.125.1588793906565; Wed, 06 May 2020 12:38:26 -0700 (PDT) In-Reply-To: <87k11pzqw7.fsf@t510.orion.oneofus.la> Received-SPF: pass client-ip=2607:f8b0:4864:20::142; envelope-from=joaotavora@gmail.com; helo=mail-il1-x142.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:249117 Archived-At: On Wed, May 6, 2020 at 4:38 AM Vladimir Sedach wrote: > This is not a dependency failure. It should be possible to > automatically pull in minor version upgrades that add functionality Let me start with a fact from another non-Lisp language. If in C++ (where you people that have the the very same misunderstanding BTW) you abuse the "using" directive correctly you run into the the very same situation. So this is a fundamental characteristic of the problem, not any language. If you want to have names from a different namespace X addressed without qualification along with other names of namespace Y also without qualification, either you control X and Y forever or you expose yourself to these problems. By definition, if either X or Y is in a library that you don't control, then you don't control them. So _don't_ merge namespaces unless you know what you are doing. Like anything in programming. Or anywhere. > There are no warnings. The developer of XYZ developed against ABC > 1.0, which did not have any warnings. Yes, and because she decided to use :USE for a package that is outside her control, she is obligated to register somewhere that her library only supports <=3D1.0. It's very simple. It's not related to CL at all. > In Elisp there would be no warnings period. How do you know this? Have you seen the future? > And there would be no warnings if you assign > variables instead of defining functions. That's why you `defvar` before assigning, and any decent lisp (including Elisp) will tell you at compile time if you don't. > > Or stop `:USE` of packages of systems whose code he doesn't > > control. > That is the current recommended practice in Common Lisp-land. Where, pray tell, is this Village of Dubious Recommendations? :-) > not happen in R6RS. Their solution was to make exported bindings > immutable. This is not going to work for Elisp. So it errors when symbols clash? A possible strategy, I guess, but not really a "solution" because the problem has no solution. I asked you to show me the problems with CL packages. If you said :USE is mandatory always, then I would agree with you immediately. That would be a pretty useless package system, though. It seems you want a namespacing system that _doesn't_ have namespace merging. Fine. Let's get one with local nicknames and you'll use only that. But full merging is useful, too. It's the usual "with great power". > The real reason Quicklisp seems to avoid this problem is because it > requires all libraries to build without any warnings, and redefining > a function causes a warning in some implementations. Re-assigning a > variable will not give any warnings and may not show up in unit > tests, so this problem is still possible. Again, you can't assign a variable without having it defined first, or you get a warning, so there's a contradiction there somewhere. > If you don't believe me, you can ask in > ircs://chat.freenode.net/#lisp What should I ask? "has anyone here ever misused the package system? or written bad code"? Doesn't sound very interesting. And if those people have something to add, they can do it here, no? To wrap this up: - I understand your :USE situation, thank you very much; - Don't merge namespaces that you don't control; - For development, the compiler warns on redefinition. You can choose not to load a compilation unit that warned. Jo=C3=A3o