Using CLISP instead of CCL to bootstrap SBCL

[Mark H Weaver]

Hi Pierre,

I just noticed that last November, you changed our SBCL package to use
CCL for bootstrapping.  Previously, it used CLISP.

  commit 4bddcae94bb9d19112354f8f0b93f6e381e67768
  Author: Pierre Neidhardt <address@hidden>
  Date:   Sat Nov 24 18:33:55 2018 +0100
  
      gnu: sbcl: Update to 1.4.13.
      
      * gnu/packages/lisp.scm (sbcl): Update to 1.4.13.
      [native-inputs]: Use minimal texlive-union instead of full texlive.
      [native-inputs]: Use CCL instead of buggy CLISP.
      [arguments]: Replace all (zero? (system* ...)) by invoke.

Since our CCL package only supports i686 and x86_64, a few days later
Efraim changed it back to use CLISP on all non-x86 systems:

  commit 76d520facb54f4f86977683fd21bf1d4ac5ba45d
  Author: Efraim Flashner <address@hidden>
  Date:   Thu Nov 29 11:54:30 2018 +0200
  
      gnu: sbcl: bootstrap with clisp on non-Intel machines.
      
      * gnu/packages/lisp.scm (sbcl)[native-inputs]: If the current system is
      not x86_64-linux or i686-linux, use clisp in place of ccl.
      [arguments]: In the custom build phase, use the correct bootstrap lisp.

The most severe problem with CCL, from my perspective, is that
apparently it cannot be built from source code, or at least our package
in Guix doesn't.  As documented in our CCL package definition:

    ;; CCL consists of a "lisp kernel" and "heap image", both of which are
    ;; shipped in precompiled form in source tarballs.  The former is a C
    ;; program which we can rebuild from scratch, but the latter cannot be
    ;; generated without an already working copy of CCL, and is platform
    ;; dependent, so we need to fetch the correct tarball for the platform.

I consider this issue to be sufficiently serious that I'd like to
propose switching back to CLISP for all systems.

In your commit log, you wrote "Use CCL instead of buggy CLISP".  What
bugs are you referring to?  Is there a bug in CLISP that prevents it
from successfully bootstrapping current SBCL releases?  If so, have the
CLISP developers been informed?  Or did you make this change
preemptively, based on lack of confidence in CLISP to do the job?

My immediate interest in this is that I'd like to try "Next" browser,
but I don't want to trust a precompiled CCL heap image.  Is there a
reasonable way forward to address this concern?

       Thanks,
         Mark