Errors when evaluating expressions from H

[pamoroso]

Describe the bug

Evaluating an expression such as 1 at the REPL of the H LispUsers module (a Horn clauses theorem prover) prints this prompt:

CATCH -> CL:CATCH ?

Answering no yields the error:

CATCH is an undefined function.

Answering yes yields the error:

first-level is an unbound variable.

To Reproduce

Steps to reproduce the behavior:

1. sign into your Interlisp Online account
2. under Initial Exec, select Interlisp
3. click Run Medley
4. evaluate (FILESLOAD H-LOAD)
5. on the desktop, right-click and select H
6. at the H prompt, evaluate 1

Expected behavior

The value of the expression is printed with no prompts or errors.

Screenshots

The full desktop with the break window after answering no and yes to the prompt:

Context (please complete the following information):

• OS: Linux Mint Cinnamon
• OS Version: 22
• Host arch: x86_64 (System76 Merkaat)
• Maiko version: N/A
• IL:MAKESYSDATE: 31-Jul-2024 02:24:40

Additional context

A debugger session after answering yes to the prompt and executing RETRY

H/9(debug)BT
OLDFAULT1
NEWFAULT1
FAULTEVAL
CL:CATCH
FAULTAPPLY
CATCH
H.?v
H.?!
HReadProvePrint
LISPX
USEREXECA0001A0002
USEREXEC
H

H/10(debug)?=
  FAULTX = first-level
  FAULTARGS = NIL
  FAULTAPPLYFLG = NIL
H/11(debug)PB first-level
bindings for first-level: 
 @ TOP : NOBIND
H/12(debug)EDIT
"Can't"
H/13(debug)

Making the H.?v frame current and executing EDIT yields the error "Can't" but the code of H.?v is available at the Medley repo:

(H.?v
  [LAMBDA (formulas)                                         (* edited: " 3-Feb-87 11:16")
    (CATCH (QUOTE first-level)
         (LET ((counter (PLUS 1 *limit*))
           (globalslashflag NIL)
           (IsCar NIL))
              (MkVars formulas)
              (H.prove (LIST (LIST formulas NIL))
                 1])

I'm not sure how to proceed from here. And I wonder why the original developers didn't qualify the CATCH symbol here and elsewhere in the file.

[MattHeffron]

I looked at the H source files and noticed that they do not have a DEFINE-FILE-INFO before the FILECREATED. I'd guess that back when the files were written, some manual IMPORT into IL: of symbols, like CATCH and THROW, was done but wasn't captured in the file COMS to recreate the condition when the files were later loaded. (This seems to imply that the files were compiled in an environment where the IMPORT wasn't done.)

Also, since CL:CATCH is a "Special Operator" I suspect that DWIM trying to fix it at the BREAK might not work quite right...

Just some guesses.