[slime] swank-loader could use ASDF (#65)

[João Távora]

Helmut Eller <eller.helmut at gmail.com> writes:

> My use case is more like:
>
>   git clone .../slime.git
>   make install

Sure, that can be served too.

> I'm not worried about the one time cost of compiling lisp files.  I'm
> talking about the cost of loading additional fasl files every time.

Yes, I understood that. I was presenting an additional concern regarding
compile-times.

I'm waiting for François's numbers on the relative proportion of loading
ASDF to loading the current swank-loader.lisp across some
implementations. That way we can check if by requiring ASDF to be
loaded, we're introducing some extraordinary burden on users of slime using
these implementations.

> So you say that's a clear advantage?  Well, I still clear out ASDF's
> fasl cache regularly because I don't trust ASDF.  And I rather debug the
> code in swank-loader.lisp than in asdf.lisp.

Yes, it seems like an advantage. Well I understand your point about
debugging a familiar swank-loader.lisp, it's not so for others
(i.e. co-workers not managing to get a contrib loaded or understanding
why swank error'ed out and quit their Allegro suddently). ASDF offers
good error messages and restarts, which are already familiar if you're
in the quicklisp/asdf ecosystem.

In general, offloading some responsibilities to a software package that
specilize in them is a good policy in my opinion.

In my view `slime-init-command' should keep "returning a string to
initialize lisp", as per its docstrings. But that string, by customizing
a variable:

* should, be default, be built around applying ASDF:REQUIRE-SYSTEM to
  :SWANK and/or whatever contribs the user has set up.

* could be based on loading swank-loader.lisp from the current
  directory, which is the current case.

* could be based on some custom swank-loading-logic if the user decides
  so.

Maybe we coulnd move the current swank-loader.lisp to
swank-asdfless-loader.lisp and load it as per a `defcustom' that you
enable in your config?

Still, I'm curious as to why you don't you trust ASDF? Any specific
problems in mind?

> I would say ELPA packages must be installed and the user "makes" .elc
> files.

I don't undertand this bit. ELPA packages are uploaded by the developers
onto remote repositories and fetched-and-installed via package.el's
`package-install' command.

They can/should be built by us using a make target that picks out some
files from the source repo, auto-generates others like
slime-pkg.el. package-install then autogenerates a slime-autoloads.el
file and byte compiles the remaining ones, sets up load paths and all
that.

> Assume we know how to load quicklisp. Let's say the user needs to create
> a config file, ~/.slime/config, that looks like so:
>
> (:load-quicklisp-form (cl-user:load-quicklisp)
>  :load-asdf-form (require :asdf)
>  :slime-contribs (slime-repl slime-foo))

At first sight, this would personally bug me: why not do this in the
user's .emacs in elisp? Why this file? very few EMACS packages have
their own config files (I can think of Gnus only) and they are all
emacs-lisp, so that they can be perfectly replaced with elisp code in
user's init files. I would see no advantage in adding one such file
to SLIME.

Also, if I understand correctly, this file would make ELPA (and el-get)
packaging much more complicated and non-standard.

To be clear. I'm not adding a ASDF dependency to slime so that we get
ASDF in the lisp runtime, although that is a side effect, unless we go
to some lengths to delete the packages afterwards.

I'm adding it because it's becoming a standard and is specilized in
representing dependencies between systems, which is something we can
definitely use to simplify out loading behaviour:

* to make addition of third-party contribs easier;

* to ease bundling our own existing contribs in separate packages;

* to have "one" way of loading swank, less 300 lines to maintain, and
  one less option-hungry SWANK-LOADER:INIT to worry about.

Once we have a simple enough loading behaviour, it's much easier to add
installation behaviours that serve:

* your "make install" use case
* the hacker's clone-my-own case
* ELPA's package-install <some-package-depending-on-slime>
* el-get

> we know how to load quicklisp but doesn't mean we load it all the
> time.

I'm still confused. When don't we load it? BTW I think quicklisp
always loads ASDF.