Bug report: Loading a FASL into a package which doesn't import SETQ

[Mark Evenson]

> On Nov 11, 2020, at 12:00, Mark Evenson <evenson at panix.com> wrote:
> 
> 
> 
>> On Nov 11, 2020, at 10:40, Mark Evenson <evenson at panix.com> wrote:
>> 
>> 
>> 
>>> On Nov 11, 2020, at 03:44, Robert Munyer <2433647181 at munyer.com> wrote:
>> 
>> […]
>> 
>>> It's conceivably possible that _all_ of the manipulation of *PACKAGE*
>>> that happens during COMPILE-FILE could be removed, because the user is
>>> already required to have *PACKAGE* set correctly when invoking LOAD.
>> 
>> I don’t think this is true:  COMPILE-FILE should actually capture the current package when COMPILE-FILE is invoked, arranging to have this package present when LOAD occurs.  [An example of this][1] works on SBCL/CCL but fails on ABCL even with all of your suggestions.  Please correct me if you believe this isn’t the case.
> 
> Strike “arranging to have this package present when LOAD occurs” as that is certainly not true in general.  It’s more that the compiler should take the current package in account when it determines what the symbols it encounters actually refer to.  More precise formulations of this are welcome…
> 
> -- 
> "A screaming comes across the sky.  It has happened before but there is nothing 
> to compare to it now."

I’m still not quite sure how to describe what I did precisely, but [please see the latest version of my patch][1] for an implementation that seems to pass all of the simple cases of problems with the fasl so one doesn’t have to resort to use of sed.  

As soon as the [ci][] finishes, and if it succeeds, I intend to merge these changes to trunk to fix [475][].  

[1]: <https://github.com/armedbear/abcl/pull/354>
[ci]: <https://travis-ci.org/github/armedbear/abcl/builds/742960126>
[475]: <https://abcl.org/trac/ticket/475>

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."