Interlisp / medley

The main repo for the Medley Interlisp project. Wiki, Issues are here. Other repositories include maiko (the VM implementation) and Interlisp.github.io (web site sources)
https://Interlisp.org
MIT License
376 stars 19 forks source link

Case-insensitive matching of CLISPWORDS in GITFNS/COMPARESOURCES #1761

Open rmkaplan opened 5 months ago

rmkaplan commented 5 months ago

Currently, if MAKEFILE lower-cases the clispwords when it dumps a function with upper-case words, the GITFNS compare will show lots of meaningless changes for functions that really haven't changed at all.

GITFNS uses COMPARESOURCES to find the items to be compared, to compare them, and to print out the messages that end up in the browser window. COMPARESOURCES uses EQUALALL as a first pass test, when that fails it goes to the compare function of the items type, defaulting to COMPARELISTS.

COMPARESOURCES currently can be parameterized by filepackage type, so that each type can have its own comparison function, its own way of extracting the name of the item from its defining form, etc. A brute force way of suppressing the CLISPWORD differences would be to add a BODYFN to the parameter list. If specified, that function would be called before the EQUALLALL test, and GITFNS could install a function that coerces the clispwords to canonical form before it does the EQUALALL. Or such a function could be specified separately, as the value of its own global variable. Or build it in to COMPAREDIRECTORIES, with a flag that turns it on or off.

A similar change to EXAMINEDEFS would eliminate clispword differences when you click to see the actual differences in the Tedit window, for items that somewhere had a substantive change.

masinter commented 5 months ago

I think there's a problem and some choices for what to do about them. BUT I'm not sure the premis is correct:

Currently, if MAKEFILE lower-cases the clispwords when it dumps a function with upper-case word

What I recall is that this "correction" is not made by MAKEFILE -- is made by DWIM (or DWIMIFY) if LCASEFLG is non-NIL. It is applied to any expression iw. a "CLISP word" including i.s.oprs (for, when, as, do, collect finaly while when ...). Masterscope might invoke it when you analyze a function. The compiler needs to also but it works on a copy of the function read from the file being compiled rather than the current definition.

The simple fix to the github compare. problem is to always run with LCASEFLG set to NIL (which, if I recall, iss set when you load SYSEDIT. Then the case doesn't change and you don't get false positives when deciding there is or isn't a change.