Re: Naive DEFSYSTEM replacement

Yep.

? (apropos "COMPILE-FILE-IF-NEEDED")
? (lisp-implementation-type)
"Clozure Common Lisp"

Plus.  MK:DEFSYSTEM does most of the things ASDF and LW Defsystem do (I
will not go out on a limb and say *all*).
Also, MK:DEFSYSTEM knows how to load/compile ASDF systems (YMMV; code is
there to do the same for LW and other defsystems.)

Cheers

MA


On Sat, Jul 26, 2025 at 2:48 PM Rainer Joswig (as joswig at lisp dot de) <
[email protected]> wrote:

>
>
> Am 26.07.2025 um 11:11 schrieb Adam Weaver (as adam at cleversure dot com
> dot au) <[email protected]>:
>
> On Sat, 2025-07-26 at 08:35 +0200, joswig (as joswig at lisp dot de)
> wrote:
>
> I don't think what was provided is a DEFSYSTEM at all. It doesn't
> define a system, since there is nothing which would be a SYSTEM data
> structure and there are no top level operations over that data
> structure.
>
>
> Well no, I never said it was. I said, "huccome ASDF is so many
> thousands of lines of code when I can achieve *what-I-want* in 19 lines
> of code?"
>
>
> One can read the ASDF manual/documentation to get an overview of much of
> its functionality:
>
> ASDF - Another System Definition Facility <https://asdf.common-lisp.dev/>
> asdf.common-lisp.dev
> [image: favicon.ico] <https://asdf.common-lisp.dev/>
> <https://asdf.common-lisp.dev/>
>
> Here is an older overview:
> http://fare.tunes.org/files/asdf3/asdf3-2014.pdf
>
> It also runs in several very different operating systems and for a dozen
> different Lisp systems.
>
>
> Other responses have suggested that *what-I-want* is not the point of
> ASDF and other DEFSYSTEM forms at all.
>
> DEFCLASS defines a class, DEFUN defines a function, DEFTYPE defines a
> type...
>
> The macro actually creates code to directly execute a computed list
> of lispworks:compile-file-if-needed function calls.
> Since there are no dependencies managed, it always executes all of
> them.
>
> We can simply turn the macro into a function without loss of
> functionality.
> So far there is no need and no advantage in generating code via a
> macro
>
>
> Dudebro. Did you seriously just spend time reworking a proof-of-concept
> 10-minute nasty hack just because it didn't conform to your stylistic
> preferences?
>
>
> Understanding other people's code and their stylistic preferences might
> also help to improve coding skills.
>
> Wouldn't it have just been easier to answer the question that I
> actually asked? I mean, I put the question in its own ====== delimiters
> and everything!
>
>
> Rewriting code helps me to understand the original code.
>
> I can remember full compilation times of Portable Common LOOPS (PCL),
> a portable CLOS implementation, on some machine taking half an hour.
> COMPILE-SYSTEM would then minimize the compilation time, by only
> compiling/loading necessary code into a running system. One would
> back then avoid restarting Lisp and avoid doing full compilations of
> large systems.
> The idea of SYSTEMS was born when machines had 1 MIPS or less CPU
> speed.
>
>
> Ok. So this is more interesting. You're suggesting that the whole
> concept of Lisp systems was about *incremental* *recompilation*, not
> about dependency management.
>
>
> I'm suggesting that real dependency management was instrumental to keep
> compilation & load times as small as possible.
>
> But my 10-minute shonk-o-rama also handled this via
> COMPILE-FILE-IF-NEEDED rather than a straight COMPILE-FILE.
>
>
> Your code does only recompile&load changed files, but not the files which
> depend on them.
> ASDF and the LispWorks system tool make sure that all necessary updates
> are done.
>
> So again... what on Earth are ASDF and other DEFSYSTEM forms actually
> doing that requires 100x as much code?
>
>
> See the manual above.
>
> Obviously it's doing *something* ... what value am I not understanding
> here?
>
>
> Your code has no system registry, no data types for describing software
> systems, there are no modules, you have no operations, no planner, no
> portability layer, no support for pathnames, no versions, no dependency
> management, no support for different types of code (C code, compiled C
> code., documentation files, test code, ..), no support for building
> libraries, no support for inferred modules, no source registry, no caching,
> no error handling, no user interface, no subprocesses, etc.
>
> All your code does is compiling and loading a simple tree of files. But if
> that is all you want, that's okay for you. You don't need to use more
> capable tools, when you don't use their features. One can learn Common Lisp
> and its development tools piece by piece. Much of that is already provided
> by LispWorks and waits to be used, when you are ready for it.
>
> But for many applications compiling&loading might be enough. One's code
> may have only ten files, then just write a function which compiles and
> loads them.
> But some applications (or larger libraries) may have thousands of files
> spread of many dozen libraries.
>
> LispWorks has also IDE tools to browse systems and an IDE tool for
> browsing compilation conditions (-> warnings and errors).
>
>
>
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html
>
>
>

-- 
Marco Antoniotti, Professor, Director         tel. +39 - 02 64 48 79 01
DISCo, University of Milan-Bicocca U14 2043   http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

REGAINS: https://regains.disco.unimib.it/