Re: Naive DEFSYSTEM replacement

Weeeeeellll.

HTML generation?

Shameless plug: https://gitlab.common-lisp.net/xhtmlambda/XHTMLambda and
https://xhtmlambda.common-lisp.dev/

Having said that, the main answers to your hack are that: (1) works for you
(not necessarily me, who is notorious for his very advanced NIH syndrome),
(2) it is LW only, and (3) it does not do what all the defsystems do.

The defsystems are big because the ANSI writers were stuck in the
"TOPS-ITS-Multics frame of mind", hence the evil and undespecified
pathnames (and the reader uppercasing behavior).  Since the defsystem (ASDF
and MK:DEFSYSTEM for sure) need to deal with the variety of the platforms
and implementations matrix they have a lot of boilerplate that just deals,
e.g., with... pathnames (*).  Just check what PATHNAME-DEVICE returns on
LW, Allegro and SBCL.

As a matter of fact, ASDF was born because MK:DEFSYSTEM had become pretty
unreadable, given the amount of conditionalization in the code (now it is
under control, but just barely).

So, by all means write what you feel works for you; we old geezers just
reminisce about the old days (some more than others - they are more
ancient) and can be obnoxious.  Remember: we are older and got more
insurance :)

Cheers

MA

(*) I have another shameless plug, but I will limit myself to one a day :)


On Sun, Jul 27, 2025 at 2:58 AM Adam Weaver (as adam at cleversure dot com
dot au) <[email protected]> wrote:

> On Sat, 2025-07-26 at 11:44 +0100, Tim Bradshaw wrote:
> > [You don't often get email from [email protected]. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Wow, I never thought I'd find myself writing a defence of ASDF!
> >
> > *It is not complicated*.  I mean, seriously:
> >
> > (defsystem "foo"
> >   :components
> >   ((:file "a")
> >    (:file "b"
> >     :depends-on ("a"))))
> >
>
> You've invented a strawman argument so you can argue with it.
> ASDF is "complicated" in the sense that it is thousands upon thousands
> of lines of code. Hell, even its maintainer recently said "I don't know
> what all of it is there for".
>
> ASDF is *not* complicated in the sense that its configuration format is
> complicated. Personally I think the ASDF:DEFSYSTEM form is fairly
> elegant.
>
> But even if I *did* have an issue with the configuration form (which I
> do not), all I'd have to do is write a macro-wrapper DSL, wouldn't I?
>
> > Is not, in fact complicated to use ASDF.  And in fact exhaustive
> > studies show that 98.3% of ASDF system declarations look like
> >
> > 1. People want to be able to do things to their systems other than
> > compile and load them.  For instance people might want to be able to
> > say 'run the tests for this system' and have ASDF know how to do that
> > for them.  Or 'Make a release for this system' which certainly
> > involves at least compiling and loading it, running all the tests,
> > copying the files of the system to some release directory and so on.
> > Or 'define where systems live so they can be found'.
> > You may not want to do those things, but ASDF was not written just
> > for you.
>
> Werd dogg. This is what I was *asking*. I think I asked it about four
> times? The question was "what the hell am I missing? I've been using
> ASDF as a compile-load-a-series-of-files-in-order tool, and then I
> don't touch ASDF again until I shut emacs down and need to start it up
> again. So what am I missing out of in ASDF facilities?"
>
> >
> > - you never plan on writing code of any complexity, especially code
> > which involves macros in nontrivial ways;
>
> Dunno. My "trivial" might be someone else' complicated?
>
> I mostly use macros for DSLs, like HTML generation, database interop,
> or simple WITH-STUFF binds.
>
> >
> > - or you want to end up living in a world of mud, where you spend
> > most of your time trying to work out exactly what series of
> > incantations you need to perform to recreate the state of the system
> > you had a few minutes ago.
> >
> > Trust me, I've lived in that world of mud, a world with sacred Lisp
> > images which nobody had any idea how to reproduce any more but on
> > which everything depended.  That world is not one you want to live
> > in.
>
> Yeah I can imagine that. Is that Robert Goldman was referring to when
> he said that ASDF is intended to keep the image "coherent"? Or words to
> that effect.
>
> Yeah, my use case is a lot simpler. I'm a solo developer working on
> software for my own use only (I'm an insurance broker by trade, and I
> need software to help my day job), so I don't have to worry so much
> about coherency or teams.
>
> Look, I gotta be honest. I thought I asked a pretty simple question,
> which was "what does ASDSF do for me that my nasty nasty nasty 19 line
> 10-minute hack doesn't do".
>
> And all I've had so far is:
>
> * Two attempts at rewriting the hack with some snobbery around how I
> should learn about that author's particular style. Mang, it was a hack,
> read the room.
>
> * One suggestion of an *alternate* build tool (which I like the look
> of!) with no answers to my questions.
>
> * One suggestion of writing a *better* build tool, in which the author
> even commented that it would NP-hard.
>
> * About three "RTFM Noob" shitposts.
>
> * A couple of comments about how I'm not understanding LW:DEFSYSTEM or
> ASDF:DEFSYSTEM. Well duh bruh! That *was*what*I*asked*.
>
> So I'm going to guess.
>
> No-one really knows why ASDF is thousands-upon-thousands of lines of
> code, but since it's a miniscule part of CL software development, no
> one really cares either.
>
> Ok, whatevs.
> Was that really hard to say?
>
> Anyway, thanks Tim. I'm going to go back to ASDF, because I do like its
> configuration file format. And although MK:DEFSYSTEM looks interesting
> too, ASDF2 is the one bundled with LW. And I'm wedded to LW.
>
> A
>
> _______________________________________________
> 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/