unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Programmer <programmer@verisimilitudes.net>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: guix-devel@gnu.org
Subject: Re: Lisp libraries: Other variants? (CCL, CLisp, etc.)
Date: Fri, 09 Nov 2018 01:45:28 -0500	[thread overview]
Message-ID: <bm6ykauv.fsf@server.domain.com> (raw)

>Have you looked at lisp-utils.scm?  I think it incorporates some of your ideas
>already.  It could perhaps be generalized following your ideas so that it works
>for all Lisps out of the box.
I've not.  I did a cursory search for this as well, but didn't find anything.  Would you be so kind
as to link me to it so I can give a good idea of whether it's similar or not?

I was aiming for something specifically suited to Common Lisp, since many Schemes have their own way
of doing things, but if a general approach works best then that would be great.  It is important to
note, however, that I find it a very important quality that there be no need to load code into the
Common Lisp implementation for doing this, as that's inconvenient.  Ideally, the Common Lisp
implementation is just told what file to LOAD and everything else is handled nicely.

I'd also want to make my proposed method work across many different systems, ideally, with little
friction.

>Question: Are .fasl files compatible across Common Lisp implementations?  If
>not, then what's your suggestion?
FASLs aren't standardized in form, so even the same implementation across different versions may be
unable to use earlier or later FASLs.

My suggestion, if this becomes an issue, is to have FASLs deposited in a fasl subdirectory of the
Common Lisp directory with further subdirectories denoted by Lisp implementation name and it may be
a good idea to think ahead and also use the particular version in the subdirectory name.  This
provides a simple, perfectly portable, and rather foolproof way to get the proper behavior for this.

>By "system", do you mean a _build system_ or something else?
I meant something like ASDF, but more abstract and able to be compiled to representations including
ASDF and Guix declarations and whatnot, with the reasoning that ASDF is rather grotesquely large and
unwieldy, among other things.

>We want to install libraries in the store.  Why do you suggest we put it in the
>user's home?
You misunderstand.  The library would be in the store, but there would be a file placed in the
user's home directory, because Common Lisp has a USER-HOMEDIR-PATHNAME function, that would handle
loading dependencies and the actual library.

So, you'd LOAD the same file whether you're using Guix, Debian, etc. and so whether the actual
library is the store, /usr/lib/, or anywhere else, varying on how the system package manager does
it.

>Sorry, I don't understand how your proposal would eliminate the POSIX-assumption
>issue.  Can you provide an example?
Sure I can.  It's been a while since I've tried this, but common Common Lisp tools to load code
don't actually know anything about the structure of the system, so under POSIX they simply check the
usual locations, instead.  This blows up miserably under Guix, since it does things differently.
With the idea of generating the code used to load things from a higher-level description, you can
adapt it to the particular system, rather than simply checking many directories like it's a
configure script or something.

Just let me know if anything else is still unclear.  I'd be very glad to help Guix have a pleasant
Common Lisp packaging method that works across systems.

             reply	other threads:[~2018-11-09  6:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-09  6:45 Programmer [this message]
2018-11-09 11:02 ` Lisp libraries: Other variants? (CCL, CLisp, etc.) Pierre Neidhardt
2018-11-09 20:17   ` Programmer
2018-11-10 10:02     ` Pierre Neidhardt
  -- strict thread matches above, loose matches on Subject: below --
2018-11-05  1:35 Programmer
2018-11-05 21:03 ` Pierre Neidhardt
2018-10-20 10:10 Pierre Neidhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bm6ykauv.fsf@server.domain.com \
    --to=programmer@verisimilitudes.net \
    --cc=guix-devel@gnu.org \
    --cc=mail@ambrevar.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).