Re: Mysteries of unwind-protect

1) They were Lisp MACHINES meant to conquer the world : ). The rest is about making the money.

----------------------------------
From: Tim Bradshaw <[email protected]>
Subject: Re: Mysteries of unwind-protect
Date: Thu, 15 Jan 2026 17:59:59 +0000

"But seriously: may be I am alone in this but I rather prefer talking to humans, not fancy
autocomplete machines."
---------------------
------------------------------------
From: Pascal Costanza <[email protected]>
Subject: Re: Mysteries of unwind-protect
Date: Thu, 15 Jan 2026 22:33:00

"There is very little value in posting LLM answers in a public discussion forum, because anybody who
wants to rely on LLM answers already knows where to find them. I would rather not see them here
either."
-------


2) Before asking LLMs, I checked the problem in the CMUCL compiler with (DEBUG 0).

(defun ts-tim-unwind ()
  (declare (optimize speed (safety 0) (debug 0)))
  (let ((v (make-array 1 :element-type 'double-float :initial-element 0.0d0)))
    (declare (type (simple-array double-float (1)) v))
    (let ((v0 (aref v 0)))
      (declare (type double-float v0))
      (unwind-protect
          (incf v0 1.0D0)
        (setf (aref v 0) v0))))
  (values))

(COMPILE 'ts-tim-unwind)

; In: LAMBDA NIL

;   (LET (#)
;     (DECLARE #)
;     (UNWIND-PROTECT # #))
; Note: Doing float to pointer coercion (cost 13), for:
;     The first argument of MAKE-VALUE-CELL.
;
;   (INCF V0 1.0d0)
; --> LET*
; ==>
;   (SETQ V0 #:G12)
; Note: Doing float to pointer coercion (cost 13), for:
;     The second argument of VALUE-CELL-SET.
;

The compiler output shows float boxing via value cells, even with debugging disabled.


NEXT -> GEMINI COMMENTS.
'Does (DEBUG 0) solve it? NO.

This proves that the boxing isn't just a courtesy for the debugger. It is a structural requirement
of how the compiler implements unwind-protect. Even if you tell the compiler you don't care about
debugging, it still uses a "Value Cell".'


3) The reason for sharing LLM replies is not to replace humans, but to protect Lisp quality.

https://x.com/JFPuget/status/2012079551644316040?s=20
"(Un)expected outcome of the rise of AI coding, open source getting flooded with low quality PR
generated with AI. We've recently seen a significant increase in contributions generated entirely
by Al tools. While some of these pull requests are formally  correct, most suffer from incomplete or
misleading context, misunderstanding of the codebase, and little to no follow-up engagement  from
their authors.

@tldraw
This week we're going to begin automatically closing pull requests from external contributors.
I hate this, sorry".


4) We should discuss LLM replies to measure how much Lisp slop they produce, and how to avoid it.
This requires human expertise, especially within this highly regarded Lisp community.

One possible solution is an official LispREPL+LLM, for example provided by LispWorks.
A paid service: let's say $10 per month, 10 000 users → $100 000 income per month.

Contributors to this system could be paid by LispWorks, once revenue materializes.
10 contributors: Martin provided 20%, another person 10% of expertise etc. = 100%.

The bet is simple: quality will beat LLM slop, by adding Lisp symbolic reasoning.
It is somewhat like a “Lisp time machine” — except this time, it pays the bills.



Kind Regards,
Adrian W. Pasieka