Assumptions the 'residential style' makes that are not enforced

[masinter]

A problem with the ability to LOADFROM(LLKEY) or LOAD(LLKEY PROP) is a general problem, that the ability to develop code in Medley depends on some conditions that are not enforced and are sometimes violated, to the point where ordinary Interlisp operations willl fail.

The scope of these invariants are difficult to enumerate, but are due to dynamic run-time changes vs the lexical order of execcution.

(This is a little difficult to express... )

Originally posted by @nbriggs in #2021 (comment)

[masinter]

I don't remember what this was about, and I can't figure it out. I'm going to close this issue.

[nbriggs]

This issue was prompted by the following exchange --

Member nbriggs commented on Feb 15, 2025:
Check out rmk65, build your full.sysout (because there are a lot of changed files in this branch, so it's easier to do it that way), then checkout rmk68 and (LOAD 'LLKEY.LCOM) into a running full.sysout. You don't always have to build a sysout in order to load changes.

Member pamoroso commented on Feb 15, 2025:
I followed that procedure but when loading LLKEY.COM from rmk68 Medley becomes unresponsive.

Author rmkaplan commented on Feb 15, 2025:
LLKEY may be a file that you can't load on top. I tried also with the same result.

Member nbriggs commented on Feb 15, 2025
Yeah, it looks as though it must reinitialize something for which that's fatal. So go the other way around - make a Lisp.sysout with the new LLKEY, run that, switch branches and load TEDIT.

[masinter]

Feel free to reopen this issue, but it would help if you could expain better what you think the problem is.

[nbriggs]

I'll leave it closed -- What I think we're seeing here (and I don't know how to fix it) is that code that is loaded after LLKEY derives something from an object initialized by LLKEY, but when LLKEY is reloaded it creates a new instance of that object, but the derived data isn't recreated -- so the later code is looking at LLKEY data that's now dead, while LLKEY happily updates the new instance which has nobody watching it.

[masinter]

If there's a particular problem with LLKEY I think we could probably take this on as an issue.

As a more general consideration, there are problems with the late binding of LISP and the residential style, in general, being that you have to be careful mixing evaluating of expressions out of order when running compiled or reloading or ... Characterizing those situations and avoiding them is a longer discussion.

Medley source files have more restrictions than Common Lisp does because you can't change the readtable or the package or the external format (encoding) ... that's something we could take on.

I'll convert this issue to a discussion and open anotehr issue for LLKEY not being reloadable.