medley
medley copied to clipboard
Interlisp
Edit interface (ED, EDITDEF) is confused about FNS and FUNCTIONS
This is one of those not-quite-right Interlisp/Commonlisp integrations.
The various edit interface functions DF, ED, EDITDEF eventually go down to DEFAULT.EDITDEF, passing a TYPE argument.
From DF the TYPE is derived from a list that contains FUNCTIONS and FNS, and DEFAULT.EDITDEF is called separately for each of those. Typically that's not a problem, because a given atom usually has only one definition of only one of those types, and WHEREIS knows where that definition is.
Things go wrong in the odd-ball case of a function that has both FNS and FUNCTIONS definitions. It tries for FUNCTIONS first, finds it, and you are never given the choice of the FNS definition.
Worse, if the FUNCTIONS definition is on a file that the WHEREIS database knows about but that is not in your search path, then you can't edit even the FUNCTIONS definition. It asks to loadprop the file, can't find the file, and bombs out.
The particular example is the attempt to execute DF FIXEDITDATE. FIXEDITDATE is a FNS on EDITINTERFACE, but also has an override FUNCTIONS definition on lispusers/migration/IL-SIM. Since ED tries for FUNCTIONS first, WHEREIS gives it that file, it can't be found, and you get an error. The only way to get at the definition you want is by (EDITDEF 'FIXEDITDATE 'FNS), avoiding the DF and ED pathways. (Of course, if the file could be found, you would end up editing the unintended definition (except that the file IL-SIM can't be loaded without other migration files being loaded first).
What should happen, in terms of the edit interface, is that we have a supertype that includes both FNS and FUNCTIONS (maybe NIL?), that doesn't get split out until it passes through all of the intermediate functions to a lowest level where all the options are available and the user is given a choice (FNS XXX on file1, FUNCTION XXX on file2).
Why did this obscure situation arise? Well, we are now allowing file search paths (directories, lispusersdirectories) to go down one extra level, so that all the files of a given package can be grouped together. E.g. all the LAFITE files are under lafite>, all the TMAX files are under tmax>, etc. But FINDFILE will still find the file by its top-level name. The WHEREIS database naturally inherited this extra level of indirection, so it notices files that it didn't notice before this change. In particular, I don't think it noticed migration>IL-SIM before, and so didn't know that it contains a dummy definition of FIXEDITDATE (and lots of other functions that will probably now be confused).
So: I think the edit interface should be fixed so that it doesn't fall into this trap. I think IL-SIM should be fixed so that it doesn't overlay functions (FNS or FUNCTIONS) directly (multiple definitions are always a bad idea), and maybe a subdirectoy like lispusers>migrations> should be explicitly excludable from the WHEREIS scan.
I agree that there are some nasty unintended side effects from indexing more stuff, and the way that editdef handles multiple type situations. I don’t think the migration code should be part of the “normal” packages… it’s special purpose code that nobody should be using unless they specifically need it, and no new user should be in that situation
lispusers/migrations/IL-SIM is a particular nuisance. Can we simply put it on an exclusion list when we are constructing the whereis database?
or fix make-whereis-hash to only index files in subdirectories that FINDFILE can find. I'll try that.
Another possibility would be to filter or even just prioritize the results of WHEREIS in its caller when looking up in the hash file.
I don’t know how generic a solution we need. This particular flle is particularly terrible, because its whole point is to override a bunch of standard Interlisp stuff. (It could be fixed up by renaming all of its functions, and then doing MOVD’s).
But getting rid of just it would maybe make the problem go away.
On Jun 29, 2022, at 2:41 PM, Larry Masinter @.***> wrote:
Another possibility would be to filter or even just prioritize the results of WHEREIS in its caller when looking up in the hash file.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/768#issuecomment-1170520448, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJILVQP7TMIWYLUNYU3VRS7KLANCNFSM5VKVYLSQ. You are receiving this because you authored the thread.
IL-SIM is still in the WHEREIS database and still confusing things. How can we get rid of it?
I'm thinking now that we can make FNS write out CL:DEFUN and CL:DEFMACRO definitions and make VARS would include (and save) those variables defined with DEFCONSTANT DEFPARAMETER. TYPESOF would return FNS and/or VARS.
if you just want to get rid of one file.... move it?
My current thinking has been to merge FNS and FUNCTIONS, VARS and VARIABLES. You can also use the singular -- every entry goes through GETFILEPKGTYPE. There are definitions that are "raw" (like a LAMBDA or NLAMBDA) and those that have definers. The definers override a raw.
only one will be on FILEPKGTYPES (I prefer FNS and VARS).
Some other things to test: substitution editing ED(FOO FILE) => ED(FOOCOMS VARS) Interlisp macros ignored/warned ? a definer for IL instead of DEFINEQ?
Masterscope etc. aawareness of MOVDs Masterscope analysis of filecoms expressions and assignments
Why would Interlisp macros be ignored or warned? There are many many of them, no?
Should we handle the interaction of Interlisp Macros, optimizers and other pseudo-definitions with subsequent or earlier definitions as CL:DEFUN or CL:DEFMACRO. Right now it just lets them both be define if a DEFINEQ happens after the CL:DEFUN or CL:DEFMACRO and overrides if the other way around. NLAMBDAs are "special forms" -- would you want one as well as a defmacro? I can't remember why we did it this way in the first place, which bothers me. "definer for IL": (IL:DEFUN FOO (X) ..) or something shorter like (IL:DE ...).
my objective here is to make the "Welcome to Medley" demo simpler. it's confusing to have the 'dummy definition' menu show both FUNCTIONS and FNS. There might be a better way to approach this ... just change the menu.
I think I'd look to the source to see what combinations of things are already observed as definitions on the same atom. I just always thought of FNS as Interlisp and FUNCTIONS as Common Lisp -- and I usually knew which way I wanted it, but if you don't recognize the distinction then I can see it would be confusing, but I don't think that's a forcing function to change it. I don't think we need IL:DEFUN vs IL:DEFINEQ, do we?
A first move would be to simply remove the dummy definition menu. It is an-almost-never-right nuisance that pops up whenever you mistype the name of the thing you want to edit. You might want something as part of a beginner’s tutorial, but it is otherwise not really helpful.
On Oct 11, 2022, at 5:53 PM, Larry Masinter @.***> wrote:
Should we handle the interaction of Interlisp Macros, optimizers and other pseudo-definitions with subsequent or earlier definitions as CL:DEFUN or CL:DEFMACRO. Right now it just lets them both be define if a DEFINEQ happens after the CL:DEFUN or CL:DEFMACRO and overrides if the other way around. NLAMBDAs are "special forms" -- would you want one as well as a defmacro? I can't remember why we did it this way in the first place, which bothers me. "definer for IL": (IL:DEFUN FOO (X) ..) or something shorter like (IL:DE ...).
my objective here is to make the "Welcome to Medley" demo simpler. it's confusing to have the 'dummy definition' menu show both FUNCTIONS and FNS. There might be a better way to approach this ... just change the menu.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/768#issuecomment-1275446210, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKPC2WGRKTG77XNAGTWCYD2FANCNFSM5VKVYLSQ. You are receiving this because you authored the thread.