From mboxrd@z Thu Jan 1 00:00:00 1970 From: Programmer Subject: Re: Lisp libraries: Other variants? (CCL, CLisp, etc.) Date: Fri, 09 Nov 2018 15:17:53 -0500 Message-ID: References: <87bm6y4ipf.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLDEB-0007KO-HW for guix-devel@gnu.org; Fri, 09 Nov 2018 15:18:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLDE8-0003mb-Ua for guix-devel@gnu.org; Fri, 09 Nov 2018 15:18:03 -0500 Received: from [2604:180:2:725::698a] (port=39948 helo=verisimilitudes.net) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gLDE5-0003c6-0r for guix-devel@gnu.org; Fri, 09 Nov 2018 15:17:58 -0500 In-Reply-To: <87bm6y4ipf.fsf@ambrevar.xyz> (message from Pierre Neidhardt on Fri, 09 Nov 2018 12:02:36 +0100) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: guix-devel@gnu.org >Sure: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/lisp-utils.scm I've only taken a look at lisp-utils.scm so far. I can see it explicitly supports sbcl and ecl. It's possible to get most or all of this in purely portable Common Lisp, which would make adding more implementations require no effort. >But how do you build this for a single Guix package? If you want FASLs for, >say, SBCL and CCL, then you need to invoke both compilers when building the Guix >package. It would be much to heavy weight that every single Lisp package >depended on all Lisp compilers, plus it would result in disk consuming packages >that would benefit practically no one (no one uses all Lisp compilers at the >same time). >I could be missing something. Can you see a way around this? I do see value in offering compiled forms of standalone Common Lisp programs, such as StumpWM, but don't see the point in doing this with Common Lisp libraries. The common way to do this in Common Lisp is to distribute the source and simply compile it as needed. It can be advantageous to have this choice easily. The basic idea is simply that the system package manager installs libraries wherever it will and places a file that will load this library and its own dependencies properly in the user's home directory. It would be simple to have it check for and load compiled versions if present or compile them if not after loading for faster reloading. So, this would enable you landing into a new system to, say, reuse your Common Lisp initialization files that reference the directory and seamlessly pick up from where you left off, once the system package manager installs things. Does this idea make sense? >If this is more general than Guix, does it still belong to the Guix project? >Shouldn't it belong to the Common Lisp community as a replacement for ASDF? I >know the Common Lisp community has been talking about replacing ASDF for a >while. I thought Guix would be a good first place to propose this idea. If it would be more appropriate, I now have time to build a first approximation of this idea, although I lack the Guix knowledge for a robust implementation. I did provide a simple example of this in my initial message, which shows the file a library would have that loads another library that has no dependencies. >Fare (one of the maintainers) has talked about it a few times: >https://fare.livejournal.com/190738.html and other articles. I'll make certain to read this. I've read some of his articles before. >But who places those files? Guix cannot. >Did you mean the user guix-profile instead? I'm not certain by what you mean. I did ask around earlier and learned it's not uncommon for Guix to place files in the user's home directory when needed. I'm not particularly familiar with Guix terminology yet. >My understanding is that CL-CFFI makes those assumptions. A few months back I >had brought up the issue upstream and they told me they were not eager to change >it. >The way we do it now is probably optimal. See cl-sqlite for instance. I'll need to take a look at those later. >I'm realizing my answers might come off as discouraging. I hope it's not, we >still need to work on the build system on the Guix side, while the Common Lisp >side would certainly benefit from improvements to ASDF (or its successor). You need not worry about discouraging me. I'd be delighted to see ASDF and Quicklisp replaced with more intelligent, simpler, and more secure solutions for this simple problem.