Reconsider FASL => SYSLOAD design

[masinter]

We should reconsider the design that FASL files are always loaded SYSLOAD.
Why was this done? What would be the effect of chaging it so that LDFLG were preserved. Loadup may load files SYSLOAD but if you LOAD a DFASL it could leave the fileCOMS in place. While we're at it, let's fix LOADFNS to work with DFASL files even though there isn't a filemap.... To support GITFNS comparing compiled files, another value for LDFLG could be added which could store the compiled code from a .DFASL (or LCOM) under a different peopwery rhan the CCODE property -- perehaps in an ALIST which was indexed by the compiled filedate so that you could "load" in the compiled code from two different .DFASLs and compare their "fingerprints".

I think Herb's problem is that BASE64 is loaded from a FILES command inside a DFASL. The DFASL loader FASL:PROCESS-FILE rebinds a bunch of variables as if the LDFLG argument to LOAD was SYSLOAD. That includes one (FILEPKGFLG) that tells any files loaded underneath it to not be noticed by the file package. (See man SYSLOAD, also #2310).

If your WEB-EDITOR is also loaded from a FILES command in another DFASL, that might explain it. The coms are there as a variable, but the file itself isn't known.

On Oct 7, 2025, at 11:35 PM, Paolo Amoroso @.***> wrote:

pamoroso
left a comment
(#2301)
#2301 (comment)
Is the issue with BASE64.DFASL and FILELST related to discussion #2308 https://github.com/orgs/Interlisp/discussions/2308? WEB-EDITOR is a managed file.

—
Reply to this email directly, view it on GitHub #2301 (comment), or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJMTFGWVQFTZ7MS2KST3WSWB7AVCNFSM6AAAAACHXBNUCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNZZHEYDMMRZG4.
You are receiving this because you modified the open/close state.

Originally posted by @rmkaplan in #2301 (comment)

[rmkaplan]

There is a more basic question to ask about DFASLs: Why do we have that file format?

If the original or main motivation was for fast-loading, that seems to fit in the bucket with all of the other complex optimizations (speed, space) that don't matter any more.

It's a format that is generally incompatible with file-package tools like LOADDEF, GETDEF (for functions as well as other items). So it doesn't fit well with strategies for bridging between residential/loaded information and information on files.

If it isn't now-irrelevant speed, what benefit are we getting from maintaining the dfasl format and keeping track of which files are compiled which way?

What would happen if CL:COMPILE-FILE was changed so that it compiles everything in the same way, but stores the results on an LCOM formatted file?

[masinter]

Ron,

There are features of Common Lisp which are not supported by FAKECOMPILEFILE -- most notably lexical scoping; the "remove Interlisp comments" and several others. If it were possible to make the change you're proposing, it would have been done. The main feature that DFASL offers is Common Lisp compatibility. The "F" in "FASL" was from CLtL.

So getting rid of FASL format is a non-starter.

On the other hand it is quite feasible to make LOADFNS work for DFASLs. (GETDEF returns source and should not returned compiled).

A simple way to make LOADFNS work in DFASL files would be to change it so that if LDFLG is PROP that it saves the compiled code somewhere (e.g., on the property list ) on an ALIST indexed by the root filename and the filedate. If you LOADFNS of anything it will first check to see if the file/filedate has already been loaded and use the cached value instead.

[rmkaplan]

Why can't you use CL:COMPILE-FILE to do the compiles, but output to an lcom format file?

…

On Oct 12, 2025, at 2:43 PM, Larry Masinter ***@***.***> wrote: masinter left a comment (Interlisp/medley#2314) <#2314 (comment)> Ron, There are features of Common Lisp which are not supported by FAKECOMPILEFILE -- most notably lexical scoping; the "remove Interlisp comments" and several others. If it were possible to make the change you're proposing, it would have been done. The main feature that DFASL offers is Common Lisp compatibility. The "F" in "FASL" was from CLtL. So getting rid of FASL format is a non-starter. On the other hand it is quite feasible to make LOADFNS work for DFASLs. (GETDEF returns source and should not returned compiled). A simple way to make LOADFNS work in DFASL files would be to change it so that if LDFLG is PROP that it saves the compiled code somewhere (e.g., on the property list ) on an ALIST indexed by the root filename and the filedate. If you LOADFNS of anything it will first check to see if the file/filedate has already been loaded and use the cached value instead. — Reply to this email directly, view it on GitHub <#2314 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOOVKN2S3IWTVGZLEL3XLDP7AVCNFSM6AAAAACIUCQNA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJVGM4DQMRRHE>. You are receiving this because you were mentioned.