Re: ABCL uses to recompile LCONS* form

Stas Boukarev <[email protected]> Sun, 1 Nov 2020 19:39:54 +0300
Newsgroups gmane.lisp.slime.devel
Message-ID <CAF63=11HAxu0K27FOv_DA7Zy4SmwV4f9Bu96tKH_70GnAi=ELw@mail.gmail.com>
I don't see any problem with moving things to whenever they're needed.

On Sun, Nov 1, 2020 at 7:36 PM Mark Evenson <[email protected]> wro=
te:
>
>
>
> > On Nov 1, 2020, at 17:21, Stas Boukarev <[email protected]> wrote:
> >
> > On Sun, Nov 1, 2020 at 6:22 PM Mark Evenson <[email protected]>=
 wrote:
> >>
> >> Note to all:  the abcl.lisp implementation inadvertenly contains a ref=
erence to
> >> LCONS*.
>
> [=E2=80=A6]
>
> >> Back in 2017 or so, @aruttenburg had a patch to some of move the some =
of the
> >> utlities to load before the implementation-specific, but @stastats obj=
ected on
> >> the grounds that we want the initial load to be as fast and error free=
 as
> >> possible.
> > I don't remember saying that or follow the logic here.
>
> My apologies for incorrectly paraphrasing your position.
>
> Let me try to restate:  the ABCL implementation would like to use some of=
 the
> machinery from swank.lisp, such as the [lazy list macroization][1].   The
> changes we requested were admittedly jumbled up in whole bunch of other i=
ssues,
> which we eventually resolved by judicious trimming [2][3].  How could we =
ensure
> that SWANK:LCONS* is present when we load the abcl implementation specifi=
c code?
>
> [1]: <https://github.com/slime/slime/blob/master/swank.lisp#L3065>
> [2]: https://github.com/slime/slime/pull/502/commits/1c4681da458470987393=
ed5a2a4ab555a7d4d30c
> [3]: https://github.com/slime/slime/pull/502/commits/1911dcfbe1dbf3445bb4=
1c0483967095cf3c2046
>
> --
> "No, this is not a disentanglement, but a progressive /knotting-into/."
>