File CL:LOADed from (host) filesystem puts code in wrong package

[marcoxa]

Describe the bug
Subject says it all.

To Reproduce
Steps to reproduce the behavior:

1. Using, obviously, Emacs, write a file containing the usual FACTORIAL function
2. CL:LOAD it (from menu or EXEC)
3. The symbol loaded is USER::FACTORIAL, not, as it should be, CL-USER::FACTORIAL.

Expected behavior
The symbol should be CL-USER::FACTORIAL (or, XCL-USER::FACTORIAL)

Screenshots
If applicable, add screenshots to help explain your problem.

Context (please complete the following information):

• Are you using online.interlisp.org? [yes / no] NO
• OS: [e.g. macOS/Linux/Cygwin] macOS
• OS Version: [e.g. Ventura, Ubuntu 24, Raspberry Pi OS] Tahoe
• Display/window system: [e.g. X11, SDL, VNC, Web browser] X11
• Host arch: [e.g. x86_64, arm7l, arm64, SPARC] x86_64

This is obviously a CL no-up-to-date issue.

Marco

[nbriggs]

I'm guessing you didn't start your file with comments. Try

;;; Canonical factorial function
(DEFUN ... )

and try again. It's the presence of a left parenthesis as the first non-whitespace character in the file that causes CL:LOAD to decide that it's an INTERLISP file you're loading and it sets up *PACKAGE* to be INTERLISP in that case.

[MattHeffron]

With the initial comment line, I was able to reproduce this.
F2616.lisp.txt
I did CL:LOAD of this file from the XCL exec.
Then I did (IL:APROPOS "FACTORIAL") which showed USER::FACTORIAL.
This is actually an error in IL:\CML-LOAD.
If it is not passed a PACKAGE argument (or is NIL), then it defaults to (CL:FIND-PACKAGE "USER") instead of *PACKAGE*.
(That code hasn't been touched since 1987, by bvm.)
I redid the CL:LOAD with the non-standard keyword argument :PACKAGE *PACKAGE* and the IL:APROPOS found 2 symbols, the one in USER, and a new one XCL-USER::FACTORIAL.

[marcoxa]

Hi

I was pretty sure this was a CLtL1 --> CLtL2 (and then ANSI) buglet. The "USER" package is a give away.

Marco

[nbriggs]

Oops, yeah -- we're not CLtL2 (yet).

[nbriggs]

@MattHeffron For CLtL2 - shouldn't CL:LOAD just be using the current value of *PACKAGE* - and, as the CLHS says, binding *PACKAGE* to its value before the CL:LOAD, so that it is restored to its original state after the load in case the file being loaded does an IN-PACKAGE (or otherwise changes *PACKAGE*)

[MattHeffron]

shouldn't CL:LOAD just be using the current value of *PACKAGE*

Yes. That's almost what's done.
IL:\CML-LOAD binds *PACKAGE* to (OR PACKAGE (CL:FIND-PACKAGE "USER")) instead of (OR PACKAGE *PACKAGE*), where PACKAGE is a parameter passed down from CL:LOAD's :PACKAGE argument.
The instead of form would accomplish the CLtL2 behavior without necessitating removing the :PACKAGE argument from CL:LOAD.

Actually, the correct form should be:

(OR (AND PACKAGE (FIND-PACKAGE PACKAGE)) *PACKAGE*)

otherwise *PACKAGE* could get bound to a string, or symbol, instead of the actual package object.

Maybe even put some error reporting there for FIND-PACKAGE failure...

(OR (AND PACKAGE (OR (FIND-PACKAGE PACKAGE) (ERROR "Unknown package: ~S" PACKAGE)) *PACKAGE*)

[nbriggs]

I wouldn't check in any changes that move our current state from CLtL to CLtL2 (or ANSI CL) until we're ready to do the full migration. Piecemeal changes make it really difficult to track.

[MattHeffron]

I wouldn't check in any changes that move our current state from CLtL to CLtL2 (or ANSI CL) until we're ready to do the full migration. Piecemeal changes make it really difficult to track.

Agreed.
At least we should document this, with a suggestion to use the :PACKAGE argument to CL:LOAD until CLtL2/ANSI.
It would do the correct thing if the file contained an (IN-PACKAGE specific-package), but there is no way for the file to know what *PACKAGE* was bound to when the CL:LOAD was evaluated.

I would suggest that the PACKAGE of the current form be changed to do the error reporting, without changing the current default. That would make it:

(OR (AND PACKAGE (OR (CL:FIND-PACKAGE PACKAGE) (CL:ERROR "Unknown package: ~S" PACKAGE))) (CL:FIND-PACKAGE "USER"))

[marcoxa]

Ok, That would work of course (although I have not seen the actual code).

However, the CL:LOAD menu in the FileBrowser would not work as we cannot pass the :package argument.

[nbriggs]

However, the CL:LOAD menu in the FileBrowser would not work as we cannot pass the :package argument.

Have a look at the variable IL:FB.MENU.ITEMS -- that's what drives that whole FileBrowser menu. You can replace the CL:LOAD in there with your own function that will get called with each file by FB.LOADCOMMAND, which adds a process to do FB.OPERATE.ON.FILES evaluating the specified function with the name of each of the files selected.

Drop that code into your user greet file so it gets loaded each time you start a fresh Medley. It should be an Interlisp managed file to avoid any other headaches.