From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Mon, 21 Aug 2017 21:52:03 -0700 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83d17qcfa1.fsf@gnu.org> <83h8x0c206.fsf@gnu.org> <83efs4byzj.fsf@gnu.org> <83378kba5u.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1503377680 7800 195.159.176.226 (22 Aug 2017 04:54:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2017 04:54:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 22 06:54:35 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dk1Cu-0001QS-Gz for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2017 06:54:28 +0200 Original-Received: from localhost ([::1]:38014 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dk1D1-0005Jl-3i for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2017 00:54:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dk1BL-0004ci-RM for emacs-devel@gnu.org; Tue, 22 Aug 2017 00:52:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dk1BK-0006qN-Gq for emacs-devel@gnu.org; Tue, 22 Aug 2017 00:52:51 -0400 Original-Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:33872) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dk1BH-0006pT-Nf; Tue, 22 Aug 2017 00:52:48 -0400 Original-Received: by mail-lf0-x232.google.com with SMTP id g77so42276144lfg.1; Mon, 21 Aug 2017 21:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p4sXSycPjyremVF6PoSl1IImGQrmhvbD4TfC9vcAJeg=; b=AdC0VWtw+6+E1xyxjImR8oM2ayKfRC9g58uay/+cAFvRAslOw+endfonKC3p5AKrPY CkAnpXKzmnMw62K8cJkInHq7edkwQi5ZL0MB05aIUdgMA/9dDfh2AWzKODrU72ihuRHp MrdCIBazjZYYj+5qFFKwIzHq2n0Pt1lCRIA6F3sQhKld3XJKLa5hp0RUfZUxI20hIhkD 5MXuyda4KFjd4genGHi5rYZx+HU+IBDow3/S32FUe8ThbmixQo2UhI/EWD3A15fC+iLx fh4oalv2ep7K0P+kWApebSY2yjWi6Lxa3d9H6k5W++rJol6/JQm7LGzQb7eWQ6NNMniZ wL8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p4sXSycPjyremVF6PoSl1IImGQrmhvbD4TfC9vcAJeg=; b=dUOHLancMfpPyY4ejS4tPeZyQc1UwxZ9aM4Lb0D1TeEuhiXhcnAJZgr4Elh/2/1NwX jgSwtmaNJETIDYCuSkucFO3dQg+8Ni0qA3qI3/UbJ81TxPPkwPDBA0BQivBZJGHJZUoC yzTvjD+9b1vo/9CoX8luLcb9pcoKRwUZogPD6xv7XBmiwqcI/iQ1gd2hu79TFeMI37RZ VzUnsKcJUIm1zeqO2GzgRiFoOrZO3dMzLHci8Qa0hBMr1P3E55smGcpvtQpFczgznYS8 bmyO+HL5oRq5lKBueelKpS98+Khjufgw0BUW3beZxs1K5q+LYsdYHo03eeZ8n3Osmw3j +dfw== X-Gm-Message-State: AHYfb5jZqehhjnwPqPC1E2TdlQz+QA61f+jFgrQIBT5j4aXSHnziJh7q GdXV5Fs8k3DSMT7UPQIoM6ZSL9wtf11gBw9kMw== X-Received: by 10.25.21.94 with SMTP id l91mr2734826lfi.16.1503377564578; Mon, 21 Aug 2017 21:52:44 -0700 (PDT) Original-Received: by 10.25.80.3 with HTTP; Mon, 21 Aug 2017 21:52:03 -0700 (PDT) In-Reply-To: <83378kba5u.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217676 Archived-At: > From: Radon Rosborough > Date: Mon, 21 Aug 2017 13:33:51 -0700 > Cc: emacs-devel@gnu.org > > > That being said, one possibility is to have a function in package.el > > scan the user init file for the definition of package-load-list, and > > process that line before loading the packages. > > I really don't want to sound rude, but... *please* no. That would be a > horrible hack. We do something very similar in other situations, like finding the file-local variables. > It will fail in so many different circumstances: > package-load-list set in a different file, package-load-list set > dynamically, package-load-list set in an unconventional way, > package-load-list set by a macro, etc. etc. etc. Nothing that cannot be handled. > Emacs Lisp is Turing-complete. It is futile for Emacs to try to > understand it. That's a strange thing to say about a program which implements that very language. Anyway, the proposal still stays, and I just pointed out one way, perhaps not the best one, out of the conundrum that you described as insoluble. I hope someone will come up with a better solution, or implement what I proposed. Otherwise, I predict that we will remain at an impasse for some time more. ===== > > > That being said, one possibility is to have a function in package.el > > > scan the user init file for the definition of package-load-list, and > > > process that line before loading the packages. > > > > I really don't want to sound rude, but... *please* no. That would be a > > horrible hack. > > We do something very similar in other situations, like finding the > file-local variables. That is completely different. File-local variables conform to a fixed, simple syntax which is -- in particular -- not Turing-complete, unlike Emacs Lisp. If you'd like to propose that `package-load-list' and friends only be settable via file-local variables, then that would indeed solve the problem. But that's a different proposal. > > Emacs Lisp is Turing-complete. It is futile for Emacs to try to > > understand it. > > That's a strange thing to say about a program which implements that > very language. I should have said: "Emacs Lisp is Turing-complete. It is futile for Emacs to try to understand it in any way other than executing it." That is what I meant. Static analysis is very different from just running the program and seeing what happens. > > It will fail in so many different circumstances: > > package-load-list set in a different file, package-load-list set > > dynamically, package-load-list set in an unconventional way, > > package-load-list set by a macro, etc. etc. etc. > > Nothing that cannot be handled. This is objectively false, and can be formally proven as such. I'll try to explain better this time. (But the gist is, if you could somehow "handle" this in general, you would also be able to solve the halting problem.) The issue is that determining anything nontrivial about the behavior of an arbitrary piece of code is impossible in general, if the language is Turing-complete. This is the content of Rice's theorem. Stated in terms of Turing machines, it is as follows: Let S be a property of Turing machines. Assume that S is a nontrivial property, meaning that there exists at least one Turing machine with property S and at least one Turing machine without property S. Assume also that S is a functional property, meaning that it depends only on the inputs accepted and rejected by the Turing machine. Then, it is undecidable whether an arbitrary Turing machine has property S. Stated in terms of package.el: Let S be a property of Emacs Lisp init-files. In particular, let S be the property that `package-load-list' is set to a given value T when the init-file is evaluated. It can be verified that the property S is nontrivial and functional. Thus, it is undecidable whether an arbitrary Emacs Lisp init-file sets `package-load-list' to any given value. There is a loophole, however, since in the case of init-files, we are willing to limit ourself to the case where running the code is guaranteed to terminate (otherwise Emacs would not start up in the first place). This allows us to determine, in general, what an init-file does to `package-load-list'. The catch is that we must actually evaluate the init-file to do so. Why is this important? It means that we can't correctly figure out the values of `package-load-list' and `package-user-dir' before we have actually loaded the init-file. It is only possible to do a `package-initialize' operation correctly *after* loading the init-file, and any attempt to the contrary will fail in general. > Anyway, the proposal still stays OK, but given that there is a formal proof that no general solution can possibly exist, I don't think anybody will find one. If you're proposing that we simply accept that package.el cannot be customized in a dynamic way, then yes, that would solve the problem. But that's a different proposal. > I just pointed out one way, perhaps not the best one, out of the > conundrum that you described as insoluble. Your way relies on solving the halting problem. I don't think it counts. > I hope someone will come up with a better solution, or implement > what I proposed. Otherwise, I predict that we will remain at an > impasse for some time more. I started this thread by proposing a specific, comprehensive solution to the problem. Nobody has pointed out any flaws yet. Why is there an impasse? Best, Radon P.S. Sorry if I'm being a bit blunt here. But it's hard not to be blunt in analyzing a problem when computability theory says there is no solution.