That's Perl living up to its own motto, "there's more than one way to do
it". ;-)
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
PostScript is so little used nowadays, even Adobe has deleted all
the documentation from its website.
sigh, I know. I still call pdf postscript version 3.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Tue, 16 Jun 2026 23:53:07 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Mon, 15 Jun 2026 01:15:12 -0000 (UTC), Waldek Hebisch wrote:
On equvalent programs built from low-level operations 'sbcl'
routinely gets _much_ better performance than Python.
Is this with similar memory consumption?
sbcl has a new generation GC.
Is that a yes or a no?
"
SBCL also inherited some newer architectural features from CMUCL. The
most important is that on some architectures it has a generational
garbage collector ("GC"), which has various implications (mostly good)
for performance. These are discussed in another chapter, *note
Efficiency::.
"
For negotiations about weapons two parties need to find a
common definition of the concept of a "warhead". More can
be found in "What exactly is a warhead?" by Anna Hadley,
Sandia Report SAND98-1201, June 1998.
In 1819, a merchant refused to pay a fish product tax on whale
oil because a whale was not a fish. A court finally ruled
that a whale is a fish. Later, a law established that a whale
is not a fish. (According to D. Graham Burnett in "Trying
Leviathan: The Nineteenth-Century New York Court Case That
Put the Whale on Trial and Challenged the Order of Nature")
Really? That would be something I haven't encountered before. Can you
explain how such a disagreement comes about?
E.g. let's say you have
(defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3) (do-something-else c))))
let's say you call (my-foo "hello" "my" "world") and a GC happens during
the call to `do-something`:
- Is the content of `b` still reachable?
(AFAIK most languages don't specify it; ELisp will probably consider it
as reachable, Scheme and SML say it isn't)
- What about the content of `c`?
ram@zedat.fu-berlin.de (Stefan Ram) writes:
For negotiations about weapons two parties need to find a
common definition of the concept of a "warhead". More can
be found in "What exactly is a warhead?" by Anna Hadley,
Sandia Report SAND98-1201, June 1998.
you must be kidding. "I just got blown up!"; i need to know the name
of the device?
In 1819, a merchant refused to pay a fish product tax on whale
oil because a whale was not a fish. A court finally ruled
that a whale is a fish. Later, a law established that a whale
is not a fish. (According to D. Graham Burnett in "Trying
Leviathan: The Nineteenth-Century New York Court Case That
Put the Whale on Trial and Challenged the Order of Nature")
did you know that it is illegal to trap mice in NJ,USA. That means they
need to change the labeling on the mouse trap to something that make
people feel less guilty about their environmental needs.
Stefan Monnier <monnier@iro.umontreal.ca> writes:
AFAIK, there is no agreed upon meaning of "garbage collection" in this
respect: some people take it to include both "tracing GC" and "reference
counting", while others take it to mean only "tracing GC".
Always keep that in mind whenever you read or write "GC".
I'm pretty sure that 45 years ago we all agreed that "reference
counting" counted as a tool for "garbage collection". But language
changes, so perhaps that's no longer the case today. Seem like a loss
to me. (Similar to the way many people now claim that Lisp no longer
counts as a call-by-value language.)
Here also, there can be minor disagreements over what
"unreachable" means.
Really? That would be something I haven't encountered before. Can you >explain how such a disagreement comes about?
Here also, there can be minor disagreements over whatReally? That would be something I haven't encountered before. Can you
"unreachable" means.
explain how such a disagreement comes about?
E.g. let's say you have
(defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3) (do-something-else c))))
let's say you call (my-foo "hello" "my" "world") and a GC happens during
the call to `do-something`:
- Is the content of `b` still reachable?
(AFAIK most languages don't specify it; ELisp will probably consider it
as reachable, Scheme and SML say it isn't)
- What about the content of `c`?
=== Stefan
The definition of reachable used by GC is different from the that used
by compilers. Compiler texts generally refer to it as being "live" or "dead", but it is the same issue as "reachable" or "unreachable".
However, whatever was passed in as 'b' still exists in a surrounding
scope and should still be accessible.
[...](defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3) (do-something-else c))))
[...]- Is the content of `b` still reachable?
That's not a language issue but an implementation issue: 'b' and 'c'
both are locals in my-foo.
thread being titled "Resources to learn common lisp?"!), so I assumed
the word "reachable" meant what it normally means in a paper about
garbage collection: the objects reachable from the root set. Things the compiler might do to alter the root set aren't normally part of the discussion.
(defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3) (do-something-else c))))
let's say you call (my-foo "hello" "my" "world") and a GC happens during
the call to `do-something`:
- Is the content of `b` still reachable?
(AFAIK most languages don't specify it; ELisp will probably consider it
as reachable, Scheme and SML say it isn't)
- What about the content of `c`?
(defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3) (do-something-else c))))
let's say you call (my-foo "hello" "my" "world") and a GC happens during
the call to `do-something`:
- Is the content of `b` still reachable?
(AFAIK most languages don't specify it; ELisp will probably consider it
as reachable, Scheme and SML say it isn't)
- What about the content of `c`?
I am unclear why this is a problem.
Joerg Mertens <joerg-mertens@t-online.de> wrote or quoted:
Does Perl really have a garbage collector besides reference counting? >Reference counting is a form of garbage collection.
On Thu, 18 Jun 2026 01:06:00 -0000 (UTC), Lawrence DrCOOliveiro wrote:
On 17 Jun 2026 11:17:33 GMT, Stefan Ram wrote:At least the renowned reference "The Garbage Collection Handbook"
Reference counting is a form of garbage collection.
No, it is a form of *memory allocation management*.
rCLGarbagerCY is the term for rCLmemory that is unreachable, but still
unavailable for reallocationrCY.
Stop referring to AIs for this sort of thing, please.
(2nd ed.) by Jones has chapters
1 Introduction
2 Mark-sweep garbage collection
3 Mark-compact garbage collection
4 Copying garbage collection
5 Reference counting <===========
6 Comparing garbage collectors--- Synchronet 3.22a-Linux NewsLink 1.2
7 Allocation
8 Partitioning the heap
9 Generational garbage collection
A reference counted system would have looked at, *and written the reference counts of* all billion conses: about 250 times as many as the GC.
I also looked up Zorn's PhD thesis (about GC performance) from 1988:
https://www2.eecs.berkeley.edu/Pubs/TechRpts/1989/Archive/CSD-89-544.pdf
Unfortunately, reference counting has fundamental disadvantages.
First and foremost, reference counting algorithms do not reclaim
storage allocated in circular structures. Modifications to the
traditional algorithm have been suggested to overcome this
problem, but the performance of the modified algorithm is
unacceptably slow.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Lisp would be the same. WhatrCOs his name, Lisp guru Paul Graham, has
a blog online where he talks about working on an early dotcom
startup where the development language was Lisp. That gave them a
lot of productivity boosts. But the core part of the in-memory
database was implemented in C++, precisely where the garbage
collector could not get its sticky fingers on it.
Do you mean https://www.paulgraham.com/avg.html ?
And the stuff he says about Python now seems quaint.
4. Because we have about 2 gigs of static data we need rapid
access to, we use C++ code to memory-map huge files containing
pointerless C structs (of flights, fares, etc), and then access
these from Common Lisp using foreign data accesses.
Two points to that:
* Most of the reference-counter management would be happening in the
L1 or maybe L2 cache. This goes back to my point about
reference-counting mostly dealing with recently-used objects, while
GCs go back to faulting in lots of long-dead objects.
* Most modern dynamic languages have more sophisticated data
structures, which involve rather less pointer-chasing than
traditional Lisp lists.
* Most modern dynamic languages have more sophisticated data
structures, which involve rather less pointer-chasing than
traditional Lisp lists.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
4. Because we have about 2 gigs of static data we need rapid
access to, we use C++ code to memory-map huge files containing
pointerless C structs (of flights, fares, etc), and then access
these from Common Lisp using foreign data accesses.
This sounds like there was no substantial C++ code other than an mmap
call. As it was a chunk of static pointer-free data being mapped, there wasn't any allocation going on.
Anyway it's perfectly normal to do stuff like that.
Are you seriously saying reference counting could have somehow
appeared instead?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Perl was probably the pioneer here. Implementations use garbage
collection simply because itrCOs so much easier to do, nothing more.
Have you actually implemented both? I feel like a bunch of stuff you're saying come from inexperience.
If of any interest, the current "big" Python implementation is
CPython and it uses reference counting.
MicroPython, a smaller Python version for microcontrollers, uses GC.
Lua, considered a smaller-footprint and more embeddable language
than Python, also uses GC.
MicroPython ran on MCU's with as little as 16KB of ram (BBC
Micro:bit v1) though that was very cramped. It's reasonably usable
with 32KB. I don't think CPython could run at all on those machines.
I'd be interested to know why CPython uses RC.
Slightly related, do you even use Lisp?
I think your picture of how Lisp programs use memory is also
unrealistic.
Can you do topic analysis of text?
On Thu, 18 Jun 2026 01:06:00 -0000 (UTC), Lawrence DrCOOliveiro wrote:
On 17 Jun 2026 11:17:33 GMT, Stefan Ram wrote:
Reference counting is a form of garbage collection.
No, it is a form of *memory allocation management*.
AFAIK, there is no agreed upon meaning of "garbage collection" in
this respect: some people take it to include both "tracing GC" and
"reference counting", while others take it to mean only "tracing
GC". Always keep that in mind whenever you read or write "GC".
rCLGarbagerCY is the term for rCLmemory that is unreachable, but still
unavailable for reallocationrCY.
Here also, there can be minor disagreements over what "unreachable"
means.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Caches are all about speeding up repeated accesses to the same
data.
No I don't think so.
Cache is fast memory.
Donald Knuth had a subsection 2.3.5 "Lists and Garbage Collection"
in his 1968 "The Art of Computer Programming" where he mentions
reference counting. So we might think that to him it /is/ a form
of garbage collection as it is mentioned under this heading.
However, he chose a wording that seems to say, to him, it is /not/
garbage collection:
|Two principal methods have been suggested for maintaining the
|available space list: the use of /reference counters/, and /garbage |collection/.
. Interesting comma there!
Here also, there can be minor disagreements over what
"unreachable" means.
Really? That would be something I haven't encountered before. Can you
explain how such a disagreement comes about?
E.g. let's say you have
(defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3) (do-something-else c))))
let's say you call (my-foo "hello" "my" "world") and a GC happens during
the call to `do-something`:
- Is the content of `b` still reachable?
(AFAIK most languages don't specify it; ELisp will probably consider it
as reachable, Scheme and SML say it isn't)
- What about the content of `c`?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Tue, 16 Jun 2026 12:33:19 -0000 (UTC), tfb wrote:
A reference counted system would have looked at, *and written the
reference counts of* all billion conses: about 250 times as many
as the GC.
* Most modern dynamic languages have more sophisticated data
structures, which involve rather less pointer-chasing than
traditional Lisp lists.
DEFSTRUCT, cough.
Admit that the Lisp garbage collector cannot scale to dealing with
large amounts of data?
You say that facetiously, but that is in fact what people are doing
nowadays, when they load huge amounts of data with NumPy, Pandas etc
for analysis with Python code.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
On Tue, 16 Jun 2026 12:33:19 -0000 (UTC), tfb wrote:
A reference counted system would have looked at, *and written the
reference counts of* all billion conses: about 250 times as many
as the GC.
Two points to that:
* Most of the reference-counter management would be happening in
the L1 or maybe L2 cache. This goes back to my point about
reference-counting mostly dealing with recently-used objects,
while GCs go back to faulting in lots of long-dead objects.
How exactly does the GC find these 'long dead objects' to reference?
Oh, wait, it doesn't: you just have no fucking idea how a copying GC
(or indeed a mark&sweep GC) works.
* Most modern dynamic languages have more sophisticated data
structures, which involve rather less pointer-chasing than
traditional Lisp lists.
I see. Stuctures which don't refer to other structures are not a
problem. Hello? Yes, we know that.
You clearly did not understand what I wrote. Hint: re-read part that
you snipped.
I donrCOt claim to be smart enough to implement such things. My
experience comes from using implementations created by people much
smarter than I am.
But guess what: I think Python has become more popular for embedded
use than Lua.
<https://docs.micropython.org/en/latest/develop/memorymgt.html>. Note
how they need to offer a separate rCLtracked allocationrCY API for use
from C code?
Somehow their rCLgarbage collectionrCY scheme seems to have
some interesting limitations, no doubt for speed and efficiency.
I'd be interested to know why CPython uses RC.Because of the reasons werCOve been discussing. You still refuse to
accept that there might be a point to that?
LetrCOs just say, rCLLisprCY and rCLhigh performancerCY were never terms that commonly went together. Whereas nowadays rCLPythonrCY and rCLhigh performancerCY are indeed commonly uttered in the same sentence ...
If a GC is not finding long-dead objects to reclaim, then what exactly
is it doing? IsnrCOt that exactly what the rCLgarbagerCY is, that it is supposed to rCLcollectrCY?
I see. Stuctures which don't refer to other structures are not aSo why didnrCOt you mention it? Why were you talking about rCLconsesrCY at all?
problem. Hello? Yes, we know that.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
That memory has to be marked as free for reallocation somehow. That
will be where the cache-thrashing comes in, no escaping it.
It does not. Once the live data has been copied from the area of memory it is free, and new allocation may take place there. You really need to think about how a copying GC works.
I wish we had a way for a running Python image to snapshot itself, like traditional Lisps did, maybe using something based on CRIU. Emacs Lisp initially did this with a Unix hack that it called unexec(), that
eventually became too hard to maintain and was replaced with something
more ad hoc. But it seems deficient of OS's to not support anything
like that.
So, given a binary, how do you know which source version was used to
produce that?
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
How exactly does the GC find these 'long dead objects' to reference? Oh, wait, it doesn't: you just have no fucking idea how a copying GC (or indeed
a mark&sweep GC) works.
* Most modern dynamic languages have more sophisticated data
structures, which involve rather less pointer-chasing than
traditional Lisp lists.
I actually used intel's excellent Vtune product to test python with and without LTO. So yes it is possible; if you can get Vtune to work.
* Most modern dynamic languages have more sophisticated data
structures, which involve rather less pointer-chasing than
traditional Lisp lists.
you might want to rethink that. all lists are pointers.
Does any program actually free or return memory to the kernel before
it exits?
Ironically, Python typically uses dictionaries for that, looking up
all the keys at runtime.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
So, given a binary, how do you know which source version was used
to produce that?
try using the --version option at the cmd line.
tfb <no_email@invalid.invalid> writes:
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
That memory has to be marked as free for reallocation somehow. That
will be where the cache-thrashing comes in, no escaping it.
It does not. Once the live data has been copied from the area of memory it >> is free, and new allocation may take place there. You really need to think >> about how a copying GC works.
Does any program actually free or return memory to the kernel before it exits?
If a GC is not finding long-dead objects to reclaim, then what exactly
is it doing? IsnrCOt that exactly what the rCLgarbagerCY is, that it is supposed to rCLcollectrCY?
Or did your term rCLconsesrCY not refer to what CONS does?
Does any program actually free or return memory to the kernel beforeAre you asking if there are programs free of memory leaks?
it exits?
Ironically, Python typically uses dictionaries for that, looking upRemember that Python strings are immutable.
all the keys at runtime.
Does any program actually free or return memory to the kernel before it exits?
I mean a data structure in Python will typically be a class
instance, so you'd say x.foo, x.bar, and so on, to get at the
members. Each of those accesses is a dictionary lookup using the
keys "foo", "bar", etc., in a dictionary that lives in the instance.
Lisp can often optimize this so that the instance is more like a C
struct.
can't you just leave them in oldspace?
you might want to rethink that. all lists are pointers.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Look at toolkits like NumPy, commonly used to do heavy-duty... So
you see, the performance bottleneck does not lie in PythonrCOs memory
management system.
Exactly, those large numeric arrays don't contain any pointers that
need management at finer granularity than the array itself.
The point is that sometimes you need to write code including low
level parts. In many situations that leads to a lot of smallish
pieces of data that need to be handled efficiently.
94GB total allocation ...
I think the conception is of Lisp representing a 1000 element data
structure as 1000 linked cons nodes instead of as a defstruct.
Ironically, Python typically uses dictionaries for that, looking up all
the keys at runtime.
Lisp can often optimize this so that the instance is more like a C
struct.
Cons nodes obviously have to be GC'd. But you're mistaken in believing
that most of the heap objects in a running Lisp program consists of cons nodes. Thus the mention of DEFSTRUCT. Or for that matter, arrays.
Python uses them, and Lisp has them too.
are immediate in Python then a list of them would not have any pointers in >it.
I don't see any clear advantages. One early motivation was prompt finalization when stuff goes out of scope, but later the "with"
statement was added, giving something like RAII.
Python and high performance amount to using Python as a scripting
wrapper around C libraries, or even CUDA libraries.
It would be allowed by the Python Language Specification
for an implementation to store small integers directly in
a list rather than storing pointers to integer objects.
The standard implementation CPython does not do this, but you can
import the built-in array module or the third-party numpy library
if you need a data structure that bypasses PyObject pointers
and stores integers directly in a contiguous block of memory.
On Thu, 18 Jun 2026 09:32:12 -0000 (UTC), tfb wrote:
94GB total allocation ...
Peak?
Lisp is not exactly there, but not far: rather
typical figure for sbcl is half of speed of comparable C. It is
worse when dealing with multidimensional arrays or if C compiler
manages to usefuly autovectorize the code. OTOH memory access
time may effectively decrease differences.
But you saying that CPython doesn't have fixnums? So, say '1 + 3' is
consing two integers? Does it at least intern small integers (and how
many, if so)? There are rumours the answer is 'integers from -5 to 256'? >Certainly 1000 doesn't seem to be interned (id changes).
Actually I think I knew this once upon a time. It was probably one of the >things I joined the foreign legion to forget. Obviously it worked.
As tools, they can be very efficient, but it's not because they run
Perl or Python code efficiently: it's because they don't spend much
time running actual Perl and Python code (instead they spend most of
their time running code written in other languages, like C).
tfb <tfb@work.it.out> wrote or quoted:
When you use "1 + 3" literally, modern CPython is generating
The answer we came to was that the only place you could use Python was as a >scripting language to put together blobs of code written in languages with >good performance. We gave up & I left a while later.
Yeah, I meant 'programs which do things to small integers.
Yeah, I meant 'programs which do things to small integers. If you write,
say
def ids(x):
y = 1000
return (id(x), id(y), x is y)
then ids(1000) returns a tuple with two different values, and False.
Nuno Silva <nunojsilva@invalid.invalid> writes:
Does any program actually free or return memory to the kernel beforeAre you asking if there are programs free of memory leaks?
it exits?
I think the picture is as follows. The program runs for a while
building up some data that consumes a lot of memory, so the process data segment gets big. Then the program finishes up with that data, the
memory that it used gets GC'd, and the program goes on to the next
thing. But the process still owns the memory pages that were occupied
by the now GC'd data. To release the memory back to the OS, in Linux
you'd use the munmap() system call if I'm not mistaken. In the very old days, Emacs never did that, so its process memory could only get larger,
not smaller. That got fixed quite a few years ago. In ancient Unix you could release memory by calling sbrk() with a negative arg and maybe
that's also still possible.
For any of this to work usefully, the GC will usually have to rearrange (compact) the live objects, to get contiguous pages to release to the
OS. I don't see how a non-moving GC can do that except in some special cases. I don't know how or whether CPython handles it.
(2) Systems which do have copying GCs which want to talk to C have an entertaining time. I don't know what SBCL does, but LW lets you allocate (some) things so the GC won't move them, or won't move them in a dynamic extent.
On Sat, 27 Jun 2026 20:25:42 -0000 (UTC), tfb wrote:
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
How exactly does the GC find these 'long dead objects' to reference?
Oh, wait, it doesn't: you just have no fucking idea how a copying GC
(or indeed a mark&sweep GC) works.
If a GC is not finding long-dead objects to reclaim, then what exactly
is it doing? IsnrCOt that exactly what the rCLgarbagerCY is, that it is >supposed to rCLcollectrCY?
__slots__?
Jones, Hosking & Moss, "The Garbage Collection Handbook: The Art of
Automatic Memory Management", 1st ed., 2012, CRC Press, ISBN
978-1420082791
Look at the Linux kernel as an example, and you will see it makes
heavy use of reference-counting, not garbage collection, to manage kernel-internal objects.... And then thererCOs filesystems. POSIX filesystems depend crucially on reference-counting to decide when
files need to be deleted. No garbage collection there either.
Why not?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Look at the Linux kernel as an example, and you will see it makes
heavy use of reference-counting, not garbage collection, to manage
kernel-internal objects.... And then thererCOs filesystems. POSIX
filesystems depend crucially on reference-counting to decide when
files need to be deleted. No garbage collection there either.
Why not?
Neither of those is a Lisp implementation.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
__slots__?
I'll have to study the implementation: as I remember, __slots__
saves memory, but it's unclear to me how well it helps with speed.
steve g <Sgonedes1977@gmail.com> writes:
I actually used intel's excellent Vtune product to test python with and
without LTO. So yes it is possible; if you can get Vtune to work.
I don't see how LTO relates to saving images. Am I missing something?
E.g. let's say you have
(defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3) (do-something-else c))))
This is why the traditional rCLparenthesis pileuprCY layout for Lisp
code is not helpful for figuring out whatrCOs going on. LetrCOs try reformatting that for clarity, shall we:
(defun my-foo (a b c)
(let ((x (concat a b)))
(do-something x a)
(if (< (length x) 3)
(do-something-else c)
) ; if
) ; let
) ; my-foo
- Is the content of `b` still reachable?Does it make a difference to the correctness of the code?
(AFAIK most languages don't specify it; ELisp will probably consider it
as reachable, Scheme and SML say it isn't)
- What about the content of `c`?Same question applies.
steve g <Sgonedes1977@gmail.com> writes:
Does any program actually free or return memory to the kernel before
it exits?
SBCL supposedly does this. Emacs Lisp does it but it uses a mark-sweep
GC that I think compacts only certain data types. I've seen the size of
a running Firefox browser both grow and shrink, but I don't know what
kind of allocator is making that happen.
On Sun, 28 Jun 2026 22:42:40 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
So, given a binary, how do you know which source version was used
to produce that?
try using the --version option at the cmd line.
That can print any number it likes. How do you verify the number if
prints actually means something?
Are you asking if there are programs free of memory leaks?
Nuno Silva <nunojsilva@invalid.invalid> writes:
Does any program actually free or return memory to the kernel beforeAre you asking if there are programs free of memory leaks?
it exits?
I think the picture is as follows. The program runs for a while
building up some data that consumes a lot of memory, so the process data segment gets big.
Then the program finishes up with that data, the
memory that it used gets GC'd, and the program goes on to the next
thing. But the process still owns the memory pages that were occupied
by the now GC'd data. To release the memory back to the OS, in Linux
you'd use the munmap() system call if I'm not mistaken. In the very old days, Emacs never did that, so its process memory could only get larger,
not smaller. That got fixed quite a few years ago. In ancient Unix you could release memory by calling sbrk() with a negative arg and maybe
that's also still possible.
For any of this to work usefully, the GC will usually have to rearrange (compact) the live objects, to get contiguous pages to release to the
OS.
GvR himself said they were introduced for efficiency reasons. The contribution to code safety was an unintended side-effect.
Thus, every slot attribute is actually a descriptor object that knows
how to set/get each attribute using an array index.
Neither is Python [a Lisp].
So why do you look down on PythonrCOs use of reference-counting?
I do not understand what you mean by an image?
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
It would be allowed by the Python Language Specification
for an implementation to store small integers directly in
a list rather than storing pointers to integer objects.
The standard implementation CPython does not do this, but you can
import the built-in array module or the third-party numpy library
if you need a data structure that bypasses PyObject pointers
and stores integers directly in a contiguous block of memory.
Yes, I know about NumPy: I used it ... a lot ... a long time ago.
But you saying that CPython doesn't have fixnums? So, say '1 + 3' is
consing two integers? Does it at least intern small integers (and how
many, if so)? There are rumours the answer is 'integers from -5 to 256'? Certainly 1000 doesn't seem to be interned (id changes).
Actually I think I knew this once upon a time. It was probably one of the things I joined the foreign legion to forget. Obviously it worked.
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
tfb <tfb@work.it.out> wrote or quoted:
When you use "1 + 3" literally, modern CPython is generating
Obviously this is just the same as using eq for numbers being a bad idea in CL, and Lisps in general don't have to have fixnums. CL does, but nothing says what they mean.
Waldek Hebisch <antispam@fricas.org> wrote:
Lisp is not exactly there, but not far: rather
typical figure for sbcl is half of speed of comparable C. It is
worse when dealing with multidimensional arrays or if C compiler
manages to usefuly autovectorize the code. OTOH memory access
time may effectively decrease differences.
FWIW for float-array intensive code SBCL is about 80% of C (specifically
the LLVM-based C compiler that ships with macOS and a fairly recent SBCL). Obviously C will do better if the compiler can vectorize things. But then
so would SBCL if its compiler could.
I should run these benchmarks again.
Looks like you missed this part of my message:
As tools, they can be very efficient, but it's not because they run
Perl or Python code efficiently: it's because they don't spend much
time running actual Perl and Python code (instead they spend most of
their time running code written in other languages, like C).
When I look at current GNU Emacs sources the approach seems to be much the same; mmap() based allocation for buffer text, malloc() based allocation for other Lisp objects, special handling for dumped data. Glibc malloc() will sometimes release memory back to the OS, but it doesnrCOt for the default (sbrk()-sourced) heap. I donrCOt believe that GNU Emacs releases GCed data for
non-buffer Lisp objects routinely.
But you saying that CPython doesn't have fixnums?
George Neuner <gneuner2@comcast.net> writes:
Jones, Hosking & Moss, "The Garbage Collection Handbook: The Art of
Automatic Memory Management", 1st ed., 2012, CRC Press, ISBN
978-1420082791
This has a 2nd edition now: https://www.gchandbook.org/editions.html
If you leak memory, or file descriptors, etc. you'll figure it out eventually.
Nuno Silva <nunojsilva@invalid.invalid> writes:
Does any program actually free or return memory to the kernel beforeAre you asking if there are programs free of memory leaks?
it exits?
I think the picture is as follows. The program runs for a while
building up some data that consumes a lot of memory, so the process data segment gets big. Then the program finishes up with that data, the
memory that it used gets GC'd, and the program goes on to the next
thing. But the process still owns the memory pages that were occupied
by the now GC'd data. To release the memory back to the OS, in Linux
you'd use the munmap() system call if I'm not mistaken. In the very old days, Emacs never did that, so its process memory could only get larger,
not smaller. That got fixed quite a few years ago. In ancient Unix you could release memory by calling sbrk() with a negative arg and maybe
that's also still possible.
For any of this to work usefully, the GC will usually have to rearrange (compact) the live objects, to get contiguous pages to release to the
OS. I don't see how a non-moving GC can do that except in some special cases. I don't know how or whether CPython handles it.
I think the picture is as follows. The program runs for a while
building up some data that consumes a lot of memory, so the process data segment gets big. Then the program finishes up with that data, the
memory that it used gets GC'd, and the program goes on to the next
thing. But the process still owns the memory pages that were occupied
by the now GC'd data. To release the memory back to the OS, in Linux
you'd use the munmap() system call if I'm not mistaken. In the very old days, Emacs never did that, so its process memory could only get larger,
not smaller. That got fixed quite a few years ago. In ancient Unix you could release memory by calling sbrk() with a negative arg and maybe
that's also still possible.
For any of this to work usefully, the GC will usually have to rearrange (compact) the live objects, to get contiguous pages to release to the
OS. I don't see how a non-moving GC can do that except in some special cases. I don't know how or whether CPython handles it.
here's someone else who discovered it recently https://blog.nirbheek.in/2026/05/an-esoteric-type-of-memory-leak.html
Yup. Beside buffer text where we may use `mmap`, memory is nabaged in
to of `malloc/free` and nowadays most `malloc` libraries appear to
tfb <tfb@work.it.out> writes:
But you saying that CPython doesn't have fixnums?All CPython integers are boxed, but small ones (-5 through +250 or
something like that) are pre-allocated. Sounds awful but I think some
Lisps also have done that.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
On Thu, 18 Jun 2026 09:32:12 -0000 (UTC), tfb wrote:
94GB total allocation ...
Peak?
Total. ... the whole purpose is to show how well copying GCs deal
with ephemeral allocation.
Lispers find the first form just as readable (if not more), by paying attention to indentation, IOW, exactly like Pythoners do.
Does it make a difference to the correctness of the code?
Definitely, because it can change the algorithmic complexity in
terms of space usage, so it can affect whether a programs runs in
constant space or not, for example.
... I don't know of any language or implementation which guarantees
it ...
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Sun, 28 Jun 2026 22:42:40 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
So, given a binary, how do you know which source version was used
to produce that?
try using the --version option at the cmd line.
That can print any number it likes. How do you verify the number if
prints actually means something?
by reading the binary or the assembler. but yes a computer program
may print something inaccurately. this why most people use a
signature file. I think that just checking the md5 is sufficient.
All CPython integers are boxed, but small ones (-5 through +250 or
something like that) are pre-allocated. Sounds awful but I think
some Lisps also have done that.
in SBCL
MOST-POSITIVE-FIXNUM = 4611686018427387903
I think that is around a 4 megabyte number.
Obviously this is just the same as using eq for numbers being a bad
idea in CL ...
In CPython, you actually can do awful things to a small integer.
Bignums are more of a pain in the ass than anything.
I think this behavior is not specified. In fact, today,
def ids(x):
y = 10000000000
return (id(x), id(y), x is y)
print( ids( 10000000000 ))
prints the same number twice and "True".
Combined with multiple inheritance, it allows you to subclass
in useful ways from built-in types like str and int.
print(x.foo) # crashes
On Mon, 29 Jun 2026 19:00:35 -0400, Stefan Monnier wrote:
Lispers find the first form just as readable (if not more), by paying
attention to indentation, IOW, exactly like Pythoners do.
I feel the indentation dependence is a mistake in the design of
Python. GvR disagrees, saying that it makes it easier for beginners.
I think thererCOs something in the rCLZen of PythonrCY that says rCLflat is better than nestedrCY. But Python supports rCLnestedrCY, and I use it heavily, as a very natural style. And then I add rCL#endrCY comment lines
to provide convenient navigation points, because things can get very confusing otherwise.
And I have custom Emacs commands to quickly jump
between lines with matching indentation, which is convenient for
hopping between the beginning of a compound statement and its
corresponding rCL#endrCY line.
If it's about "easier for beginners", I'd think they'd have addressed
the inconsistency where CPython, by doing automatic indentation or what
it was behaves differently when interactive, instead of being 1:1
between parsing code from a file and pasted code.
In the interactive CPython shell, one needs to add a blank line:
On 2 Jul 2026 09:24:13 GMT, Stefan Ram wrote:
In the interactive CPython shell, one needs to add a blank line:
But not in Jupyter, which is just as interactive -- if not more so.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
If a GC is not finding long-dead objects to reclaim, then what
exactly is it doing? IsnrCOt that exactly what the rCLgarbagerCY is, that
it is supposed to rCLcollectrCY?
Like I said: you do not understand, at all, how a copying GC works.
class A(int): pass
x = A(3)
x.foo = 8
x += 5
print(x.foo) # [raises AttributeError: ...]
ThatrCOs not about correctness, thatrCOs an efficiency issue. So thatrCOs a rCLnorCY, then.Does it make a difference to the correctness of the code?Definitely, because it can change the algorithmic complexity in
terms of space usage, so it can affect whether a programs runs in
constant space or not, for example.
that shows why reference-counting can be a worthwhile option,
doesnrCOt it?
class A(int): pass
x = A(3)
x.foo = 8
x += 5
print(x.foo) # crashes
Anyway, last I heard, OOP was a 1990s thing that didn't work out.
A copying GC doesn't find dead objects to reclaim them. It copies
the live objects to a new heap (contiguous chunk of memory) and then
releases the entire old heap in a single swoop. So if there are 15
live objects and a million dead ones, the GC spends no time dealing
with the individual dead ones.
Also, in Lisp jargon, "consing" sometimes informally refers to
allocating any type of memory object, not just cons nodes.
(I actually think `+=` is a bit of a hazard for newbie Python
programmers.)
There are plenty of situations where reference counting can be a
worthwhile option, of course. Nobody claimed otherwise here, AFAIK.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Admit that the Lisp garbage collector cannot scale to dealing with
large amounts of data?
It's not a scaling issue in the slightest.
You say that facetiously, but that is in fact what people are doing
nowadays, when they load huge amounts of data with NumPy, Pandas
etc for analysis with Python code.
NumPy and friends keep their data away from the CPython reference
counting system the same way mmap keeps the mapped data away from a
Lisp GC.
George Neuner <gneuner2@comcast.net> writes:
Jones, Hosking & Moss, "The Garbage Collection Handbook: The Art
of Automatic Memory Management", 1st ed., 2012, CRC Press, ISBN
978-1420082791
This has a 2nd edition now: https://www.gchandbook.org/editions.html
Think of NumPy returning an array of floats: each float has to be
allocated as a Python object.
When your program runs out of memory that becomes a correctness
issue.
On 2026-07-02, Lawrence DrCOOliveiro wrote:
On 2 Jul 2026 09:24:13 GMT, Stefan Ram wrote:
In the interactive CPython shell, one needs to add a blank line:
But not in Jupyter, which is just as interactive -- if not more so.
Yes, but this was about the comment that Python's indentation is "easier
for beginners" (which you attributed to Guido van Rossum?).
On Thu, 02 Jul 2026 18:22:50 -0400, Stefan Monnier wrote:
There are plenty of situations where reference counting can be a
worthwhile option, of course. Nobody claimed otherwise here, AFAIK.
Quite a few are insisting that garbage collection is somehow superior >overall.
If itrCOs so good, why donrCOt OS kernels use it?
On Fri, 03 Jul 2026 00:34:38 +0100, Nuno Silva
<nunojsilva@invalid.invalid> wrote:
On 2026-07-02, Lawrence DrCOOliveiro wrote:
On 2 Jul 2026 09:24:13 GMT, Stefan Ram wrote:
In the interactive CPython shell, one needs to add a blank line:
But not in Jupyter, which is just as interactive -- if not more so.
Yes, but this was about the comment that Python's indentation is "easier >>for beginners" (which you attributed to Guido van Rossum?).
I'm not aware that von Rossum actually said indentation made it
"easier for beginners" ... but he definitely did say that use of
indentation made code more readable.
from "Open heart with Guido Van Rosuum" https://impythonist.wordpress.com/2014/02/16/open-heart-with-guido-van-rosuuma-lost-interview-of-python-creator-part2/
|| The choice of indentation for grouping was not a novel concept
|| in Python; I inherited this from ABC, but it also occurred in
|| occam, an older language. I don't know if the ABC authors got
|| the idea from occam, or invented it independently, or if there
|| was a common ancestor. Of course, I could have chose not to
|| follow ABCrCOs lead, as I did in other areas (e.g., ABC used
|| uppercase for language keywords and procedure names, an idea
|| I did not copy), but I had come to like the feature quite a
|| bit while using ABC, as it seemed to do away with a certain
|| type of pointless debate common amongst C users at the time,
|| about where to place the curly braces. I also was well aware
|| that readable code uses indentation voluntarily anyway to
|| indicate grouping, and I had come across subtle bugs in code
|| where the indentation disagreed with the syntactic grouping
|| using curly bracesrCothe programmer and any reviewers had
|| assumed that the indentation matched the grouping and
|| therefore not noticed the bug. Again, a long debugging
|| session taught a valuable lesson.
YMMV. I /hate/ the idea of indentation being signicant.--
On Thu, 02 Jul 2026 18:22:50 -0400, Stefan Monnier wrote:
There are plenty of situations where reference counting can be a
worthwhile option, of course. Nobody claimed otherwise here, AFAIK.
Quite a few are insisting that garbage collection is somehow superior overall.
If itrCOs so good, why donrCOt OS kernels use it?
On Sun, 28 Jun 2026 16:36:03 -0700, Paul Rubin wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Admit that the Lisp garbage collector cannot scale to dealing with
large amounts of data?
It's not a scaling issue in the slightest.
Large amounts of data => canrCOt cope.
What would you call it, then?
but: this doesn't steer clear of the tabs v. spaces debate, and I
think one might even argue it makes *that* debate more visible in the
Python world?
from "Open heart with Guido Van Rosuum" https://impythonist.wordpress.com/2014/02/16/open-heart-with-guido-van-rosuuma-lost-interview-of-python-creator-part2/
|| The choice of indentation for grouping was not a novel concept
|| in Python; I inherited this from ABC, but it also occurred in
|| occam, an older language.
Python with braces. Because Python is awesome, but whitespace is awful.
All CPython integers are boxed, but small ones (-5 through +250 or
something like that) are pre-allocated. Sounds awful but I think some
Lisps also have done that.
I think Python doesn't really have a tabs-vs-spaces debate since the
userbase is solidly convinced (indoctrinated?) that "tabs bad, spaces
good". Tabs vs spaces was a 1980s thing anyway.
On Thu, 02 Jul 2026 13:41:43 -0400, Stefan Monnier wrote:
When your program runs out of memory that becomes a correctnessSo why doesnrCOt the language spec resolve the ambiguity, then?
issue.
On Thu, 02 Jul 2026 18:22:50 -0400, Stefan Monnier wrote:
There are plenty of situations where reference counting can be aQuite a few are insisting that garbage collection is somehow superior overall.
worthwhile option, of course. Nobody claimed otherwise here, AFAIK.
For example, PDP-10 MacLisp....
So why doesnrCOt the language spec resolve the ambiguity, then?Probably for the same reason most language "specifications" don't
deserve this name
Lawrence DrCOOliveiro [2026-07-03 04:04:00] wrote:
Quite a few are insisting that garbage collection is somehow
superior overall.
I haven't seen such a claim being made here.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
So why do you look down on PythonrCOs use of reference-counting?
Look at the decades of anguish CPython has suffered over its GIL.
I simply don't understand the refcounting fanboying taking place
here.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
Think of NumPy returning an array of floats: each float has to be
allocated as a Python object.
Numpy float arrays don't work like that at all.
"Although some people have initial resistance to the ( indentation as
block structure | parentheses) most come to ( accept | deeply
appreciate ) them."
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
But guess what: I think Python has become more popular for embedded
use than Lua.
Lua is a somewhat weird language and people may prefer Python due to familiarity.
CPython is a pain to embed though.
One early motivation was prompt finalization when stuff goes out of
scope, but later the "with" statement was added, giving something
like RAII.
I don't see any clear advantages.
I think Python doesn't really have a tabs-vs-spaces debate since the
userbase is solidly convinced (indoctrinated?) that "tabs bad,
spaces good".
Most programming languages are workable unless you are too hung up
about perceived flaws.
Tracing GCs seem to be popular among language implementors, even though they're non-trivial to implement (and a major PITA to debug),
so they do seem to provide good value "overall". Tho maybe it's just implementors reproducing blindly what previous implementors did.
I've debugged refcounting errors in Python extensions and other
systems too, and that's not fun either.
On Sun, 28 Jun 2026 16:41:13 -0700, Paul Rubin wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
But guess what: I think Python has become more popular for embedded
use than Lua.
Lua is a somewhat weird language and people may prefer Python due to
familiarity.
That wasnrCOt so true when Lua first came out. Somehow Python managed to overtake it.
CPython is a pain to embed though.
I will say, I think Lua is more popular in proprietary apps (I think
Adobe uses it, also some game engines). CPython is particularly well-supported among open-source content-creation apps.
My favourite example is Blender <https://docs.blender.org/api/5.1/>.
Just look at the depth of that -- the entire contents of the loaded
Blender document are exposed as Python objects.
One early motivation was prompt finalization when stuff goes out of
scope, but later the "with" statement was added, giving something
like RAII.
The rCLwithrCY statement is more about restoration of state -- see also rCLtry/finallyrCY.
I don't see any clear advantages.
Worth comparing garbage-collected Python implementations. For example, someone else said that Java had a particularly good GC. Jython is, or
was, a Python implementation on top of the JVM. That should have shown
some clear performance advantages, shouldnrCOt it? Yet it was never
popular.
Microsoft also had a go, with IronPython built on top of its DotNet
runtime. Again, after several years of trying to promote it, it could
never work up enough interest, so eventually the project was
abandoned.
If a company with the marketing clout of Microsoft cannot make a
success of a garbage-collected alternative to CPython, then the idea
must really be bad ...
There is a way to write the code to make this a bit easier <https://gitlab.com/ldo/a_structured_discipline_of_programming/>.
I do find the CPython API to be unpleasant, compared to the FFI's of
other languages that don't make you manage refcounts.
Lawrence DrCOOliveiro [2026-07-03 05:45:01] wrote:
So why doesnrCOt the language spec resolve the ambiguity, then?
Probably for the same reason most language "specifications" don't
deserve this name, they're just vague descriptions with lots of grey
areas. Some languages are more precise and do provide usable
guarantees w.r.t when a value is unreachable, but they're still a
small minority.
So if the program hangs or crashes, it hasn't generated any type of
answer much less a wrong one, and therefore it is correct. That type
of program is called partial or divergent. A never-diverging program
is called "total" and being correct and total at the same time is
called "total correctness".
Look at the decades of anguish CPython has suffered over its GIL.
Python's inventors insist that it's not a Lisp, but we Lispers can
see that it's just a weird Lisp implementation with some surface
syntax added. It even has lambda!
There is one easy, if one might say brutal, way of guaranteeing
termination, at any rate: make the language primitive-recursive.
I think SML/NJ got a speedup by using the machine's paging hardware to
raise an address fault when the bump allocator hit the end of heap
space, instead of spending actual CPU instructions checking that the
pointer was in range on each allocation.
It generated THAT much garbage.
On Fri, 03 Jul 2026 10:18:04 -0400, Stefan Monnier wrote:
Lawrence DrCOOliveiro [2026-07-03 04:04:00] wrote:You havenrCOt seen all the ones telling me IrCOm wrong in saying that
Quite a few are insisting that garbage collection is somehowI haven't seen such a claim being made here.
superior overall.
Python is doing the right thing with reference-counting?
If garbage collection is so good, why donrCOt OS kernels use it?
The usual main weaknesses of refcounting is low-speed and difficulty
dealing with cycles.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
There is one easy, if one might say brutal, way of guaranteeing
termination, at any rate: make the language primitive-recursive.
That still doesn't guarantee any reasonable memory bounds.
Python's inventors insist that it's not a Lisp, but we Lispers can
see that it's just a weird Lisp implementation with some surface
syntax added.
See, there you go, repeating the same thing again. It is garbage
collection that is more likely to suffer from performance issues than reference-counting.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
It is garbage collection that is more likely to suffer from
performance issues than reference-counting.
What on earth makes you spout nonsense like this?
On Sat, 04 Jul 2026 09:23:44 -0400, Stefan Monnier wrote:
The usual main weaknesses of refcounting is low-speed and difficulty
dealing with cycles.
See, there you go, repeating the same thing again. It is garbage
collection that is more likely to suffer from performance issues than reference-counting.
On Sat, 04 Jul 2026 21:44:50 -0700, Paul Rubin wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
It is garbage collection that is more likely to suffer from
performance issues than reference-counting.
What on earth makes you spout nonsense like this?
Whichever way you look at garbage collection, it is going to be cache-hostile.
I pointed out issues with storage reclamation. Someone said that
garbage collectors donrCOt work that way, they only access live objects,
not dead ones. But thatrCOs no better: copying live objects to new
locations means throwing away their existing cache entries, if any,
and forcing new cache faults.
So you see, there is no escaping the conclusion that garbage
collection is a fundamentally low-performance activity.
copying live objects to new locations means throwing away their
existing cache entries, if any, and forcing new cache faults.
So you see, there is no escaping the conclusion that garbage
collection is a fundamentally low-performance activity.
On Fri, 03 Jul 2026 10:12:41 -0400, Stefan Monnier wrote:
Lawrence DrCOOliveiro [2026-07-03 05:45:01] wrote:Nowadays I would say theyrCOre the majority.
So why doesnrCOt the language spec resolve the ambiguity, then?Probably for the same reason most language "specifications" don't
deserve this name, they're just vague descriptions with lots of grey
areas. Some languages are more precise and do provide usable
guarantees w.r.t when a value is unreachable, but they're still a
small minority.
steve g <Sgonedes1977@gmail.com> wrote:
Does any program actually free or return memory to the kernel before it exits?
Absolutely. LispWorks even has a function to do just this.
Ar an nao|| l|i is fiche de m|! Meitheamh, scr|!obh tfb:
steve g <Sgonedes1977@gmail.com> wrote:
Absolutely. LispWorks even has a function to do just this.
Does any program actually free or return memory to the kernel
before it exits?
Why, with a modern OS? For the sake of leak-tracking?
I guess you have a very different idea of what a "guarantee" looks
like than I.
On Sat, 04 Jul 2026 09:23:44 -0400, Stefan Monnier wrote:
The usual main weaknesses of refcounting is low-speed and difficultySee, there you go, repeating the same thing again. It is garbage
dealing with cycles.
collection that is more likely to suffer from performance issues than reference-counting.
Lawrence DrCOOliveiro [2026-07-05 01:46:21] wrote:
It is garbage collection that is more likely to suffer from
performance issues than reference-counting.
So you say. I don't have my own numbers to back my claim, and AFAIK
neither do you. I'm only stating a general consensus among
practitioners.
On Sun, 05 Jul 2026 22:14:32 +0100, Aidan Kehoe wrote:
Ar an nao|| l|i is fiche de m|! Meitheamh, scr|!obh tfb:
steve g <Sgonedes1977@gmail.com> wrote:
Absolutely. LispWorks even has a function to do just this.
Does any program actually free or return memory to the kernel
before it exits?
Why, with a modern OS? For the sake of leak-tracking?
rCLModernrCY OSes support multitasking. That means there are going to be other processes running and doing useful things in their way, not just yours.
Giving up memory yourCOre not using is just part of acting like a well-behaved resident of the userland ecosystem. Because, at least on
Linux, being too much of a memory hog is liable to awaken the Dreaded
OOM Killer.
And you do not want that.
Does any program actually free or return memory to the kernelAbsolutely. LispWorks even has a function to do just this.
before it exits?
I took the question to mean rCLright before it exits,rCY which would be
a waste of time.
On 2026-07-05, Lawrence DrCOOliveiro wrote:
On Sat, 04 Jul 2026 21:44:50 -0700, Paul Rubin wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
It is garbage collection that is more likely to suffer from
performance issues than reference-counting.
What on earth makes you spout nonsense like this?
Whichever way you look at garbage collection, it is going to be
cache-hostile.
I pointed out issues with storage reclamation. Someone said that
garbage collectors donrCOt work that way, they only access live objects,
not dead ones. But thatrCOs no better: copying live objects to new
locations means throwing away their existing cache entries, if any,
and forcing new cache faults.
So you see, there is no escaping the conclusion that garbage
collection is a fundamentally low-performance activity.
I've kind of lost track in this whole thread, so if possible please
refresh my memory: how does reference counting avoid the
"cache-hostility" issue?
On Sun, 05 Jul 2026 11:02:49 -0400, Stefan Monnier wrote:
Lawrence DrCOOliveiro [2026-07-05 01:46:21] wrote:
It is garbage collection that is more likely to suffer from
performance issues than reference-counting.
So you say. I don't have my own numbers to back my claim, and AFAIK
neither do you. I'm only stating a general consensus among
practitioners.
Do your rCLpractitionersrCY include OS kernel developers?
I also mentioned alternative purely-garbage-collected Python
implementations, that never seemed able to offer any significant
benefits (performance or otherwise) over regular CPython.
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
Python's inventors insist that it's not a Lisp, but we Lispers can
see that it's just a weird Lisp implementation with some surface
syntax added.
Lisp doesnrCOt have operator overloading.
On Sun, 05 Jul 2026 11:02:49 -0400, Stefan Monnier wrote:
Lawrence DrCOOliveiro [2026-07-05 01:46:21] wrote:Do your rCLpractitionersrCY include OS kernel developers?
It is garbage collection that is more likely to suffer fromSo you say. I don't have my own numbers to back my claim, and AFAIK
performance issues than reference-counting.
neither do you. I'm only stating a general consensus among
practitioners.
I also mentioned alternative purely-garbage-collected Python
implementations, that never seemed able to offer any significant
benefits (performance or otherwise) over regular CPython.
Lawrence DrCOOliveiro [2026-07-06 01:10:30] wrote:
On Sun, 05 Jul 2026 11:02:49 -0400, Stefan Monnier wrote:
Lawrence DrCOOliveiro [2026-07-05 01:46:21] wrote:Do your rCLpractitionersrCY include OS kernel developers?
It is garbage collection that is more likely to suffer fromSo you say. I don't have my own numbers to back my claim, and AFAIK
performance issues than reference-counting.
neither do you. I'm only stating a general consensus among
practitioners.
No, "practitioners" of the art of implementing memory management.
I also mentioned alternative purely-garbage-collected Python
implementations, that never seemed able to offer any significant
benefits (performance or otherwise) over regular CPython.
If you think it has anything to do with their memory management, I can't
help you, I'm afraid.
So you say. I don't have my own numbers to back my claim, and AFAIK
neither do you.
I'd like to see actual data instead of made-up numbers in the above,
but you can see the shape of things.
Lawrence DrCOOliveiro [2026-07-06 01:10:30] wrote:
On Sun, 05 Jul 2026 11:02:49 -0400, Stefan Monnier wrote:
Lawrence DrCOOliveiro [2026-07-05 01:46:21] wrote:
It is garbage collection that is more likely to suffer from
performance issues than reference-counting.
So you say. I don't have my own numbers to back my claim, and
AFAIK neither do you. I'm only stating a general consensus among
practitioners.
Do your rCLpractitionersrCY include OS kernel developers?
No, "practitioners" of the art of implementing memory management.
I also mentioned alternative purely-garbage-collected Python
implementations, that never seemed able to offer any significant
benefits (performance or otherwise) over regular CPython.
If you think it has anything to do with their memory management, I
can't help you, I'm afraid.
Alan Bawden <alan@csail.mit.edu> writes:
For example, PDP-10 MacLisp....
Thanks for this long and interesting post. I don't have much of a
response but I can say that I read all of it with appreciation. Today,
I guess that in such an implementation, CPU instructions are so much
faster than memory accesses that there's not much slowdown from checking arithmetic results for belonging in the permanently allocated set. Can
I ask if that was an issue in the Maclisp era?
On Tue, 30 Jun 2026 13:47:55 -0700, Paul Rubin wrote:
Every value in Python is an object.
The understanding that native Python code is slow while
C-extensioned code runs at C-speed (known as the "glue
language" paradigm) has been a foundational truth about
Python throughout its history, and I'm a bit surprised that
where you once worked they only found this out the hard way.
On Mon, 29 Jun 2026 09:47:23 -0000 (UTC), tfb wrote:
But if the cost is a peak use of several times the actual total size
of the live objects at any one time, then that shows why
reference-counting can be a worthwhile option, doesnrCOt it?
Lisp doesnrCOt have operator overloading.
It's usually not a problem. It just illustrates that there can be
different notions of "reachable".
On Thu, 02 Jul 2026 13:41:43 -0400, Stefan Monnier wrote:
So why doesnrCOt the language spec resolve the ambiguity, then?
Why, with a modern OS? For the sake of leak-tracking?
yeti <yeti@tilde.institute> writes:
Python with braces. Because Python is awesome, but whitespace is awful.
"Although some people have initial resistance to the
( indentation as block structure | parentheses)
most come to ( accept | deeply appreciate ) them."
Peter Norvig, Python vs Lisp comparison (May 2000) https://www.norvig.com/python-lisp.html
Every value in CL is an object, every object belongs to a class. You can't subclass some builtin classes. Functions and classes are classes.
(a) Most Lisps do not have special-case infix operators at all, but rather >everything is syntactically (<op> ...).
Have they come up with any excuses as to why OS kernels donrCOt use
garbage collection?
What on earth makes you spout nonsense like this?
Have they come up with any excuses as to why OS kernels donrCOt use
garbage collection?
What I do find amusing us when some bozo turns up and reformats
(defun foo (...)
(...
...
(...
(... ...))))
As
(defun foo (...)
(...
...
(... ...)
)
)
I'd not call a change a "reformat" when a gentleman changes
the number of parentheses and who knows what else ("...").
We knew. We'd just made (I think: it's a long time ago) three mistakes:
the Java compiler was much better than we assumed, the Java version version >of the search code was quicker than we assumed, and the Python bottleneck
ate more of the performance than we assumed.
Paul Rubin <no.email@nospam.invalid> wrote:
yeti <yeti@tilde.institute> writes:
Python with braces. Because Python is awesome, but whitespace is awful.
"Although some people have initial resistance to the
( indentation as block structure | parentheses)
most come to ( accept | deeply appreciate ) them."
Peter Norvig, Python vs Lisp comparison (May 2000)
https://www.norvig.com/python-lisp.html
And he's right. I've written lots of Python, and I have a fairly deep
hatred of the language as a result. But indentation as block structure is entirely a non-issue for me: it's entirely fine. This is not a thing which is wrong with Python.
What I do find amusing us when some bozo turns up and reformats
(defun foo (...)
(...
...
(...
(... ...))))
As
(defun foo (...)
(...
...
(... ...)
)
)
I mean, for
def foo (...):
if ...:
if ...:
...
do they leave two lines which are blank except for suitable numbers of leading spaces after the definition?
Consider:
(defun c_args_as_string (arguments)
(cond
((null arguments) "")
(t (let ((res (c_type_as_string (nth 1 (car arguments)))))
(dolist (el (rest arguments))
(setf res (concatenate 'string res ", "
(c_type_as_string (nth 1 el)))))
res)))
)
I do not say it is great code, but I find it easier to handle than
more traditional Lisp style.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
Lisp doesnrCOt have operator overloading.
What a stupid thing to say.
There are a few releated things and terminology is somewhat mixed.
I distinguish the following:
Waldek Hebisch <antispam@fricas.org> wrote:
Consider:
(defun c_args_as_string (arguments)
(cond
((null arguments) "")
(t (let ((res (c_type_as_string (nth 1 (car arguments)))))
(dolist (el (rest arguments))
(setf res (concatenate 'string res ", "
(c_type_as_string (nth 1 el)))))
res)))
)
I do not say it is great code, but I find it easier to handle than
more traditional Lisp style.
OK, that's just weird. Everything is fine and you've got lots of close parens at the ends of lines in the standard way, but then something breaks and you have the final close paren on its own at the left margin. I can't even begin to understand what motivates that.
But the same question: if you wrote it in Python, would you leave an extra little blank line for that weird closing paren?
If you look at rational factors: I need to see where given piece of
code ends.
Waldek Hebisch <antispam@fricas.org> wrote:
There are a few releated things and terminology is somewhat mixed.
I distinguish the following:
I think everyone knows what the Python documentation means when it talks about 'operator overloading', and nobody cares about whether it's dynamic, static, or smells of elderberries.
Much more interesting than counting angels is the vast gulfs between languages which have a whole slew of special syntax fir infix or other operators, languages which do that but allow you to define new ones in interesting ways, and languages which simply say 'fuck all that, we'll have
a regular syntax'.
When Java dropped back in '96, Python was actually faster a lot of
the time. But that vibe only lasted for like two or three years.
Back then, I was out here teaching Java courses and totally ghosting
Python.
I am not a big fan of indented syntax, but for me it is in not a big
trouble. And when using indented syntax I feel less pressure to put
end markers on syntactic constructs (compared to Lisp or C). Part of
the reason is that in indented syntax indentation can not be
misleading ...
I trying to be conservative with putting end parentheses on separate
lines. One, doing this on too many constructs would add too many
extra lines. Second, putting such parentheses in too many places
would limit their value, they would be no longer good cue.
tfb <tfb@work.it.out> wrote:
I think everyone knows what the Python documentation means when it talks
about 'operator overloading', and nobody cares about whether it's dynamic, >> static, or smells of elderberries.
Some people care. Especially people who (like me) look seriously
at statically typed languages.
Imagine, now, if someone from one of these groups of people turned up in a >forum where people from the other group discuss things and said "you can't >use 'LW' like that: you have to use our definition.
In pretty much every language - like C++, C#, Rust, or Kotlin -
operator overloading is static. Python is the only one doing its
own thing and keeping it dynamic.
Paul Rubin <no.email@nospam.invalid> wrote:
What on earth makes you spout nonsense like this?
It's obvious he's a troll at this point. But he's also the kind of troll >we've seen before on CLL: the circular troll.
:
Past experience says that these people *never* give up: they will cycle >around their mental loops for ever, in a kind of sad DoS attack on everyone >else.
:
The terror is that, like the previous CLL troll, he will become >tail-recursive: responding endlessly to his own arguments long after
everyone else has left, keeping at it for years. If that happens then CLL >will die, again. Let's hope it doesn't.
But please everyone: stop responding. Let him 'win', because he can never >admit he is wrong and he will endlessly recycle the same refuted claims.
I am as guilty -- more guilty -- as anyone of responding to him, but it
needs to stop.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
On Mon, 29 Jun 2026 09:47:23 -0000 (UTC), tfb wrote:
But if the cost is a peak use of several times the actual total size
of the live objects at any one time, then that shows why
reference-counting can be a worthwhile option, doesnrCOt it?
Nobody is claiming reference-counting is not useful in very >memory-constrained systems. That is, for instance, one of the reasons >Interlisp-D used it: Wikipedia thinks a Dandelion could have 1.5MB: I think >the could have 3.something (we had Dandytigers though, but I think the >difference was just hardware floating-point), and the Daybreak could have >3.7MB. These systems supported a fully-fledged graphical environment whose >image sizes were much larger than the physical memory of the machine.
However the memory overhead for a generational copying GC doesn't need to
be more than the size of the largest generation.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
Have they come up with any excuses as to why OS kernels donrCOt use
garbage collection?
Here is why: they're written either in C or in languages which must be
memory & call compatible with C. It is essentially impossible to implement
a garbage collector in C. There is a famous counterexample: the Boehm GC. >It would probably be possible to use that in an OS kernel written in C but
I expect it would be very hard to retrofit it to an existing kernel. It's >also (because C) not a copying collector.
C was a deeply appropriate language to write an OS for the PDP-11. At
every point since then there's been the choice of continuing to use C and >either a port of that OS or an implementation of a compatible OS or of >implementing a new, incompatible, OS. For at least 30 years there's really >only been one answer to that question. And so, today, by a series of >perfectly reasonable choices, we've ended up with a vast OS implemented in
a language which is now deeply inappropriate.
Sadly we've also ended up with programmers who think the machines they >program for are giant PDP-11s, and as a result machines which spend a huge >amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
There is, in fact, a copying collector for C++ [not for C]. It is conservative in the stack but relies on perfect knowledge of heap allocations.
On Thu, 9 Jul 2026 09:15:06 -0000 (UTC), tfb <tfb@work.it.out> wrote:
However the memory overhead for a generational copying GC doesn't need to
be more than the size of the largest generation.
Not exactly.
The largest generation typically is the 'long-lived' objects, and
usually it has zero additional memory overhead because it is handled
by compaction rather than by copying.
[Yes, compaction is achieved by copying, but the two approaches are considered different by the literature.]
George Neuner <gneuner2@comcast.net> writes:
There is, in fact, a copying collector for C++ [not for C]. It is
conservative in the stack but relies on perfect knowledge of heap
allocations.
Also just yesterday or so, there was yet another report of a serious use-after-free bug that's been in the Linux kernel for 15 years. Maybe
we'd be better off if Linux had used GC.
George Neuner <gneuner2@comcast.net> wrote:
On Thu, 9 Jul 2026 09:15:06 -0000 (UTC), tfb <tfb@work.it.out> wrote:
However the memory overhead for a generational copying GC doesn't need to >>> be more than the size of the largest generation.
Not exactly.
The largest generation typically is the 'long-lived' objects, and
usually it has zero additional memory overhead because it is handled
by compaction rather than by copying.
[Yes, compaction is achieved by copying, but the two approaches are
considered different by the literature.]
Yes, my point really was that it will not be more: the very worst case I
can think of is a collector which needs to allocate space equal to the size >of the largest (which as you say is usually the long-lived-object)
generation to copy it. In practice you can do better almost always.
Paul Rubin <no.email@nospam.invalid> wrote:
George Neuner <gneuner2@comcast.net> writes:
There is, in fact, a copying collector for C++ [not for C]. It is
conservative in the stack but relies on perfect knowledge of heap
allocations.
Also just yesterday or so, there was yet another report of a serious
use-after-free bug that's been in the Linux kernel for 15 years. Maybe
we'd be better off if Linux had used GC.
That's an important point. A subtext in the 'if x is so good, why doesn't >popular thing y use x?' family of questions is that y, being popular, is >somehow the best thing possible, when often y, being a thing made by
humans, is in fact a pile of steaming shit. I am not implying Linux is a >pile of steaming shit, but many things are.
'Good' and 'popular' are not synonyms.
Certainly there is junk out there, but more often the "popular" choice
just is something that worked ok for its original purpose, and somehow received a lot of attention [and emulation].
try using the --version option at the cmd line.
That can print any number it likes. How do you verify the number if
prints actually means something?
by reading the binary or the assembler. but yes a computer program
may print something inaccurately. this why most people use a
signature file. I think that just checking the md5 is sufficient.
Checking against what?
Remember, the issue was determining which version of the source code
was involved in creating this binary. How does an md5 of source code
relate in any way to that of the binary?
mkfontmap.s <==.file "mkfontmap.c"
On Mon, 29 Jun 2026 10:44:15 -0000 (UTC), tfb wrote:
Obviously this is just the same as using eq for numbers being a bad
idea in CL ...
Luckily, thatrCOs not a problem in Python, because it allows custom
overloads for standard operators like rCL==rCY, which can do the right
thing in a type-specific fashion.
On Mon, 29 Jun 2026 07:33:05 -0000 (UTC), tfb wrote:
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
If a GC is not finding long-dead objects to reclaim, then what
exactly is it doing? IsnrCOt that exactly what the rCLgarbagerCY is, that >>> it is supposed to rCLcollectrCY?
Like I said: you do not understand, at all, how a copying GC works.
ThatrCOs what we call a rCLpassive-aggressiverCY response: trying to imply IrCOm wrong, but not specifically enough so that I can call you up on it.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
Have they come up with any excuses as to why OS kernels donrCOt use
garbage collection?
Here is why: they're written either in C or in languages which must be
memory & call compatible with C. It is essentially impossible to implement
a garbage collector in C. There is a famous counterexample: the Boehm GC. It would probably be possible to use that in an OS kernel written in C but
I expect it would be very hard to retrofit it to an existing kernel. It's also (because C) not a copying collector.
C was a deeply appropriate language to write an OS for the PDP-11. At
every point since then there's been the choice of continuing to use C and either a port of that OS or an implementation of a compatible OS or of implementing a new, incompatible, OS. For at least 30 years there's really only been one answer to that question. And so, today, by a series of perfectly reasonable choices, we've ended up with a vast OS implemented in
a language which is now deeply inappropriate.
Sadly we've also ended up with programmers who think the machines they program for are giant PDP-11s, and as a result machines which spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
George Neuner <gneuner2@comcast.net> wrote:
Certainly there is junk out there, but more often the "popular" choice
just is something that worked ok for its original purpose, and somehow
received a lot of attention [and emulation].
I agree. As I think I've said previously here(*) I think both C and Unix were just astonishingly good designs ... for the PDP-11. Not so great (especially C) on today's systems.
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
Have they come up with any excuses as to why OS kernels donrCOt use
garbage collection?
Here is why: they're written either in C or in languages which must be
memory & call compatible with C. It is essentially impossible to implement
a garbage collector in C. There is a famous counterexample: the Boehm GC. It would probably be possible to use that in an OS kernel written in C but
I expect it would be very hard to retrofit it to an existing kernel. It's also (because C) not a copying collector.
C was a deeply appropriate language to write an OS for the PDP-11. At
every point since then there's been the choice of continuing to use C and either a port of that OS or an implementation of a compatible OS or of implementing a new, incompatible, OS. For at least 30 years there's really only been one answer to that question. And so, today, by a series of perfectly reasonable choices, we've ended up with a vast OS implemented in
a language which is now deeply inappropriate.
Sadly we've also ended up with programmers who think the machines they program for are giant PDP-11s, and as a result machines which spend a huge amount of effort pretending to be giant PDP-11s.--- Synchronet 3.22a-Linux NewsLink 1.2
It's all a tragedy.
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
If garbage collection is so good, why donrCOt OS kernels use it?
Similarly, I don't think the JVM for desktop java has ever been lauded
for being very performant and lean on resource usage.
tfb <tfb@work.it.out> wrote or quoted:
Imagine, now, if someone from one of these groups of people turned up in a >>forum where people from the other group discuss things and said "you can't >>use 'LW' like that: you have to use our definition.
Anyone can just make up definitions for words whenever they want.
But if people actually wanna talk to each other, they gotta get
on the same page about what the heavy-hitting terms mean.
In pretty much every language - like C++, C#, Rust, or Kotlin -
operator overloading is static. Python is the only one doing its
own thing and keeping it dynamic.
Anyway, here's how
ISO/IEC 2382-15
"Information Technology rCo Vocabulary",
Second edition / 1998
Let me guess, you can squeeze more scheme into the cput if it were
buffer and had more silicon. people usually use what works. You do not
like C because it is not python. get over it.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Mon, 29 Jun 2026 10:44:15 -0000 (UTC), tfb wrote:
Obviously this is just the same as using eq for numbers being a
bad idea in CL ...
Luckily, thatrCOs not a problem in Python, because it allows custom
overloads for standard operators like rCL==rCY, which can do the right
thing in a type-specific fashion.
seriously; operating overloading?
|Which one gets invoked ("dispatch") is decided at run-time,
|in contrast to many other languages with "overloading".
"An Introduction to the Common Lisp Object System"
- Gregor Kiczales, Jim des Rivi|?res, and Daniel G. Bobrow?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
If garbage collection is so good, why donrCOt OS kernels use it?
You are probably using a shitty OS.
postscript is a complicated language in my mind, especially when
compared to C.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Mon, 29 Jun 2026 07:33:05 -0000 (UTC), tfb wrote:
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
If a GC is not finding long-dead objects to reclaim, then what
exactly is it doing? IsnrCOt that exactly what the rCLgarbagerCY is,
that it is supposed to rCLcollectrCY?
Like I said: you do not understand, at all, how a copying GC works.
ThatrCOs what we call a rCLpassive-aggressiverCY response: trying to
imply IrCOm wrong, but not specifically enough so that I can call you
up on it.
Where did you study psychology; I mean social worker class.
tfb <tfb@work.it.out> writes:
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
Have they come up with any excuses as to why OS kernels donrCOt use
garbage collection?
Here is why: they're written either in C or in languages which must be
memory & call compatible with C. It is essentially impossible to implement >> a garbage collector in C. There is a famous counterexample: the Boehm GC. >> It would probably be possible to use that in an OS kernel written in C but >> I expect it would be very hard to retrofit it to an existing kernel. It's >> also (because C) not a copying collector.
Introduction to GC:
The GC package contains the Boehm-Demers-Weiser conservative garbage collector, which can be used as a garbage collecting replacement for the
C malloc function or C++ new operator. It allows you to allocate memory basically as you normally would, without explicitly deallocating memory
that is no longer useful. The collector automatically recycles memory
when it determines that it can no longer be otherwise accessed. The
collector is also used by a number of programming language
implementations that either use C as intermediate code, want to
facilitate easier interoperation with C libraries, or just prefer the
simple collector interface. Alternatively, the garbage collector may be
used as a leak detector for C or C++ programs, though that is not its
primary goal.
this is what guile uses and GCC can use.
C was a deeply appropriate language to write an OS for the PDP-11. At
every point since then there's been the choice of continuing to use C and
either a port of that OS or an implementation of a compatible OS or of
implementing a new, incompatible, OS. For at least 30 years there's really >> only been one answer to that question. And so, today, by a series of
perfectly reasonable choices, we've ended up with a vast OS implemented in >> a language which is now deeply inappropriate.
let me guess assembler is not your programming language of choice.
henceforth C.
Sadly we've also ended up with programmers who think the machines they
program for are giant PDP-11s, and as a result machines which spend a huge >> amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
tfb <tfb@work.it.out> writes:
Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:
Have they come up with any excuses as to why OS kernels donrCOt use
garbage collection?
Here is why: they're written either in C or in languages which must be
memory & call compatible with C. It is essentially impossible to implement >> a garbage collector in C.
... There is a famous counterexample: the Boehm GC.
It would probably be possible to use that in an OS kernel written in C but >> I expect it would be very hard to retrofit it to an existing kernel. It's >> also (because C) not a copying collector.
On 10 Jul 2026 10:17:33 GMT, Stefan Ram wrote:
|Which one gets invoked ("dispatch") is decided at run-time,
|in contrast to many other languages with "overloading".
"An Introduction to the Common Lisp Object System"
- Gregor Kiczales, Jim des Rivi|?res, and Daniel G. Bobrow?
Maybe that doesnrCOt mean what you think it means. Remember, theyrCOre
using rCLdispatchrCY specifically for a language without infix operators. >Smalltalk was doing dynamic operator overloading before Common Lisp
was even thought of.
Of course you meant "for C." Many collectors are/were written "in C."
Sadly we've also ended up with programmers who think the machines
they program for are giant PDP-11s, and as a result machines which
spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
[...]
Sadly we've also ended up with programmers who think the machines
they program for are giant PDP-11s, and as a result machines which
spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent
fast code that I'd write in C, where speed matters. In other words, I
seem to gain nothing (other than more work) by writing typical
applications in C.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct.
On Fri, 31 Jul 2026 12:21:51 -0300, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct.
What a dumb idea. Common Lisp is full of legacy baggage to cater to proprietary pre-POSIX OSes which are now extinct.
Python can offer basic facilities like these in its standard library: <https://docs.python.org/3/library/subprocess.html> <https://docs.python.org/3/library/select.html>; where are the Common
Lisp equivalents?
On Wed, 29 Jul 2026 16:26:56 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
If garbage collection is so good, why donrCOt OS kernels use it?
You are probably using a shitty OS.
So where is there a rCLnon-shitty OSrCY that uses garbage collection in
its kernel? Does the one *you* use have garbage collection in its
kernel?
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
[...]
Sadly we've also ended up with programmers who think the machines
they program for are giant PDP-11s, and as a result machines which
spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent
fast code that I'd write in C, where speed matters. In other words, I
seem to gain nothing (other than more work) by writing typical
applications in C.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Wed, 29 Jul 2026 16:26:56 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
If garbage collection is so good, why donrCOt OS kernels use it?
You are probably using a shitty OS.
So where is there a rCLnon-shitty OSrCY that uses garbage collection in
its kernel? Does the one *you* use have garbage collection in its
kernel?
It depends on how the kernel is compiled.
Anton Antimo <anton@safunu.org> writes:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
[...]
Sadly we've also ended up with programmers who think the machines
they program for are giant PDP-11s, and as a result machines which
spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent
fast code that I'd write in C, where speed matters. In other words, I
seem to gain nothing (other than more work) by writing typical
applications in C.
Wait until you read LISP:Lisp In Small Pieces. it's published in france.
PYTHON IS THE ONLY TRUE SOLUTION PYTHON HAS BEEN THE BEST THE ONLY
LANGUAGE FOR CENTURIES REFERENCE COUNTING WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS GARBAGE COLLECTION IS THE WORK OF SATAN PYTHON IS THE
STANDARD REFERENCE COUNTING MAKES THE BIRDS SING AND THE GRASS GREEN
GARBAGE COLLECTORS ARE CONTINUALLY TRAWLING THROUGH DEAD DATA LISP IS OBSOLETE EVIL NOBODY USES LISP USE PYTHON LIKE ME USE PYTHON REFERENCE
PYTHON LISP SLOW FAST PYTHON BEST YES PYTHON GARBAGE BAD PYTHON OBSOLETE
It is 2042.
Fade.
Well, that was only a leg-pull. Here is another paragraph of that
slop, to provide some balance.
Enterprise backend raA Java or C#
On Sat, 1 Aug 2026 07:49:41 -0400, Paul wrote:
Well, that was only a leg-pull. Here is another paragraph of that
slop, to provide some balance.
Enterprise backend raA Java or C#
This <https://www.infoworld.com/article/4091447/spring-ai-tutorial-get-started-with-spring-ai.html>
is supposed to be an example of how you do AI programming in Java.
Is anybody still mystified why normal people would rather use Python
instead?
[... Python, Rust ...]
Hello everyone!
I want to learn Common Lisp, but I don't really know what resources to
use.
What did you all use to learn? Is that even relevant? Is this newsgroup active?
Thanks for everyone in advice
For learning the basics about the language I highly recommend the
book "Practical Common Lisp" by Peter Seibel.
Also it does help to have a background in Emacs Lisp ...
For learning the basics about the language I highly recommend the book "Practical Common Lisp" by Peter Seibel.... Also it does help to have
a background in Emacs Lisp
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
Python's inventors insist that it's not a Lisp, but we Lispers can
see that it's just a weird Lisp implementation with some surface
syntax added.
Lisp doesnrCOt have operator overloading.
On Sun, 5 Jul 2026 01:49:41 -0000 (UTC), I wrote:
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
Python's inventors insist that it's not a Lisp, but we Lispers can
see that it's just a weird Lisp implementation with some surface
syntax added.
Lisp doesnrCOt have operator overloading.
Also: Python doesnrCOt need the whole multiple-value-return Heath-Robinsonesque mechanism. It has something simpler: destructuring assignment.
|------------------------------------------------------------------------------|
|" Ar an c||igi|| l|i de m|! I||il, scr|!obh Lawrence DrCOOliveiro: |
| |
| > On Sun, 05 Jul 2026 22:14:32 +0100, Aidan Kehoe wrote: |
| > |
| > > Ar an nao|| l|i is fiche de m|! Meitheamh, scr|!obh tfb: |
| > > |
| > >> steve g <Sgonedes1977@gmail.com> wrote: |
| > >>> |
| > >>> Does any program actually free or return memory to the kernel |
| > >>> before it exits? |
| > >>> |
| > >> Absolutely. LispWorks even has a function to do just this. |
| > > |
| > > Why, with a modern OS? For the sake of leak-tracking? |
| > |
| > rCLModernrCY OSes support multitasking. That means there are going to be |
| > other processes running and doing useful things in their way, not just |
| > yours. |
| > |
| > Giving up memory yourCOre not using is just part of acting like a |
| > well-behaved resident of the userland ecosystem. Because, at least on |
| > Linux, being too much of a memory hog is liable to awaken the Dreaded |
| > OOM Killer. |
| > |
| > And you do not want that. |
| |
|I broadly agree with that; my question above was from a misinterpretation of: |
| |
| > >>> Does any program actually free or return memory to the kernel |
| > >>> before it exits? |
| > >>> |
| > >> Absolutely. LispWorks even has a function to do just this. |
| |
|I took the question to mean rCLright before it exits,rCY which would be a waste of|
|time." |
|------------------------------------------------------------------------------|
arsa Aodh|in mac Eochadha.
N|! c||is n|iire sin!
Is mise le meas,
Niocl|is|in Caile|in Glost|-ir
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
George Neuner <gneuner2@comcast.net> wrote:
Of course you meant "for C." Many collectors are/were written "in C."
Yes, and specifically 'for large existing C programs which you are not >willing to completely reengineer'. At any point since it started running
on machines where a GC would be a practical proposition[*], the Unix kernel >was such a program.
There is more, I think: the Sapir-Whorf hypothesis is at least partly true >for programming languages: the language determines what its programmers can >(easily) think. You obviously could write GC-friendly C programs, but C >programmers exposed to large existing C programs probably would find them
so alien they probably wouldn't actually write them. You really need a new >language (which, in turn, would influence how people think, but in
different ways).
And let's leave out compatibility questions: 'you mean to port my device >driver I have to ...?'
All of this means that, once you've got large C programs and a culture
around them you can't just drop in GC.
[*] Yes, I do not claim GC is suitable for all machines. I've written >programs for the 1802.
On Wed, 29 Jul 2026 16:08:10 -0400, steve g wrote:
Specific substantive response still lacking.
On 01/08/2026 6:46 AM, Lawrence DrCOOliveiro wrote:
On Fri, 31 Jul 2026 12:21:51 -0300, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:What a dumb idea. Common Lisp is full of legacy baggage to cater to
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct.
proprietary pre-POSIX OSes which are now extinct.
As always, you start off by mouthing your own ignorance.
* OpenVMS is both sold and ported to the x86. https://vmssoftware.com/
* OS/2 is being sold and supported, under a new brand name.
https://www.arcanoae.com/
Flecks of foam and blood land on the keyboard. No birds sing; what once
was grass is now dust and ash.
Still he types, faster and faster now, singing and chanting.
From the computer in the shack a cable runs. The camera follows it, to its end: copper cores poking through charred insulation.
Fade.
On Fri, 31 Jul 2026 23:52:27 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Wed, 29 Jul 2026 16:26:56 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Mon, 29 Jun 2026 17:37:24 -0700, Paul Rubin wrote:
If garbage collection is so good, why donrCOt OS kernels use it?
You are probably using a shitty OS.
So where is there a rCLnon-shitty OSrCY that uses garbage collection in
its kernel? Does the one *you* use have garbage collection in its
kernel?
It depends on how the kernel is compiled.
What a load of nonsense. There is no OS kernel you have access to,
that uses garbage collection for internal memory management. Just
admit it instead of trying to bullshit.
On 01/08/2026 11:59 AM, steve g wrote:
Anton Antimo <anton@safunu.org> writes:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:Wait until you read LISP:Lisp In Small Pieces. it's published in france.
[...]
Sadly we've also ended up with programmers who think the machines
they program for are giant PDP-11s, and as a result machines which >>>>>> spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent >>> fast code that I'd write in C, where speed matters. In other words, I
seem to gain nothing (other than more work) by writing typical
applications in C.
I read the French edition. /Principes d'Implantation de Scheme et
Lisp/, and it's now available as ebook on Amazon. I recommend it,
it's a really fun book. I believe it's the /second edition/, and
may have a little bit different content than the English one, which
I haven't read.
Do you read French?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
There is no OS kernel you have access to, that uses garbage
collection for internal memory management. Just admit it instead of
trying to bullshit.
well thanks. as Microsoft's Singularity apparently uses a GC.
tfb <tfb@work.it.out> wrote:
Waldek Hebisch <antispam@fricas.org> wrote:
Consider:
(defun c_args_as_string (arguments)
(cond
((null arguments) "")
(t (let ((res (c_type_as_string (nth 1 (car arguments)))))
(dolist (el (rest arguments))
(setf res (concatenate 'string res ", "
(c_type_as_string (nth 1 el)))))
res)))
)
I do not say it is great code, but I find it easier to handle than
more traditional Lisp style.
OK, that's just weird. Everything is fine and you've got lots of close
parens at the ends of lines in the standard way, but then something breaks >> and you have the final close paren on its own at the left margin. I can't >> even begin to understand what motivates that.
If you look at rational factors: I need to see where given piece of
code ends. In bigger function with multiple blocks inside I would
put some parentheses in separate lines to signal ends of blocks.
There is also issue of seeing what is changed. Code frequently
gets added at end of existing functions. Separate "end"
parenthesis means that in such case old lines are unchanged and
only new lines get added. Version with parentheses at end of
line needs to move closing parentheses from old line to new
one.
I trying to be conservative with putting end parentheses on
separate lines. One, doing this on too many constructs would
add too many extra lines. Second, putting such parentheses
in too many places would limit their value, they would be no
longer good cue. Third, really small pieces of code are
managable without extra cues, it is bigger pieces when it
matters. Fourh, I want to limit dissatisfaction of Lispers
used to traditional style in case they need to work on code
that I write.
But the same question: if you wrote it in Python, would you leave an extra >> little blank line for that weird closing paren?
"no trailing white space".
On Tue, 04 Aug 2026 22:47:33 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
There is no OS kernel you have access to, that uses garbage
collection for internal memory management. Just admit it instead of
trying to bullshit.
well thanks. as Microsoft's Singularity apparently uses a GC.
Try using past tense. ItrCOs a dead project. Wonder why?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Tue, 04 Aug 2026 22:47:33 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
There is no OS kernel you have access to, that uses garbage
collection for internal memory management. Just admit it instead
of trying to bullshit.
well thanks. as Microsoft's Singularity apparently uses a GC.
Try using past tense. ItrCOs a dead project. Wonder why?
No, I do not wonder about microsoft or why their stuff fails.
On Tue, 04 Aug 2026 22:47:33 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
There is no OS kernel you have access to, that uses garbage
collection for internal memory management. Just admit it instead of
trying to bullshit.
well thanks. as Microsoft's Singularity apparently uses a GC.
Try using past tense. ItrCOs a dead project. Wonder why?
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 01/08/2026 11:59 AM, steve g wrote:
Anton Antimo <anton@safunu.org> writes:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:Wait until you read LISP:Lisp In Small Pieces. it's published in france. >>>
[...]
Sadly we've also ended up with programmers who think the machines >>>>>>> they program for are giant PDP-11s, and as a result machines which >>>>>>> spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent >>>> fast code that I'd write in C, where speed matters. In other words, I >>>> seem to gain nothing (other than more work) by writing typical
applications in C.
I read the French edition. /Principes d'Implantation de Scheme et
Lisp/, and it's now available as ebook on Amazon. I recommend it,
it's a really fun book. I believe it's the /second edition/, and
may have a little bit different content than the English one, which
I haven't read.
Do you read French?
No I do not read french; just the algorithms. It is a fantastic book. I
can also apparently read german algorithms but the comments and the docstrings can be difficult.
In C the situation is complicated even beyond simply not being able to
find pointers because the standard explicitly permits idioms and code optimizations that can obscure what pointers are there.
On 31/07/2026 11:21 PM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
[...]
Sadly we've also ended up with programmers who think the machines
they program for are giant PDP-11s, and as a result machines which
spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent
fast code that I'd write in C, where speed matters. In other words, I
seem to gain nothing (other than more work) by writing typical
applications in C.
The fun is in writing atypical applications, and then finding yourself looking at the disassembly in SBCL.
Personally, I love writing in C, even though it's more verbose.
That said, and to be mildly on-topic in comp.lang.lisp, have
* /The Common Lisp Condition System/, and
* /Programming Algorithms in Lisp/
been mentioned before as resources for learning common lisp?
These two books look lovely in my programming shelf, next to
* /Common Lisp Recipes/, and
* /Practical Common Lisp/,
which must have been mentioned. They're interspersed with
* /Low Level Programming/,
* /String Algorithms in C/, and
* /The Joys of Hashing/,
which come in handy when you want to implement your own Common
Lisp system.
Enjoy!
George Neuner <gneuner2@comcast.net> wrote:
In C the situation is complicated even beyond simply not being able to
find pointers because the standard explicitly permits idioms and code
optimizations that can obscure what pointers are there.
I wonder how the Symbolics C compiler dealt with all this horror? That's
not a rhetorical question: if anyone knows, I'd be interested, because it must have been painful.
On 05/08/2026 10:54 AM, Lawrence DrCOOliveiro wrote:
On Tue, 04 Aug 2026 22:47:33 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
There is no OS kernel you have access to, that uses garbage
collection for internal memory management. Just admit it instead of
trying to bullshit.
well thanks. as Microsoft's Singularity apparently uses a GC.
Try using past tense. ItrCOs a dead project. Wonder why?
Now, now, Lawrence, you're totally misunderstanding the situation.-a As always.-a Garbage collection is /not bad/.
To be fair, a big part of my struggle is the thick layer of Racket
on top of POSIX. For instance, try to locate the equivalent
select-call on it. It's so hard to recognize exactly how your Racket
maps to the lower level. I understand that may a strong point of
Racket's design, but it certainly hits my weakness.
Let Over Lambda
Doug Hoyte, 2008
ISBN 978-1-4357-1275-1
This book is about macros, that is programs that write programs.
Macros are what make lisp the greatest programming language in the
world. When used properly, macros enable amazing feats of
abstraction, programmer productivity, and code efficiency and
security that are unheard of elsewhere. Macros let you do things
you simply cannot do in other languages.
If garbage collection is so good, why donrCOt high-performance operating system kernels use it? Why do they prefer reference-counting instead?
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
Given this is posted to comp.lang.c, itrCOs always worth mentioning
these are not macros in the style of #define, but they work at the AST
level. Which is really the only sensible way to implement a workable
macro system.
And no longer unique to Lisp.
antispam@fricas.org (Waldek Hebisch) writes:
tfb <tfb@work.it.out> wrote:
Waldek Hebisch <antispam@fricas.org> wrote:
Consider:
(defun c_args_as_string (arguments)
(cond
((null arguments) "")
(t (let ((res (c_type_as_string (nth 1 (car arguments)))))
(dolist (el (rest arguments))
(setf res (concatenate 'string res ", "
(c_type_as_string (nth 1 el)))))
res)))
)
I do not say it is great code, but I find it easier to handle than
more traditional Lisp style.
OK, that's just weird. Everything is fine and you've got lots of close
parens at the ends of lines in the standard way, but then something breaks >>> and you have the final close paren on its own at the left margin. I can't >>> even begin to understand what motivates that.
If you look at rational factors: I need to see where given piece of
code ends. In bigger function with multiple blocks inside I would
put some parentheses in separate lines to signal ends of blocks.
There is also issue of seeing what is changed. Code frequently
gets added at end of existing functions. Separate "end"
parenthesis means that in such case old lines are unchanged and
only new lines get added. Version with parentheses at end of
line needs to move closing parentheses from old line to new
one.
Hear Hear!
IMHO python looks like pascal. Pascal is a great language but
do not mess up the begin/end statements! The semicolons should be
standard. I have the same issue with GO. This is starting to remind me
of sendmail.cf :)
I trying to be conservative with putting end parentheses on
separate lines. One, doing this on too many constructs would
add too many extra lines. Second, putting such parentheses
in too many places would limit their value, they would be no
longer good cue. Third, really small pieces of code are
managable without extra cues, it is bigger pieces when it
matters. Fourh, I want to limit dissatisfaction of Lispers
used to traditional style in case they need to work on code
that I write.
But the same question: if you wrote it in Python, would you leave an extra >>> little blank line for that weird closing paren?
[ ... ]--- Synchronet 3.22a-Linux NewsLink 1.2
"no trailing white space".
Hear hear!
On 05/08/2026 23:48, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
Given this is posted to comp.lang.c, itrCOs always worth mentioning
these are not macros in the style of #define, but they work at the AST
level. Which is really the only sensible way to implement a workable
macro system.
And no longer unique to Lisp.
Given that this is entirely about Lisp (or at least it has absoltuely nothing to do with C), it should be posted only in comp.lang.list - not comp.lang.c.-a It would be very nice if the absurd level of pointless cross-postings we have seen recently were to stop.-a It is fine to have occasional cross-postings and "outside influence" in a newsgroup, but a
few trolls have taken to cross-posting meaningless ramblings to all
sorts of groups.-a I would ask all reasonable participants in Usenet
threads to check the newsgroup lists on their posts, and trim them where
it makes sense (or simply not to respond to the worst trolls).
As for macros in programming languages, AST macros are /not/ the only "sensible" way to have macros.-a They are a very different thing from text-based macros as supported by the C pre-processor.-a The two types of macro have their advantages and disadvantages, and can be used for
different purposes.-a The mistake is not in having one or the other, but
in calling them both "macros".-a It is reasonable to note, however, that
AST macros must be part of the language while text-based macros can be provided by a generic external tool (like m4).
On 05/08/2026 23:48, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
Given this is posted to comp.lang.c, itrCOs always worth mentioning
these are not macros in the style of #define, but they work at the AST
level. Which is really the only sensible way to implement a workable
macro system.
And no longer unique to Lisp.
Given that this is entirely about Lisp (or at least it has absoltuely
nothing to do with C), it should be posted only in comp.lang.list -
not comp.lang.c. It would be very nice if the absurd level of
pointless cross-postings we have seen recently were to stop. It is
fine to have occasional cross-postings and "outside influence" in a newsgroup, but a few trolls have taken to cross-posting meaningless
ramblings to all sorts of groups. I would ask all reasonable
participants in Usenet threads to check the newsgroup lists on their
posts, and trim them where it makes sense (or simply not to respond to
the worst trolls).
As for macros in programming languages, AST macros are /not/ the only "sensible" way to have macros. They are a very different thing from text-based macros as supported by the C pre-processor. The two types
of macro have their advantages and disadvantages, and can be used for different purposes. The mistake is not in having one or the other,
but in calling them both "macros". It is reasonable to note, however,
that AST macros must be part of the language while text-based macros
can be provided by a generic external tool (like m4).
On Tue, 04 Aug 2026 23:11:08 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Tue, 04 Aug 2026 22:47:33 -0400, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
There is no OS kernel you have access to, that uses garbage
collection for internal memory management. Just admit it instead
of trying to bullshit.
well thanks. as Microsoft's Singularity apparently uses a GC.
Try using past tense. ItrCOs a dead project. Wonder why?
No, I do not wonder about microsoft or why their stuff fails.
Funny, you were just talking about it. Suddenly backpedalling when you realize itrCOs actually destroying rather than strengthening your
argument?
Now is there some particular book you feel is worth my time in German?
For either studying some C or Lisp arcana? Preferably not some basics,
as those are already covered in English.
George Neuner <gneuner2@comcast.net> wrote:
In C the situation is complicated even beyond simply not being able to
find pointers because the standard explicitly permits idioms and code
optimizations that can obscure what pointers are there.
I wonder how the Symbolics C compiler dealt with all this horror? That's
not a rhetorical question: if anyone knows, I'd be interested, because it must have been painful.
As for macros in programming languages, AST macros are /not/ the only >"sensible" way to have macros.
... They are a very different thing from
text-based macros as supported by the C pre-processor. The two types of >macro have their advantages and disadvantages, and can be used for
different purposes. The mistake is not in having one or the other, but
in calling them both "macros".
... It is reasonable to note, however, that--- Synchronet 3.22a-Linux NewsLink 1.2
AST macros must be part of the language while text-based macros can be >provided by a generic external tool (like m4).
Let me try to contribute with
Let Over Lambda
Doug Hoyte, 2008
ISBN 978-1-4357-1275-1
On Thu, 6 Aug 2026 09:05:38 +0200, David Brown
<david.brown@hesbynett.no> wrote:
As for macros in programming languages, AST macros are /not/ the only >>"sensible" way to have macros.
Depends on your definition of "sensible". <grin>
Do you think that reader macros are sensible?
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Wed, 29 Jul 2026 16:08:10 -0400, steve g wrote:
Specific substantive response still lacking.
I am actually nor familiar with this. thank you for mentioning it! I
will certainly discuss this with a friend whois Dr Psychology. This will
be a great discussion. seriously I think I can use this to impress him
:)
If garbage collection is so good, why donrCOt high-performance operating system kernels use it? Why do they prefer reference-counting instead?
On 05/08/2026 10:22 AM, steve g wrote:
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Wed, 29 Jul 2026 16:08:10 -0400, steve g wrote:
Specific substantive response still lacking.
I am actually nor familiar with this. thank you for mentioning it! I
will certainly discuss this with a friend whois Dr Psychology. This will
be a great discussion. seriously I think I can use this to impress him
:)
I'm starting to think Lawrence has a list of words on a piece of paper,
and uses dice to select them for his replies on Usenet. Nothing he says
ever makes sense.
I mean, at least he could do would be to run an L.L.M. and generate the
words for him. It's less work, and doesn't require throwing all these
dice.
I'm starting to think Lawrence has a list of words on a piece of paper,
and uses dice to select them for his replies on Usenet. Nothing he says
ever makes sense.
I mean, at least he could do would be to run an L.L.M. and generate the
words for him. It's less work, and doesn't require throwing all these
dice.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
Now is there some particular book you feel is worth my time in German?
For either studying some C or Lisp arcana? Preferably not some basics,
as those are already covered in English.
my answer would be using ITU (international morse code) and looking at American (or military) CW (continious wave). Many people claim they have learned both from just listening to it on the radio.
Unfortunately radio is all but dead. This is a good thing; less "traffic police".
As to english books I do have an excellent book one of my teachers gave
me. it contains all the funky rules of american enhlish. I am not at
"home" right now so I look it up and I can't remeber the name. She said
just read and re-scim this book before writing papers in college. This
is bothering me now...
I personally think that you need to practice the language to understand
it.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
I'm starting to think Lawrence has a list of words on a piece of paper,
and uses dice to select them for his replies on Usenet. Nothing he says
ever makes sense.
I mean, at least he could do would be to run an L.L.M. and generate the
words for him. It's less work, and doesn't require throwing all these
dice.
I think he (it?) may well *be* an LLM. In particular he (it?) has, at
least twice, done this weird looping thing, asking the same question which has already been answered. That looks like something losing context.
If it wasn't for the fact that usenet is moribund, an obvious way of acquiring training data for LLMs would be to set up troll bots and then use all the human responses to them as training data. Perhaps it's bit as moribund as I thought and someone is in fact doing this.
George Neuner <gneuner2@comcast.net> wrote:
On Thu, 6 Aug 2026 09:05:38 +0200, David Brown
<david.brown@hesbynett.no> wrote:
As for macros in programming languages, AST macros are /not/ the only >>>"sensible" way to have macros.
Depends on your definition of "sensible". <grin>
Do you think that reader macros are sensible?
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 31/07/2026 11:21 PM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
[...]
Sadly we've also ended up with programmers who think the machines
they program for are giant PDP-11s, and as a result machines which >>>>>> spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent >>> fast code that I'd write in C, where speed matters. In other words, I
seem to gain nothing (other than more work) by writing typical
applications in C.
The fun is in writing atypical applications, and then finding yourself
looking at the disassembly in SBCL.
I actually do that every now and then just to learn a bit more about assembly, something I find so cool about SBCL (and lacking in other close-to-the-language tools).
Speaking of which, I decided to try Common Lisp about 2 years ago,
having struggled to deal with Racket for over ten years, nevertheless considering Racket the most elegant Lisp around ever since its birth.
And, boy, did I never look back.
(*) A critique of Racket
To be fair, a big part of my struggle is the thick layer of Racket on
top of POSIX. For instance, try to locate the equivalent select-call on
it. It's so hard to recognize exactly how your Racket maps to the lower level. I understand that may a strong point of Racket's design, but it certainly hits my weakness.
How about the macro system? So perfect, yet so annoying. One thing I
love about Common Lisp is precisely macro's (lack of) hygiene. I'm
totally fine with complete guarantee. Anaphoric macros are so useful.
(No idea how to implement them in Racket---impossible?)
Personally, I love writing in C, even though it's more verbose.
That said, and to be mildly on-topic in comp.lang.lisp, have
* /The Common Lisp Condition System/, and
* /Programming Algorithms in Lisp/
been mentioned before as resources for learning common lisp?
These two books look lovely in my programming shelf, next to
* /Common Lisp Recipes/, and
* /Practical Common Lisp/,
which must have been mentioned. They're interspersed with
* /Low Level Programming/,
* /String Algorithms in C/, and
* /The Joys of Hashing/,
which come in handy when you want to implement your own Common
Lisp system.
Enjoy!
Enjoyed a lot! Thanks so much for sharing very useful references.
Let me try to contribute with
Let Over Lambda
Doug Hoyte, 2008
ISBN 978-1-4357-1275-1
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
To be fair, a big part of my struggle is the thick layer of Racket
on top of POSIX. For instance, try to locate the equivalent
select-call on it. It's so hard to recognize exactly how your Racket
maps to the lower level. I understand that may a strong point of
Racket's design, but it certainly hits my weakness.
Sounds very Java-like. Though perhaps not as irritating as Java.
Compare Python <https://docs.python.org/3/library/select.html> --
thatrCOs less than 10 pages (i.e. number of times I have to hit
Page-Down in the browser) of docs.
Let Over Lambda
Doug Hoyte, 2008
ISBN 978-1-4357-1275-1
This book is about macros, that is programs that write programs.
Macros are what make lisp the greatest programming language in the
world. When used properly, macros enable amazing feats of
abstraction, programmer productivity, and code efficiency and
security that are unheard of elsewhere. Macros let you do things
you simply cannot do in other languages.
Given this is posted to comp.lang.c, itrCOs always worth mentioning
these are not macros in the style of #define, but they work at the AST
level. Which is really the only sensible way to implement a workable
macro system.
And no longer unique to Lisp.
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
(*) A critique of Racket
To be fair, a big part of my struggle is the thick layer of Racket on
top of POSIX. For instance, try to locate the equivalent select-call on
it. It's so hard to recognize exactly how your Racket maps to the lower >level. I understand that may a strong point of Racket's design, but it >certainly hits my weakness.
How about the macro system? So perfect, yet so annoying. One thing I
love about Common Lisp is precisely macro's (lack of) hygiene. I'm
totally fine with complete guarantee. Anaphoric macros are so useful.
(No idea how to implement them in Racket---impossible?)
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
It is so weird that people use a language whose defining feature is the incremental construction of languages and then say they don't use that feature. I mean, I'm aware people do that, but it's just so fucking weird.
Ar an naoi|| l|i de m|! L||nasa, scr|!obh tfb:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> >
> > I've found the Common Lisp macro system annoying enough that I rarely
> > use it. I'm OK with functions most of the time, and CLOS the rest of
> > the time. And only resort to macros when I can't do anything else in
> > the situation.
>
> It is so weird that people use a language whose defining feature is the
> incremental construction of languages and then say they don't use that
> feature. I mean, I'm aware people do that, but it's just so fucking weird.
I donrCOt find macros annoying, but I will use macrolet much more than defmacro.
Usually no point making a utility macro available in the run-time namespace. (This is XEmacs Lisp, so reader macros not available.)
Common Lisp is big and thererCOs plenty worth using in the rest of the language.
Common Lisp is big and thererCOs plenty worth using in the rest of the language.
On Sun, 09 Aug 2026 11:50:07 +0100, Aidan Kehoe wrote:
Common Lisp is big and thererCOs plenty worth using in the rest of the
language.
It leaves out too many things we take for granted in this era of
pretty much universal POSIX availability.
Where are the Common Lisp equivalents of these?
<https://docs.python.org/3/library/subprocess.html> <https://docs.python.org/3/library/threading.html> <https://docs.python.org/3/library/select.html>
On 06/08/2026 6:00 AM, Lawrence DrCOOliveiro wrote:
If garbage collection is so good, why donrCOt high-performance operating
system kernels use it? Why do they prefer reference-counting instead?
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
I think he (it?) may well *be* an LLM.
I try to keep in shape by reading books in languages I'm not using. Or converse with people about programming languages I don't use anymore,
such as Pascal.
I've managed to keep my French more or less intact, but could use a
brush up on Danish, and of course German as I said. I'm sure I'll
find something to inspire me to keep practicing German. After all,
I'm struggling to read Asterisk and Obelisk in Latin.
Best wishes, and happy language studies in comp.lang.lisp!
Do you think that reader macros are sensible?
I've not implemented them in TXR Lisp. It's not that they are
"insensible" or any other epithet.
They have a disruptive effect in the ecosystem.
It is so weird that people use a language whose defining feature is the incremental construction of languages and then say they don't use that feature. I mean, I'm aware people do that, but it's just so fucking weird.
I've never really gotten the hang of when I need to use (gensym) and
and when I don't. If I ever reach those heights of Common Lisp arcana,
I may change my mind and use macros all the time.
Chances are, I won't. I have this feeling that macros should be used as
a last resort, and not as the first /weapon of choice/ when coding Comm-
on Lisp.
Common Lisp is big and thererCOs plenty worth using in the rest of the
language.
Indeed, and QuickLisp makes it bigger. It's perhaps the major reason I
find myself faster at coding certain tasks in Common Lisp than most
other programming languages. Though packages of various types are now commonplace in other common programming languages.
Perhaps the major beauty of the Common Lisp social culture, is the disc- ipline of keeping interfaces stable. As far as I've heard, the /Python-
ic/ interfaces are always in flux, perhaps because their Python is ever writhing? It didn't help when they ditched the syntax of Python 2.7.
Many people whose code got obsolete decided never to use that language
again. And with good reason.
Of course, cultures change, but Common Lisp is eternal. I'm sure we can still code all of our websites with Hunchentoot without ever having the
need to learn something new, several hundred years from now.
Happy coding in Common Lisp!--- Synchronet 3.22a-Linux NewsLink 1.2
To be fair, you need to understand that Racket is multi-platform,
needs to run on Windows, and Windows [for the most part] does not
implement POSIX functions.
Do you think that reader macros are sensible?I've not implemented them in TXR Lisp. It's not that they are
"insensible" or any other epithet.
They have a disruptive effect in the ecosystem.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
It is so weird that people use a language whose defining feature is the incremental construction of languages and then say they don't use that feature. I mean, I'm aware people do that, but it's just so fucking weird.
The question I have is "what argument"?
On Wed, 5 Aug 2026 22:00:45 -0000 (UTC), Lawrence DrCOOliveiro wrote:
If garbage collection is so good, why donrCOt high-performance
operating system kernels use it? Why do they prefer
reference-counting instead?
to be a high performance kernel you should not need to do garbage
collection.
GC is for user space, not kernel space. Kernel developers are
usually very good programmers.
Reader macros have been proposed/requested for ELisp several times, but
we've managed to resist the temptation so far.
It is so weird that people use a language whose defining feature is
the incremental construction of languages and then say they don't use
that feature. I mean, I'm aware people do that, but it's just so
fucking weird.
I admit I'm not sure why the select system call seems to be missing from
this selection of networking functions, so I'm impelled to ask, what is
is that you use select for, in Python?
On 06/08/2026 12:13 AM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 31/07/2026 11:21 PM, Anton Antimo wrote:I actually do that every now and then just to learn a bit more about
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
[...]
Sadly we've also ended up with programmers who think the machines >>>>>>> they program for are giant PDP-11s, and as a result machines which >>>>>>> spend a huge amount of effort pretending to be giant PDP-11s.
It's all a tragedy.
The tragedy is not using Common Lisp for everything.
I loved this bit and I have a feeling you're correct. My little
experience with Common Lisp is that it allows me to write the equivalent >>>> fast code that I'd write in C, where speed matters. In other words, I >>>> seem to gain nothing (other than more work) by writing typical
applications in C.
The fun is in writing atypical applications, and then finding yourself
looking at the disassembly in SBCL.
assembly, something I find so cool about SBCL (and lacking in other
close-to-the-language tools).
Speaking of which, I decided to try Common Lisp about 2 years ago,
having struggled to deal with Racket for over ten years, nevertheless
considering Racket the most elegant Lisp around ever since its birth.
And, boy, did I never look back.
(*) A critique of Racket
To be fair, a big part of my struggle is the thick layer of Racket on
top of POSIX. For instance, try to locate the equivalent select-call on
it. It's so hard to recognize exactly how your Racket maps to the lower
level. I understand that may a strong point of Racket's design, but it
certainly hits my weakness.
How about the macro system? So perfect, yet so annoying. One thing I
love about Common Lisp is precisely macro's (lack of) hygiene. I'm
totally fine with complete guarantee. Anaphoric macros are so useful.
(No idea how to implement them in Racket---impossible?)
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
George Neuner <gneuner2@comcast.net> wrote:
In C the situation is complicated even beyond simply not being able to
find pointers because the standard explicitly permits idioms and code
optimizations that can obscure what pointers are there.
I wonder how the Symbolics C compiler dealt with all this horror? That's
not a rhetorical question: if anyone knows, I'd be interested, because it must have been painful.
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo <anton@safunu.org>
wrote:
(*) A critique of Racket
To be fair, a big part of my struggle is the thick layer of Racket on
top of POSIX. For instance, try to locate the equivalent select-call
on it. It's so hard to recognize exactly how your Racket maps to the
lower level. I understand that may a strong point of Racket's design,
but it certainly hits my weakness.
To be fair, you need to understand that Racket is multi-platform,
needs to run on Windows, and Windows [for the most part] does not
implement POSIX functions.
Racket's network [and filesystem, and ... ] implementation tries to
abstract over equivalent behaviors on all the target platforms.
How about the macro system? So perfect, yet so annoying. One thing I
love about Common Lisp is precisely macro's (lack of) hygiene. I'm
totally fine with complete guarantee. Anaphoric macros are so useful.
(No idea how to implement them in Racket---impossible?)
Racket has its roots in Scheme. Scheme is defined in terms of source
/text/ rather than the compiler's AST. So there is no real equivalent
of Lisp's AST macros.
That said, Racket does support Lisp-like unhygienic macros with 'define-macro'. Apologies for the ridiculous length of the URL.
https://docs.racket-lang.org/compatibility/defmacro.html#%28form._%28%28lib._compatibility%2Fdefmacro..rkt%29._define-macro%29%29
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
I admit I'm not sure why the select system call seems to be missing from
this selection of networking functions, so I'm impelled to ask, what is
is that you use select for, in Python?
Select is used to listening to a bunch of file descriptors
simultaneously and unblocking as soon as data becomes available on one
or more of the fd's. These days it's somewhat superseded by epoll or >io_uring or a few other alternatives.
I actually don't see any of these in the sbcl manual, though maybe I
didn't look hard enough. I'd expect to see it in the streams or
concurrency modules. You could use threads and mailboxes instead, but
that's often overkill, especially with posix threads.
On 06/08/2026 6:00 AM, Lawrence DrCOOliveiro wrote:
If garbage collection is so good, why donrCOt high-performance operating >>> system kernels use it? Why do they prefer reference-counting instead?
to be a high performance kernel you should not need to do garbage
collection. GC is for user space, not kernel space. Kernel developers
are usually very good programmers.
On 07/08/2026 7:36 AM, steve g wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
Now is there some particular book you feel is worth my time in German?
For either studying some C or Lisp arcana?-a Preferably not some basics, >>> as those are already covered in English.
my answer would be using ITU (international morse code) and looking at
American (or military) CW (continious wave). Many people claim they have
learned both from just listening to it on the radio.
Unfortunately radio is all but dead. This is a good thing; less "traffic
police".
As to english books I do have an excellent book one of my teachers gave
me. it contains all the funky rules of american enhlish. I am not at
"home" right now so I look it up and I can't remeber the name. She said
just read and re-scim this book before writing papers in college. This
is bothering me now...
I personally think that you need to practice the language to understand
it.
I try to keep in shape by reading books in languages I'm not using.-a Or converse with people about programming languages I don't use anymore,
such as Pascal.
I've managed to keep my French more or less intact, but could use a
brush up on Danish, and of course German as I said.-a I'm sure I'll
find something to inspire me to keep practicing German.-a After all,
I'm struggling to read Asterisk and Obelisk in Latin.
Best wishes, and happy language studies in comp.lang.lisp!
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
I admit I'm not sure why the select system call seems to be missing from
this selection of networking functions, so I'm impelled to ask, what is
is that you use select for, in Python?
Select is used to listening to a bunch of file descriptors
simultaneously and unblocking as soon as data becomes available on one
or more of the fd's. These days it's somewhat superseded by epoll or io_uring or a few other alternatives.
I actually don't see any of these in the sbcl manual, though maybe I
didn't look hard enough. I'd expect to see it in the streams or
concurrency modules. You could use threads and mailboxes instead, but
that's often overkill, especially with posix threads.
I see a mention of:
*Recursive Event Loop*: SBCL provides a recursive event loop
(serve-event) for doing non-blocking IO on multiple streams without
using threads.
But I don't see anything more about that in the manual. There's a
reddit thread saying it's poorly supported:
https://old.reddit.com/r/Common_Lisp/comments/kdk6mq/how_to_use_serveevent_from_sbcl/
Anyway that is basically what select is for.
On 06/08/2026 5:48 AM, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
To be fair, a big part of my struggle is the thick layer of RacketSounds very Java-like. Though perhaps not as irritating as Java.
on top of POSIX. For instance, try to locate the equivalent
select-call on it. It's so hard to recognize exactly how your Racket
maps to the lower level. I understand that may a strong point of
Racket's design, but it certainly hits my weakness.
Compare Python <https://docs.python.org/3/library/select.html> --
thatrCOs less than 10 pages (i.e. number of times I have to hit
Page-Down in the browser) of docs.
I admit I'm not sure why the select system call seems to be missing from
this selection of networking functions, [...]
For select (called unix-fast-select in SBCL), see sb-unix.
I think in terms of POSIX---likely because I started there.
On Thu, 06 Aug 2026 19:25:26 -0400, steve g wrote:
The question I have is "what argument"?
Since you mentioned MicrosoftrCOs Singularity, letrCOs look in a bit
more detail at it, shall we?
It was some kind of OS rCLresearch projectrCY. rCLLetrCOs build yet another microkernelrCY, they thought. As if that wasnrCOt a bad enough idea, they also thought rCLletrCOs include garbage collection in the kernelrCY. Perhaps two sufficiently bad ideas, mashed together sufficiently thoroughly,
will add up to something good?
So what came out of that research project? Nothing, that I can see. It
was abandoned, and then disappeared without leaving any trace on the
world of computer science.
Can you find some published papers on it?
Do they say anything more than rCLthis is not something that should be
tried againrCY?
Because if you go to the website, the link to the downloadable
software disappears off into the ether.
Feel free to prove me wrong. But somehow I donrCOt think you would know
where to start.
Of course, you could always regurgitate some AI slop, if you think it
will help ...
On Sun, 09 Aug 2026 18:42:29 -0400, steve g wrote:
On Wed, 5 Aug 2026 22:00:45 -0000 (UTC), Lawrence DrCOOliveiro wrote:
If garbage collection is so good, why donrCOt high-performance
operating system kernels use it? Why do they prefer
reference-counting instead?
to be a high performance kernel you should not need to do garbage
collection.
But isnrCOt that supposed to be better than reference-counting? Offering higher performance or something?
GC is for user space, not kernel space. Kernel developers are
usually very good programmers.
Do different laws of physics apply in kernel space or something?
And/or is that an admission that garbage collection is not for rCLvery
good programmersrCY?
And by the way some of my complains can also be exactly applied to
Common Lisp. For instance, I think Common Lisp doesn't have the
semantics of POSIX's read(2). I suppose there are libraries out there
that might go lower level (than Common Lisp's) and then give you an abstraction that mimics read(2), but that's beside the point.
On Sun, 09 Aug 2026 18:42:29 -0400, steve g wrote:
[...] GC is for user space, not kernel space. Kernel developers are usually very good programmers.
Do different laws of physics apply in kernel space or something?
And/or is that an admission that garbage collection is not for rCLvery
good programmersrCY?
Ar an deichi|| l|i de m|! L||nasa, scr|!obh Lawrence DrCOOliveiro:
On Sun, 09 Aug 2026 18:42:29 -0400, steve g wrote:
[...] GC is for user space, not kernel space. Kernel developers are usually very good programmers.
Do different laws of physics apply in kernel space or something?
And/or is that an admission that garbage collection is not for rCLvery good programmersrCY?
Let me digress for a moment:
Within medicine, my day job, [...]
This would require essentially assembler written with the quality of
the Apollo code, without an operating system. (IrCOm sure everyone
reading this accepts that good assembler, if it has no bugs, is going
to make better use of the hardware than their language of choice.)
The trade-off is that the resulting software is slower than the above
ideal, and, e.g. that my Windows install decides that it is going to
update whether I like it or not and the Cygwin terminal that I had
open, in the middle of debugging something, with a command history
that I would ideally like to have kept, evaporates.
On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
For select (called unix-fast-select in SBCL), see sb-unix.
select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll() ><https://manpages.debian.org/poll(2)> (POSIX) or even epoll() ><https://manpages.debian.org/epoll(7)> (Linux-specific).
tfb <tfb@work.it.out> writes:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
I think he (it?) may well *be* an LLM.
I was asked a psychiatrist what an LLM is. Large Language Model makes no >sense. What is behind this LLM, neural nets? I was thkng that semantic
nets. How do I go about writing an LLM, no I do not want to use one; I
want to write one (list is comp.lang.lisp afterall).
George Neuner <gneuner2@comcast.net> writes:
To be fair, you need to understand that Racket is multi-platform,
needs to run on Windows, and Windows [for the most part] does not
implement POSIX functions.
Can you use CYGwin? it is a bit ugly but it is POSIX. Microsoft should
be able to introduce a POSIX level (xyz) rather easily; they just don't
do that. It's like the Xterminal.
dunno, I cannot use windows 11; it needs a credit card. God bless the--- Synchronet 3.22a-Linux NewsLink 1.2
Free Software Project!
George Neuner <gneuner2@comcast.net> writes:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo <anton@safunu.org>
wrote:
How about the [Racket] macro system? So perfect, yet so annoying.
One thing I love about Common Lisp is precisely macro's (lack of) >>>hygiene. I'm totally fine with complete guarantee. Anaphoric
macros are so useful. (No idea how to implement them in Racket >>>---impossible?)
Racket has its roots in Scheme. Scheme is defined in terms of source
/text/ rather than the compiler's AST. So there is no real equivalent
of Lisp's AST macros.
Interesting. I bet this has been one my major difficulties because I had >never quite understood that and I probably still don't. I had realized
I always needed to manipulate the syntax objects as opposed to sexps and
it was always confusing to insert a new identifier into the generating
code and so on. The blame is of course always on me, but >yeah---difficult-to-understand stuff. Common Lisp is a lot simpler, I
feel. (Let me also say that I was never able to understand Scheme
compilers' error messages, Racket included.)
Is there an article out there that elaborate your paragraph here? I'd
like to learn more about these differences. I suppose the Scheme people >would have very strong arguments to go their way.
--- Synchronet 3.22a-Linux NewsLink 1.2That said, Racket does support Lisp-like unhygienic macros with
'define-macro'. Apologies for the ridiculous length of the URL.
https://docs.racket-lang.org/compatibility/defmacro.html#%28form._%28%28lib._compatibility%2Fdefmacro..rkt%29._define-macro%29%29
We need a project that can promise to shorten and maintain URLs for 50
years, say. (I say fifty so a single hacker can keep it running during
his lifetime. After 50 years, a young hacker takes it on for another
50.) It'a pity that Google Inc. let us down with goo.gl.
Aidan Kehoe <kehoea@parhasard.net> writes:
Ar an deichi|| l|i de m|! L||nasa, scr|!obh Lawrence DrCOOliveiro:
On Sun, 09 Aug 2026 18:42:29 -0400, steve g wrote:
[...] GC is for user space, not kernel space. Kernel developers are usually very good programmers.
Do different laws of physics apply in kernel space or something? And/or is that an admission that garbage collection is not for rCLvery good programmersrCY?
Let me digress for a moment:
Within medicine, my day job, [...]
Very cool that we have people from areas such as medicine here. (In reality, there's no academic discipline called programming---people in Computer Science are more often than not not programmers at all.) Medicine, in particular, is an unexpected one. Can you share a bit more about your history as in how did you get interested in medicine and computers (and Lisp specially)? That'd be cool to hear. (Assuming a little social chat is acceptable here given the current low volume.)
This would require essentially assembler written with the quality of
the Apollo code, without an operating system. (IrCOm sure everyone
reading this accepts that good assembler, if it has no bugs, is going
to make better use of the hardware than their language of choice.)
Perfectly reasonable.
The trade-off is that the resulting software is slower than the above ideal, and, e.g. that my Windows install decides that it is going to update whether I like it or not and the Cygwin terminal that I had
open, in the middle of debugging something, with a command history
that I would ideally like to have kept, evaporates.
Isn't that irritating? Windows is a system that's really not very respectful at all with what the user is doing---lots of interruptions
such as alerts by Windows Defender and whatnot. Many other programmers
on Windows follow suit, so it's not Microsoft's fault completely. And
that might be the same thing in the usual GNU system these days. For
window management, I run CWM, which is one that really only lets
anything happen that the user has actively made it happen.
And speaking of Medicine, how is it disrespectful these days as well,
but I won't digress on this (and it's perhaps just something that
plagues the entirety of society).
|--------------------------------------------------------|
|"degree from the best university in my country, [. . .]"| |--------------------------------------------------------|
arsa Aodh|in ua Ciothaigh ar an 11|| l|i de mh|! L||nasa 2026.
Chan in |eirinn d'ollscoil ar bith!
|------------------------------------------------------------------------------|
|"If there were no resource constraints, a fully informed user aware of what is|
|possible would like bug-free software that does exactly what is desired as |
|quickly as the hardware can do it. |
| |
|[. . .] |
|Operating systems, [. . .] are all examples |
|of tools that make programming [. . .] less likely to have bugs." |
|------------------------------------------------------------------------------|
arsa Aodh|in || Ceoth|inaigh ar an 11|| l|i de mh|! L||nasa 2026.
Windows is buggy.
|------------------------------------------------------------------------------|
|"This means that the cost ([. . .] often in money) of developing software to |
|do a given thing goes down. [. . .] |
|[. . .] |
| |
|[. . .] |
|[. . .] my Windows install decides that it is going to update whether I |
|like it or not" |
|------------------------------------------------------------------------------|
arsa Aodh|in || Ciothaigh ar an 11|| l|i de mh|! L||nasa 2026.
A license for Windows costs money.
|------------------------------------------------------------------------------|
|"and the Cygwin terminal that I had open, in the middle of |
|debugging something, with a command history that I would ideally like to have |
|kept, evaporates." |
|------------------------------------------------------------------------------|
arsa Aodh|in mac Eochadha ar an 11|| l|i de mh|! L||nasa 2026.
Is BASh on Windoze without its features on gratis operating systems?
Is mise le meas,--
Niocl|iis|!n C||il|!n Glost|-ir
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
tfb <tfb@work.it.out> writes:
It is so weird that people use a language whose defining feature is
the incremental construction of languages and then say they don't use
that feature. I mean, I'm aware people do that, but it's just so
fucking weird.
For a long time, Scheme didn't have macros, but it was still considered
cool.
Lisp macros are generally a way for user code to get hold of unevaluated
args in a sexp. If your language has lazy evaluation (Haskell) and/or syntactic support for your likely macro use cases (lots of languages),
macros become less important.
As Lispers like to say, syntax is no big
deal. So why obsess about being able to redefine it?
|Hmm? The University of Dublin, founded 1592 by Queen Elizabeth as Trinity| |College Dublin, four Nobel laureates, alumni including Samuel Beckett, | |Oscar Wilde, Denis Burkitt of BurkittrCOs lymphoma is not a university?" |
|-------------------------------------------------------------------------| arsa Aodh P||l ua Ceoth|inaigh.
Dar liom!
|-------------------------------------------------------------------------| |"Where did | |you study[. . .]?" | |-------------------------------------------------------------------------| arsa Aodh|in ua Ciothaigh.
Le deirfi||r daoibh.
Is mise le meas,
On So 09 Aug 2026 at 05:26, Johann 'Myrkraverk' Oskarsson wrote:
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
That us exactly where it should be used - when there is no other way.
On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
For select (called unix-fast-select in SBCL), see sb-unix.
select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll() <https://manpages.debian.org/poll(2)> (POSIX) or even epoll() <https://manpages.debian.org/epoll(7)> (Linux-specific).
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 06/08/2026 5:48 AM, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
To be fair, a big part of my struggle is the thick layer of RacketSounds very Java-like. Though perhaps not as irritating as Java.
on top of POSIX. For instance, try to locate the equivalent
select-call on it. It's so hard to recognize exactly how your Racket
maps to the lower level. I understand that may a strong point of
Racket's design, but it certainly hits my weakness.
Compare Python <https://docs.python.org/3/library/select.html> --
thatrCOs less than 10 pages (i.e. number of times I have to hit
Page-Down in the browser) of docs.
I admit I'm not sure why the select system call seems to be missing from
this selection of networking functions, [...]
It would be like writing C in Lisp notation. For select (called unix-fast-select in SBCL), see sb-unix.
(defun wait-for-stdin-select ()
(sb-alien:with-alien ((read-fds (sb-alien:struct sb-unix:fd-set)))
(sb-unix:fd-zero read-fds)
(sb-unix:fd-set 0 read-fds)
(format t "Waiting up to 5 seconds for input on stdin... Type something!~%")
(force-output)
(multiple-value-bind (count err)
(sb-unix:unix-fast-select 1 (sb-alien:addr read-fds) nil nil 5 0)
(cond
((null count)
(format t "Select failed with errno: ~A~%" err))
((zerop count)
(format t "Timeout! No input received.~%"))
((sb-unix:fd-isset 0 read-fds)
(format t "Data is ready to be read from stdin!~%"))
(t
(format t "Something else woke up select!~%"))))))
;; run it
(wait-for-stdin-select)
Is BASh on Windoze without its features on gratis operating systems?
This would require essentially assembler written with the quality of
the Apollo code, without an operating system.
For me, garbage collection as it is actually implemented (I would
phrase this -+real existierende Garbage-Collection-2 in German, by
analogy with -+real existierender Sozialismus) has a non-negligible
runtime cost. This is usually acceptable but sometimes not.
If you use any emacs itrCOs hard to avoid Lisp. Emacs Lisp is not a
paragon of good design nor of good implementation-- (aset
(symbol-name nil) 0 ?\u0192) , (fillarray obarray 0) , anyone?--so
the natural thing is to look around for something better. The
consensus within XEmacs was that Common Lisp was better. On
investigating, yes, it is.
Even if the update process is manual, e.g. when IrCOm using Debian and migrating a server to a new VM, I do not actually want to spend my
time working out with trial and error what invocation of certbot
will allow me to put Letsencrypt certificates on a new server that
already has Apache installed. (Spoiler; spin down Apache, use
certbot --certonly, which spins up its own HTTP server.)
(I certainly donrCOt want to have to migrate well-written PHP of
twenty years ago that carefully wrapped access to a database using then-best-practice APIs because those APIs are unmaintained and
removed, but that is entirely on me, we all know PHP is terrible,
and I knew it then.
Ar an deichi|| l|i de m|! L||nasa, scr|!obh Lawrence DrCOOliveiro:
On Sun, 09 Aug 2026 18:42:29 -0400, steve g wrote:
[...] GC is for user space, not kernel space. Kernel developers are usually very good programmers.
Do different laws of physics apply in kernel space or something?
And/or is that an admission that garbage collection is not for rCLvery good programmersrCY?
Let me digress for a moment:
Within medicine, my day job, decision making should be and mostly is (absent resource constraints) guided by what is right for the patient.
(This sounds obvious but it does need to be re-emphasised and
re-emphasised as part of training, because it is not always intuitive
in the details of every decision made. Every six year old who bumps
his or her head should not have a CT brain, for example.) Now, you can obviously ask patients (or parents in that last example) what they
feel would be right for the patient, and that is often helpful, but it
is not the case that every patient has thought through every specific clinical situation before, and it is not the case that every patient
has an informed command of the relevant research.
In practice, you have to develop a mental picture of what is right for almost everyone. Practically no-one wants to die young (and if they do, practically none of their family members want them to die young, and practically no-one continues to want to die young once the twelve Buckfasts have worn off or their
depression is treated). Practically everyone wants to continue to be able to walk. Practically everyone wants to continue to have control of their bowels and bladders. Practically no-one wants to have dementia. No-one wants to die of
metastatic cancer. Frail people in their high eighties may not want colonoscopy
if they have a change to their bowel habit with some blood in their stool, and,
if they are unlikely to be fit for treatment of any bowel cancer that is found,
that is very reasonable and it is not a good use of time to attempt to talk them round to the investigation.
This becomes more important when the patient is not paying directly for their care (they are paying through their taxes, or they have health insurance), since the body that pays for the care is incentivised to minimise investigations and management. If you are employed directly by the body that pays for care part of the job is, often and effectively, to market the investigations and management as necessary to other people in the organisation.
Digression ended.
When I returned to software I found it helpful, by analogy to rCLwhat is right
for the patientrCY above, to consider what is right for the end user.
If there were no resource constraints, a fully informed user aware of what is possible would like bug-free software that does exactly what is desired as quickly as the hardware can do it.
This would require essentially assembler written with the quality of the Apollo
code, without an operating system. (IrCOm sure everyone reading this accepts that
good assembler, if it has no bugs, is going to make better use of the hardware
than their language of choice.) This is not going to happen, because we have resource constraints; no-one is going to pay for that. But itrCOs helpful to keep it in mind as a possibility.
Operating systems, virtual memory, and non-assembler languages are all examples
of tools that make programming less demanding and less likely to have bugs. This means that the cost (in time and often in money) of developing software to
do a given thing goes down. Portable non-assembler languages have the additional advantage that the development time can be amortised over multiple generations of hardware, reducing the cost further.
The trade-off is that the resulting software is slower than the above ideal, and, e.g. that my Windows install decides that it is going to update whether I
like it or not and the Cygwin terminal that I had open, in the middle of debugging something, with a command history that I would ideally like to have kept, evaporates.
The question just becomes what point in the trade-off of increasing development
time versus decreasing does-exactly-what-I-want-making-best-use-of-the-hardware
a given piece of software should make.
For me, garbage collection as it is actually implemented (I would phrase this -+real existierende Garbage-Collection-2 in German, by analogy with -+real existierender Sozialismus) has a non-negligible runtime cost. This is usually acceptable but sometimes not.
Aidan Kehoe <kehoea@parhasard.net> writes:
Ar an deichi|| l|i de m|! L||nasa, scr|!obh Lawrence DrCOOliveiro:
On Sun, 09 Aug 2026 18:42:29 -0400, steve g wrote:
[...] GC is for user space, not kernel space. Kernel developers are
usually very good programmers.
Do different laws of physics apply in kernel space or something?
And/or is that an admission that garbage collection is not for rCLvery
good programmersrCY?
Let me digress for a moment:
Within medicine, my day job, [...]
Very cool that we have people from areas such as medicine here. (In
reality, there's no academic discipline called programming---people in Computer Science are more often than not not programmers at all.)
Medicine, in particular, is an unexpected one. Can you share a bit more about your history as in how did you get interested in medicine and
computers (and Lisp specially)? That'd be cool to hear. (Assuming a
little social chat is acceptable here given the current low volume.)
This would require essentially assembler written with the quality of
the Apollo code, without an operating system. (IrCOm sure everyone
reading this accepts that good assembler, if it has no bugs, is going
to make better use of the hardware than their language of choice.)
Perfectly reasonable.
The trade-off is that the resulting software is slower than the above
ideal, and, e.g. that my Windows install decides that it is going to
update whether I like it or not and the Cygwin terminal that I had
open, in the middle of debugging something, with a command history
that I would ideally like to have kept, evaporates.
Isn't that irritating? Windows is a system that's really not very
respectful at all with what the user is doing---lots of interruptions
such as alerts by Windows Defender and whatnot. Many other programmers
on Windows follow suit, so it's not Microsoft's fault completely. And
that might be the same thing in the usual GNU system these days. For
window management, I run CWM, which is one that really only lets
anything happen that the user has actively made it happen.
And speaking of Medicine, how is it disrespectful these days as well,
but I won't digress on this (and it's perhaps just something that
plagues the entirety of society).
once the twelve Buckfasts have worn off
Suppressing evaluation is not the same thing as delaying evaluation.
https://man.freebsd.org/cgi/man.cgi?kqueue
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
https://man.freebsd.org/cgi/man.cgi?kqueue
Is this something like io_uring? Is it just for i/o on open fd's or can
you also use it for stuff like opening files?
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
It is so weird that people use a language whose defining feature is the incremental construction of languages and then say they don't use that feature. I mean, I'm aware people do that, but it's just so fucking weird.
On 12/08/2026 11:59 AM, Paul Rubin wrote:
Is this something like io_uring? Is it just for i/o on open fd's or canThe kqueue() is for open file descriptors, created as sockets or open
you also use it for stuff like opening files?
files, or anything else the FreeBSD kernel decides is a file. I'm not
aware of any interface to create one and open a file with the same func-
tion call.
I _think_ what Paul was asking was is it possible to get notified
when a specific file in the file system is opened. If that's what
he's asking, then the answer is: yes kqueue/kevent can do that. You
open the file in question using O_PATH, and then create a kevent
using that descriptor with filter EVFILT_VNODE and event NOTE_OPEN.
On 09/08/2026 4:52 PM, tfb wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:No the subject of /weird/, I've also found it highly bizarre, if not
outright disturbing, that people don't use do ... while(); in C. It's
an eminently useful structured programming pattern.
On the subject of Common Lisp, I find it more than disturbing when a
codebase lacks the basic usage of hash tables.
https://www.sbcl.org/manual/#hash-table-extensions
I _think_ what Paul was asking was is it possible to get notified when a specific file in the file system is opened.
On 11/08/2026 4:41 AM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 06/08/2026 5:48 AM, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
To be fair, a big part of my struggle is the thick layer of RacketSounds very Java-like. Though perhaps not as irritating as Java.
on top of POSIX. For instance, try to locate the equivalent
select-call on it. It's so hard to recognize exactly how your Racket >>>>> maps to the lower level. I understand that may a strong point of
Racket's design, but it certainly hits my weakness.
Compare Python <https://docs.python.org/3/library/select.html> --
thatrCOs less than 10 pages (i.e. number of times I have to hit
Page-Down in the browser) of docs.
I admit I'm not sure why the select system call seems to be missing from >>> this selection of networking functions, [...]
It would be like writing C in Lisp notation. For select (called
unix-fast-select in SBCL), see sb-unix.
(defun wait-for-stdin-select ()
(sb-alien:with-alien ((read-fds (sb-alien:struct sb-unix:fd-set)))
(sb-unix:fd-zero read-fds)
(sb-unix:fd-set 0 read-fds)
(format t "Waiting up to 5 seconds for input on stdin... Type something!~%")
(force-output)
(multiple-value-bind (count err)
(sb-unix:unix-fast-select 1 (sb-alien:addr read-fds) nil nil 5 0) >> (cond
((null count)
(format t "Select failed with errno: ~A~%" err))
((zerop count)
(format t "Timeout! No input received.~%"))
((sb-unix:fd-isset 0 read-fds)
(format t "Data is ready to be read from stdin!~%"))
(t
(format t "Something else woke up select!~%"))))))
;; run it
(wait-for-stdin-select)
Thank you. This is indeed helpful.
Unhelpfully, Lawrence is always talking about some sort of select in
Python, and then talks about polling in Linux, when he knows we don't
care about the Linux kernel here in comp.lang.lisp, because the Steel
Banks Common Lisp encapsulates the kernel for us.
And no, I don't know why Lawrence is always pretending to be a Python influencer here in comp.lang.lisp. I hope he's getting paid for it.
I liked the idea of
(with-current-readtable (xyz)
...)
using macros to enhance performance is usually a bad idea.
using macros to enhance performance is usually a bad idea.
Why should it be termed "weird" at all? Is this one of these things
where somebody comes up with a definition of the "normal" way to do
things and points fingers at anyone who deviates from that? Or is macro system usage somehow mandatory for Lisp programming?
For a long time, Scheme didn't have macros, but it was still considered
cool.
Lisp macros are generally a way for user code to get hold of unevaluated
args in a sexp.
If your language has [...]
syntactic support for your likely macro use cases (lots of languages),
macros become less important.
As Lispers like to say, syntax is no big
deal. So why obsess about being able to redefine it?
The Apollo code *did* have an operating system. And remember, it
crashed twice during the Apollo 11 landing. And got very confused by
that lightning strike during the Apollo 12 launch.
(I certainly donrCOt want to have to migrate well-written PHP of | twenty years ago that carefully wrapped access to a database using | then-best-practice APIs because those APIs are unmaintained and | removed, but that is entirely on me, we all know PHP is terrible, || |
and I knew it then. |
A very long time ago, Lisp had many unique features. Today it has exactly >one, but that feature is critical. It just seems weird to me to ignore its >defining characteristic. Not wrong: weird.
On Mon, 10 Aug 2026 10:48:48 -0300, Anton Antimo <anton@safunu.org>
wrote:
George Neuner <gneuner2@comcast.net> writes:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo <anton@safunu.org>
wrote:
How about the [Racket] macro system? So perfect, yet so annoying.
One thing I love about Common Lisp is precisely macro's (lack of) >>>>hygiene. I'm totally fine with complete guarantee. Anaphoric
macros are so useful. (No idea how to implement them in Racket >>>>---impossible?)
Racket has its roots in Scheme. Scheme is defined in terms of source
/text/ rather than the compiler's AST. So there is no real equivalent
of Lisp's AST macros.
:
Is there an article out there that elaborate your paragraph here? I'd
like to learn more about these differences. I suppose the Scheme people >>would have very strong arguments to go their way.
:
It is implicit in the semantics sections of the R_RS documents. Might
be explicit in some of them, I don't recall - the earlier documents
tended to contain more detail about intent, but I haven't (re)read any
of them in ages. I'm sure I've seen it explicitly stated somewhere,
but it may have been in some book.
[One of my college professors was Mitchell Wand who co-wrote
"Essentials of Programming Languages" and served on the Scheme
defining committee for many years.]
TLDR; Scheme's formal semantics are based on the syntax of forms in
the /external/ representation - ie. the source text - not on any
compiler's internal representation.
Reddit concluded that with macros they were now supposed to learn
to read several entirely unique, personalized programming languages,
and preferred to rewrite their system in Python.
R6RS has in Appendix (A) a discussion of the formal semantics in which
they do state that Scheme's denotation semantics are based on
/strings/. Unfortunately the statement is offhand and the discussion
itself is non-normative.
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
Reddit concluded that with macros they were now supposed to learnIf that's a problem for you, I'd suggest doing the same. But, if this was >the reason (fully willing to believe it was the reason)
to read several entirely unique, personalized programming languages,
and preferred to rewrite their system in Python.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
https://man.freebsd.org/cgi/man.cgi?kqueue
Is this something like io_uring? Is it just for i/o on open fd's or can
you also use it for stuff like opening files?
Aidan Kehoe <kehoea@parhasard.net> writes:
once the twelve Buckfasts have worn off
I had to look that up. Wow, that's the medicine we all need, lol.
https://en.wikipedia.org/wiki/Buckfast_Tonic_Wine
Alan Bawden <alan@csail.mit.edu> writes:
I _think_ what Paul was asking was is it possible to get notified when a
specific file in the file system is opened.
No in linux that's called inotify. io_uring is basically an alternative system call interface that's relatively new, and maybe not complete.
You send off a request to do the system call, and get back a queued
response when the call is completed, unlike traditional syscalls that
appear to be synchronous.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 11/08/2026 4:41 AM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 06/08/2026 5:48 AM, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
To be fair, a big part of my struggle is the thick layer of Racket >>>>>> on top of POSIX. For instance, try to locate the equivalentSounds very Java-like. Though perhaps not as irritating as Java.
select-call on it. It's so hard to recognize exactly how your Racket >>>>>> maps to the lower level. I understand that may a strong point of
Racket's design, but it certainly hits my weakness.
Compare Python <https://docs.python.org/3/library/select.html> --
thatrCOs less than 10 pages (i.e. number of times I have to hit
Page-Down in the browser) of docs.
I admit I'm not sure why the select system call seems to be missing from >>>> this selection of networking functions, [...]
It would be like writing C in Lisp notation. For select (called
unix-fast-select in SBCL), see sb-unix.
(defun wait-for-stdin-select ()
(sb-alien:with-alien ((read-fds (sb-alien:struct sb-unix:fd-set)))
(sb-unix:fd-zero read-fds)
(sb-unix:fd-set 0 read-fds)
(format t "Waiting up to 5 seconds for input on stdin... Type something!~%")
(force-output)
(multiple-value-bind (count err)
(sb-unix:unix-fast-select 1 (sb-alien:addr read-fds) nil nil 5 0) >>> (cond
((null count)
(format t "Select failed with errno: ~A~%" err))
((zerop count)
(format t "Timeout! No input received.~%"))
((sb-unix:fd-isset 0 read-fds)
(format t "Data is ready to be read from stdin!~%"))
(t
(format t "Something else woke up select!~%"))))))
;; run it
(wait-for-stdin-select)
Thank you. This is indeed helpful.
But don't assume I'd ever write something like that in Lisp. Again,
that's like C programming in Lisp notation. See IOLib, for example.
Unhelpfully, Lawrence is always talking about some sort of select in
Python, and then talks about polling in Linux, when he knows we don't
care about the Linux kernel here in comp.lang.lisp, because the Steel
Banks Common Lisp encapsulates the kernel for us.
No sarcasm here. Lawrence has been doing a great service to the current USENET. We can say whatever we want about his knowledge or opinions or whatever, but he keeps a lot of people distracted here and I'm sure
these people are all looking for a distraction. And his distractions
are not all inadequate. He's usually bring up on-topic things that
allows people here to exercise their own skills. If these contributions
are too shallow---well---I'd say that's something we can say about most USENET traffic these days. Because we're very low volume these days, I
think shallow contributions are better than nothing. I prefer the
shallow chat than no chat at all.
And no, I don't know why Lawrence is always pretending to be a Python
influencer here in comp.lang.lisp. I hope he's getting paid for it.
From what I can tell, Lawrence never really caught the Lisp culture---it
can be seen in how he writes Lisp in the occasion he does it. This
means his criticism aren't very serious. He loves Python, which is a
way of saying---``thanks, Lisp, for the things you've done for me.''
On Wed, 12 Aug 2026 03:23:45 -0400, Alan Bawden wrote:
I _think_ what Paul was asking was is it possible to get notified
when a specific file in the file system is opened. If that's what
he's asking, then the answer is: yes kqueue/kevent can do that. You
open the file in question using O_PATH, and then create a kevent
using that descriptor with filter EVFILT_VNODE and event NOTE_OPEN.
There is no POSIX API for this. Linux has inotify(7) for watching
particular files, and certain kinds of directory operations, and
fanotify(7) for more general watching of entire
directories/filesystems.
<https://manpages.debian.org/inotify(7)> <https://manpages.debian.org/fanotify(7)>
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 12/08/2026 11:59 AM, Paul Rubin wrote:
Is this something like io_uring? Is it just for i/o on open fd's or can >>> you also use it for stuff like opening files?The kqueue() is for open file descriptors, created as sockets or open
files, or anything else the FreeBSD kernel decides is a file. I'm not
aware of any interface to create one and open a file with the same func-
tion call.
I _think_ what Paul was asking was is it possible to get notified when a specific file in the file system is opened. If that's what he's asking,
then the answer is: yes kqueue/kevent can do that. You open the file in question using O_PATH, and then create a kevent using that descriptor
with filter EVFILT_VNODE and event NOTE_OPEN.
So I believe we need more books about Common Lisp. Especially how to
make production games in Common Lisp.
WordPress. Ugh!
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
So I believe we need more books about Common Lisp. Especially how to
make production games in Common Lisp.
I mentioned Land of Lisp a couple days ago. Its sample programs are
games, if that helps. They're closer to Hunt the Wumpus than to a
modern AAA game, but it's a start.
You might also like Tim Sweeney's old slide deck about a hypothetical
new language for game dev:
https://groups.csail.mit.edu/cag/crg/papers/sweeney06games.pdf
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
So I believe we need more books about Common Lisp. Especially how to
make production games in Common Lisp.
I mentioned Land of Lisp a couple days ago. Its sample programs are
games, if that helps. They're closer to Hunt the Wumpus than to a
modern AAA game, but it's a start.
Hello everyone!
I want to learn Common Lisp, but I don't really know what resources to
use.
What did you all use to learn? Is that even relevant? Is this newsgroup active?
On Sun, 02 Aug 2026 16:42:37 +0000, kotorifan wrote:
For learning the basics about the language I highly recommend the
book "Practical Common Lisp" by Peter Seibel.
Common Lisp is a museum-worthy spec by this point. There needs to be something more modern, not so full of legacy baggage tied to old, proprietary, pre-POSIX OS platforms which are all extinct by now.
Also it does help to have a background in Emacs Lisp ...
Emacs Lisp contains some useful functionality beyond that specified by
Common Lisp, but it still isnrCOt really enough for a general-purpose programming language. Not in this day and age.
Ar an t-aon|| l|i d|-ag de m|! L||nasa, scr|!obh Anton Antimo:
Aidan Kehoe <kehoea@parhasard.net> writes:
Ar an deichi|| l|i de m|! L||nasa, scr|!obh Lawrence DrCOOliveiro:
On Sun, 09 Aug 2026 18:42:29 -0400, steve g wrote:
[...] GC is for user space, not kernel space. Kernel developers are usually very good programmers.
Do different laws of physics apply in kernel space or something? And/or
is that an admission that garbage collection is not for rCLvery good programmersrCY?
Let me digress for a moment:
Within medicine, my day job, [...]
Very cool that we have people from areas such as medicine here. (In reality,
there's no academic discipline called programming---people in Computer Science are more often than not not programmers at all.) Medicine, in particular, is an unexpected one. Can you share a bit more about your history as in how did you get interested in medicine and computers (and Lisp
specially)? That'd be cool to hear. (Assuming a little social chat is acceptable here given the current low volume.)
My first degree was 1998-2002 and the professor (clearly taking
shelter from the first AI winter) assigned the GNU Emacs manual as
required reading for the first class. (This is, I understand, not
typical.)
At that point XEmacs was a better editor so after using GNU Emacs for
a few weeks I switched to XEmacs. It still meets my needs and I have
no plan to switch away from it.
2002 was the Dot Com bust, and after six months unemployment following
a 2.1 degree from the best university in my country, I ended up in
technical support. To my surprise, I really enjoyed solving peoplerCOs problems then and there. Continued working in IT here in Europe (got
out of technical support given it was clear that was moving to India,
was in software development roles) realised I was not going to be able
to comfortably raise a family in the roles I was doing.
2007 my parents pointed me towards a new rCLGraduate Entry MedicinerCY
course in Dublin, on the US model of requiring another degree but
being only four years in length; I realised from the technical support experience that I would likely enjoy the day-to-day of this, and you
can comfortably raise a family in medicine in Ireland.
Studied medicine 2008-2012, worked like a demon 2013-2021, and am no
longer at the point where I have to work and study relentlessly to
make forward progress. Very happy with the job and with my
day-to-day, and I finally have a bit of breathing space to be back on
Usenet.
If you use any emacs itrCOs hard to avoid Lisp. Emacs Lisp is not a paragon of
good design nor of good implementation-- (aset (symbol-name nil) 0 ?\u0192) , (fillarray obarray 0) , anyone?--so the natural thing is to look around for something better. The consensus within XEmacs was that Common Lisp was better.
On investigating, yes, it is. But, XEmacs needs work, no-one else is doing it,
so my software work these days is C with a very Common-Lisp-oriented Emacs Lisp.
This would require essentially assembler written with the quality of
the Apollo code, without an operating system. (IrCOm sure everyone reading this accepts that good assembler, if it has no bugs, is going
to make better use of the hardware than their language of choice.)
Perfectly reasonable.
The trade-off is that the resulting software is slower than the above ideal, and, e.g. that my Windows install decides that it is going to update whether I like it or not and the Cygwin terminal that I had
open, in the middle of debugging something, with a command history
that I would ideally like to have kept, evaporates.
Isn't that irritating? Windows is a system that's really not very respectful at all with what the user is doing---lots of interruptions
such as alerts by Windows Defender and whatnot. Many other programmers
on Windows follow suit, so it's not Microsoft's fault completely. And that might be the same thing in the usual GNU system these days. For window management, I run CWM, which is one that really only lets
anything happen that the user has actively made it happen.
The comment wasnrCOt intended to be specifically about Windows, that
just happened to be the most recent example that sprung to mind. All
the common operating systems take time to boot, time which would
ideally be spent doing what you, as the user, actually wish to
do. Even resume-from-hibernation is not instant.
All of the common operating systems update, often requiring a reboot,
taking time which would ideally be spent doing what you, as the user, actually wish to do.
Even if the update process is manual, e.g. when IrCOm using Debian and migrating a server to a new VM, I do not actually want to spend my
time working out with trial and error what invocation of certbot will
allow me to put Letsencrypt certificates on a new server that already
has Apache installed. (Spoiler; spin down Apache, use certbot
--certonly, which spins up its own HTTP server.)
(I certainly donrCOt want to have to migrate well-written PHP of twenty
years ago that carefully wrapped access to a database using then-best-practice APIs because those APIs are unmaintained and
removed, but that is entirely on me, we all know PHP is terrible, and
I knew it then. But Debian shouldnrCOt be terrible, and in the grand
scheme of things it isnrCOt terrible.)
There are reasons and many of them are good for these things. I donrCOt
plan to switch my day-to-day to TempleOS. But that we have them is a
trade off.
And speaking of Medicine, how is it disrespectful these days as
well, but I won't digress on this (and it's perhaps just something
that plagues the entirety of society).
What do you mean? Respect towards and from medicine varies by
country. Doctors are regularly assaulted in India by family members of patients unhappy with the patientsrCO care. I get Christmas presents.
I never ran XEmacs, but I watched a documentary once that said that
XEmacs was born out of something to do with font locking---my intuition
says XEmacs started out with coloring? IIRC, Stallman or someone would
have said that the idea was not properly designed. I can't recall, but
I might research the question and report back here.
ADDENDUM
On Tue, 11 Aug 2026 12:20:00 -0400, George Neuner
<gneuner2@comcast.net> wrote:
On Mon, 10 Aug 2026 10:48:48 -0300, Anton Antimo <anton@safunu.org>
wrote:
George Neuner <gneuner2@comcast.net> writes:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo <anton@safunu.org>
wrote:
How about the [Racket] macro system? So perfect, yet so annoying. >>>>>One thing I love about Common Lisp is precisely macro's (lack of) >>>>>hygiene. I'm totally fine with complete guarantee. Anaphoric >>>>>macros are so useful. (No idea how to implement them in Racket >>>>>---impossible?)
Racket has its roots in Scheme. Scheme is defined in terms of source
/text/ rather than the compiler's AST. So there is no real equivalent >>>> of Lisp's AST macros.
:
Is there an article out there that elaborate your paragraph here? I'd >>>like to learn more about these differences. I suppose the Scheme people >>>would have very strong arguments to go their way.
:
It is implicit in the semantics sections of the R_RS documents. Might
be explicit in some of them, I don't recall - the earlier documents
tended to contain more detail about intent, but I haven't (re)read any
of them in ages. I'm sure I've seen it explicitly stated somewhere,
but it may have been in some book.
[One of my college professors was Mitchell Wand who co-wrote
"Essentials of Programming Languages" and served on the Scheme
defining committee for many years.]
TLDR; Scheme's formal semantics are based on the syntax of forms in
the /external/ representation - ie. the source text - not on any
compiler's internal representation.
R6RS has in Appendix (A) a discussion of the formal semantics in which
they do state that Scheme's denotation semantics are based on
/strings/. Unfortunately the statement is offhand and the discussion
itself is non-normative.
So far I haven't been able to find it stated explicitly in any
normative (authoritative) source, but I don't have access to the ISO
or IEEE standard documents.
On 12/08/2026 8:01 PM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 11/08/2026 4:41 AM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 06/08/2026 5:48 AM, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
Unhelpfully, Lawrence is always talking about some sort of select in
Python, and then talks about polling in Linux, when he knows we don't
care about the Linux kernel here in comp.lang.lisp, because the Steel
Banks Common Lisp encapsulates the kernel for us.
No sarcasm here. Lawrence has been doing a great service to the
current USENET. We can say whatever we want about his knowledge or
opinions or whatever, but he keeps a lot of people distracted here
and I'm sure these people are all looking for a distraction. And his
distractions are not all inadequate. He's usually bring up on-topic
things that allows people here to exercise their own skills. If
these contributions are too shallow---well---I'd say that's something
we can say about most USENET traffic these days. Because we're very
low volume these days, I think shallow contributions are better than
nothing. I prefer the shallow chat than no chat at all.
And I prefer polite chat, such as the one we are now having. Thank you.
I can only talk about my own skillset in Common Lisp, which I will prob-
ably have to say is not that great, having used it much less in anger
than C -- and prior to that, C++ but that's a different story -- and so
I got myself all the Lisp books I have amassed, most or all of them al-
ready mentioned in various topics here in comp.lang.lisp.
That said, life happened, and continues to happen, so I don't know when
I'll get to increase my skillset in Lisp. As everyone in comp.lang.c
knows, I'm currently going through Appel's compiler book in C, and well,
also took a detour by re-reading Loudon's /Mastering Algorithms in C/,
which while somewhat basic in the C, is very good at giving practical examples of the data structures in question.
I've previously mentioned a similar book in Lisp, by Domkin. I'll get
to it one of these decades.
And no, I don't know why Lawrence is always pretending to be a Python
influencer here in comp.lang.lisp. I hope he's getting paid for it.
From what I can tell, Lawrence never really caught the Lisp
culture---it can be seen in how he writes Lisp in the occasion he
does it. This means his criticism aren't very serious. He loves
Python, which is a way of saying---``thanks, Lisp, for the things
you've done for me.''
I'm not sure I did either, to be honest. I just find it fascinating in
many ways, and wish to increase my own skillset in Lisp, and of course,
get a better immersion in the culture.
Personally, I think Lisp people need -- well, need is a strong word, but
I'll go with it -- to get a little bit more behind the notion of practi- cality. I mean, the Steel Banks Common Lisp is fine, but many others
aimed at beginners are exclusively geared towards facing the programmer
him- -- or her- -- self. There is very little attention paid to the de- tails of creating binaries to share with friends. And by this, I mean
the parts of the programmer facing documentation. I believe the Steel
Banks Common Lisp manual does not mention how to create binary executa-
bles? I believe I learned that from /Stack Overflow/ which everyone
here in comp.lang.lisp knows is not a good place to learn how to do
anything; not anymore.
If I'm not mistaken, we also have this problem with Racket. Racket is
aimed at students, mostly, learning to code in Scheme, or the Scheme
dialect that is Racket, but not how to create binaries to share their
work with their loved ones who don't code.
So I believe we need more books about Common Lisp. Especially how to
make production games in Common Lisp. I mean, the Steel Banks Common
Lisp garbage collector cannot be worse than the old one in Unity, and
I currently believe C.L.O.S. is eminently suitable for three
dimensional game objects.
What do you think?
* Here I'm making fun of the YouTubian culture of only ever talk** about videos, and never anything published in books. "This guy made a video
about something, and I'm going to talk about too" is the typical intro duction, if I remember correctly. I don't watch much of YouTube any-
more.
** I'm going to leave this grammatical error.
If I'm not mistaken, we also have this problem with Racket. Racket is
aimed at students, mostly, learning to code in Scheme, or the Scheme
dialect that is Racket, but not how to create binaries to share their
work with their loved ones who don't code.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 12/08/2026 8:01 PM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 11/08/2026 4:41 AM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 06/08/2026 5:48 AM, Lawrence DrCOOliveiro wrote:
On Wed, 05 Aug 2026 13:13:42 -0300, Anton Antimo wrote:
[...]
Unhelpfully, Lawrence is always talking about some sort of select in
Python, and then talks about polling in Linux, when he knows we don't
care about the Linux kernel here in comp.lang.lisp, because the Steel
Banks Common Lisp encapsulates the kernel for us.
No sarcasm here. Lawrence has been doing a great service to the
current USENET. We can say whatever we want about his knowledge or
opinions or whatever, but he keeps a lot of people distracted here
and I'm sure these people are all looking for a distraction. And his
distractions are not all inadequate. He's usually bring up on-topic
things that allows people here to exercise their own skills. If
these contributions are too shallow---well---I'd say that's something
we can say about most USENET traffic these days. Because we're very
low volume these days, I think shallow contributions are better than
nothing. I prefer the shallow chat than no chat at all.
And I prefer polite chat, such as the one we are now having. Thank you.
Yeah---rudeness in USENET is a reflection of the health state of its participants.
I can only talk about my own skillset in Common Lisp, which I will prob-
ably have to say is not that great, having used it much less in anger
than C -- and prior to that, C++ but that's a different story -- and so
I got myself all the Lisp books I have amassed, most or all of them al-
ready mentioned in various topics here in comp.lang.lisp.
That said, life happened, and continues to happen, so I don't know when
I'll get to increase my skillset in Lisp. As everyone in comp.lang.c
knows, I'm currently going through Appel's compiler book in C, and well,
also took a detour by re-reading Loudon's /Mastering Algorithms in C/,
which while somewhat basic in the C, is very good at giving practical
examples of the data structures in question.
I've previously mentioned a similar book in Lisp, by Domkin. I'll get
to it one of these decades.
I've thankfully read this one by Kyle Loudon as well. Keep your
studying going slowly, but constantly. There's no rush. Things
meaningfully evolve as fast as everybody says. There's no royal road to knowledge and wisdom; no AI-road either. Keep it up; be careful with
your time on the USENET.
And no, I don't know why Lawrence is always pretending to be a Python
influencer here in comp.lang.lisp. I hope he's getting paid for it.
From what I can tell, Lawrence never really caught the Lisp
culture---it can be seen in how he writes Lisp in the occasion he
does it. This means his criticism aren't very serious. He loves
Python, which is a way of saying---``thanks, Lisp, for the things
you've done for me.''
I'm not sure I did either, to be honest. I just find it fascinating in
many ways, and wish to increase my own skillset in Lisp, and of course,
get a better immersion in the culture.
Try to understand when, why and how people did what they did. In other words, I think history is very important in studying. New is not always better.
Personally, I think Lisp people need -- well, need is a strong word, but
I'll go with it -- to get a little bit more behind the notion of practi-
cality. I mean, the Steel Banks Common Lisp is fine, but many others
aimed at beginners are exclusively geared towards facing the programmer
him- -- or her- -- self. There is very little attention paid to the de-
tails of creating binaries to share with friends. And by this, I mean
the parts of the programmer facing documentation. I believe the Steel
Banks Common Lisp manual does not mention how to create binary executa-
bles? I believe I learned that from /Stack Overflow/ which everyone
here in comp.lang.lisp knows is not a good place to learn how to do
anything; not anymore.
See SBCL's sb-ext:save-lisp-and-die.
(sb-ext:save-lisp-and-die #P"my-executable.exe"
:toplevel #'my-package:main
:executable t
:save-runtime-options t)
Source:
https://www.sbcl.org/manual/
If I'm not mistaken, we also have this problem with Racket. Racket is
aimed at students, mostly, learning to code in Scheme, or the Scheme
dialect that is Racket, but not how to create binaries to share their
work with their loved ones who don't code.
That's what Racket claims. They claim it to be real-world, batteries included and whatnot. They also create executable binaries like SBCL
does above.
So I believe we need more books about Common Lisp. Especially how to
make production games in Common Lisp. I mean, the Steel Banks Common
Lisp garbage collector cannot be worse than the old one in Unity, and
I currently believe C.L.O.S. is eminently suitable for three
dimensional game objects.
What do you think?
I never think about games, thankfully. I've played video-games from 11
to 14 years old, replacing them completely with UNIX, a great
investment.
Economically speaking, if CL had more users, there'd be more books. I
don't have much need for Common Lisp (strictly speaking) books myself.
I'm not trying myself to read more books on the language. What I'm
doing is writing more Common Lisp and reading more of it. What
certainly helps me is for people to use it, which then indirectly asks
for more books (but for the wrong reasons: the beginner often thinks
that something new is required for him to invest his time; reading an
old book seems like a waste of time for so many of them, but that's only because they're beginners and might be for the rest of their lives).
* Here I'm making fun of the YouTubian culture of only ever talk** about
videos, and never anything published in books. "This guy made a video
about something, and I'm going to talk about too" is the typical intro
duction, if I remember correctly. I don't watch much of YouTube any-
more.
** I'm going to leave this grammatical error.
Yeah---knowing how to use a natural language includes knowing how to
violate ``its grammar'' as well.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
If I'm not mistaken, we also have this problem with Racket. Racket is
aimed at students, mostly, learning to code in Scheme, or the Scheme
dialect that is Racket, but not how to create binaries to share their
work with their loved ones who don't code.
In practise the answer is 'raco exe' which makes an executable. You have
to have a suitable main function &c, but it's not hard.
Mario Rosell <mario@mariorosell.es> writes:
Hello everyone!
I want to learn Common Lisp, but I don't really know what resources to
use.
What did you all use to learn? Is that even relevant? Is this newsgroup
active?
Book already mentioned that was very useful to me, apologies to re-post
1. Practical Common Lisp
2. OnLisp
3. Land Of Lisp
one of my favorites but it's maybe controversial is Let Over Lambda
A proper setup with Emacs with Sly, and lately I was able to enable
open local HyperSpec from a symbol ( that was a game changer for my brain that can not hold to much info and unfortunately I have to use C++ at work).
Quicklisp is very very handy, and I'm trying to setup quicklisp lookup textinfo from symbol as well similar to the HyperSpec, but the mileage
vary here.
Anton Antimo <anton@safunu.org> wrote:
I never ran XEmacs, but I watched a documentary once that said that
XEmacs was born out of something to do with font locking---my intuition
says XEmacs started out with coloring? IIRC, Stallman or someone would
have said that the idea was not properly designed. I can't recall, but
I might research the question and report back here.
The Emacs schism was not fundamentally technical: it happened because cooperation with RMS is impossible. Lucid needed some features in what
would have been Emacs 19 to support a programming environment (for C++, I think, not Lisp, despite them being Lucid) and were willing to donate the time to implement them & donate the results (remember Emacs 18 had an entirely minimal interface to X: equivalent to running it in a terminal emulator). And ... cooperation with RMS turned out to be impossible. So LEmacs happened, which became XEmacs after Lucid died.
I wasn't there, but I was around a few months later and perhaps before the split was really final. I perhaps no longer have the trove of emails from the split: they made depressing reading.
(If you're thinking of posting a followup explaining why cooperation with
RMS is, in fact, possible, just ... don't, please.)
tfb <tfb@work.it.out> writes:
Anton Antimo <anton@safunu.org> wrote:
I never ran XEmacs, but I watched a documentary once that said that
XEmacs was born out of something to do with font locking---my intuition
says XEmacs started out with coloring? IIRC, Stallman or someone would
have said that the idea was not properly designed. I can't recall, but
I might research the question and report back here.
The Emacs schism was not fundamentally technical: it happened because
cooperation with RMS is impossible. Lucid needed some features in what
would have been Emacs 19 to support a programming environment (for C++, I
think, not Lisp, despite them being Lucid) and were willing to donate the
time to implement them & donate the results (remember Emacs 18 had an
entirely minimal interface to X: equivalent to running it in a terminal
emulator). And ... cooperation with RMS turned out to be impossible. So
LEmacs happened, which became XEmacs after Lucid died.
I wasn't there, but I was around a few months later and perhaps before the >> split was really final. I perhaps no longer have the trove of emails from >> the split: they made depressing reading.
(If you're thinking of posting a followup explaining why cooperation with
RMS is, in fact, possible, just ... don't, please.)
Thank you for describing the matter. You must be the best one here to elaborate on the schism? Can you elaborate it more technically? For instance, there's font locking today on the GNU EMACS---was it done in a dramatically different way relative to LEmacs?
An LLM is an emulation of a neural net. There's plenty of study
material regarding neural nets.
Modern implementations forgo the traditional graph representation and
instead are based on matrix math. Ie. you take a bunch of inputs,
multiply each input by a weight, offset the result by adding some
value, then summ and pass the summ put through a (possibly per node)
equation to get an output. That ptoentially feeds into the inputs of
the next layer of nodes.
The difficulty is in getting the topology correct. Too many nodes,
the nodes start to specialize, too few nodes the results are fuzzy.
Bad connection scheme - either it doesn't work or training becomes
very difficult. NNs have been studied since the 1970s, and there are
known topologies to create various kinds of recognizers and types of
(app specific) memories. You can (sort of) plug and play using these
as modules. But still a lot of it is just trial and error. That's why
so much effort is needed to build them.
LLMs [I agree it's a stupid name] are hidden node models having tens
of thousands (or more) of nodes, and many millions of inputs [and
weights and offsets]. You can't build one without a supercomputer.
There's a PHd and potential billions of $$$ waiting if you can figure
out how to make a NN reliably forget something it has learned, without retraining from scratch and without affecting anything else it knows.
Have fun!
On Sun, 09 Aug 2026 19:12:49 -0400, steve g <Sgonedes1977@gmail.com>
wrote:
I'm not aware that Racket can run over Cygwin. If it can, I would bet
that GUI/graphical programs won't work.
Certainly you can create an interface to Cygwin and use it directly.
[You can do this with pretty much any library.]
On 2026-08-02, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
Common Lisp is a museum-worthy spec by this point. There needs to
be something more modern, not so full of legacy baggage tied to
old, proprietary, pre-POSIX OS platforms which are all extinct by
now.
SBCL tells me otherwise, ditto with the Kandria engine, or projects
like Nyxt. Also, Coalton + Quilc in quantum mechanics basically
makes any 'legacy' assumption on CL laughable.
I never ran XEmacs, but I watched a documentary once that said that
XEmacs was born out of something to do with font locking---my
intuition says XEmacs started out with coloring? IIRC, Stallman or
someone would have said that the idea was not properly designed.
On 13/08/2026 11:19 PM, Anton Antimo wrote:
Personally, I think Lisp people need -- well, need is a strong word, but >>> I'll go with it -- to get a little bit more behind the notion of practi- >>> cality. I mean, the Steel Banks Common Lisp is fine, but many others
aimed at beginners are exclusively geared towards facing the programmer
him- -- or her- -- self. There is very little attention paid to the de- >>> tails of creating binaries to share with friends. And by this, I mean
the parts of the programmer facing documentation. I believe the Steel
Banks Common Lisp manual does not mention how to create binary executa-
bles? I believe I learned that from /Stack Overflow/ which everyone
here in comp.lang.lisp knows is not a good place to learn how to do
anything; not anymore.
See SBCL's sb-ext:save-lisp-and-die.
(sb-ext:save-lisp-and-die #P"my-executable.exe"
:toplevel #'my-package:main
:executable t
:save-runtime-options t)
Source:
https://www.sbcl.org/manual/
And herein lies the conundrum. I believe I took a quick glance at the manual, looked at the able of contents, and even tried ctrl+f and the
terms /binary/ or /binaries/, and /executable/, and found nothing.
Being /technically/ in the manual does not help if one cannot easily
find what one is looking for. It also doesn't help if one doesn't have expectations of finding it in the first place.
So I believe we need more books about Common Lisp. Especially how to
make production games in Common Lisp. I mean, the Steel Banks Common
Lisp garbage collector cannot be worse than the old one in Unity, and
I currently believe C.L.O.S. is eminently suitable for three
dimensional game objects.
What do you think?
I never think about games, thankfully. I've played video-games from
11
to 14 years old, replacing them completely with UNIX, a great
investment.
Economically speaking, if CL had more users, there'd be more books.
I don't have much need for Common Lisp (strictly speaking) books
myself. I'm not trying myself to read more books on the language.
What I'm doing is writing more Common Lisp and reading more of it.
What certainly helps me is for people to use it, which then
indirectly asks for more books (but for the wrong reasons: the
beginner often thinks that something new is required for him to
invest his time; reading an old book seems like a waste of time for
so many of them, but that's only because they're beginners and might
be for the rest of their lives).
Well, I don't only mean beginner books. I mean some of the more ad-
vanced books as well, when it comes to C. Of course /Common Lisp Re-
cipes/, and /The Common Lisp Condition System/ should be good examples
that I'll get to read one of these decades. Here I'm thinking of Adam Tornhill's /Patterns in C/. There are even several more, some of which
I've lost track of, because I believe they were only available as a PDF
and I neglected to print them out.
Right now I'm not inclined to cross post this to comp.lang.c, and ask if they'd be willing to fill in some of those blanks.
Hm, as-is, there seems to be a /blank/ in my knowledge, when it comes to thinking of an equivalent book in Lisp. Specifically about these /patt- erns/, and how to use them.
Perhaps there is no need? After all, the original patterns book in Java
was all about working around deficiencies in the Java programming lang-
uage, and maybe Common Lisp has few enough of those we don't care about
a specific set of patterns?
Or is this simply covered in /Common Lisp Recipes/ and I forgot?
Have a nice day, and Lisp well!
I never ran XEmacs, but I watched a documentary once that said that
XEmacs was born out of something to do with font locking---my
intuition says XEmacs started out with coloring? IIRC, Stallman or
someone would have said that the idea was not properly designed.
Thank you for describing the matter. You must be the best one here to elaborate on the schism? Can you elaborate it more technically? For instance, there's font locking today on the GNU EMACS---was it done in a dramatically different way relative to LEmacs?
Hm, as-is, there seems to be a /blank/ in my knowledge, when it comes to thinking of an equivalent book in Lisp. Specifically about these /patt- erns/, and how to use them.
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 13/08/2026 11:19 PM, Anton Antimo wrote:
[...]
Personally, I think Lisp people need -- well, need is a strong word, but >>>> I'll go with it -- to get a little bit more behind the notion of practi- >>>> cality. I mean, the Steel Banks Common Lisp is fine, but many others
aimed at beginners are exclusively geared towards facing the programmer >>>> him- -- or her- -- self. There is very little attention paid to the de- >>>> tails of creating binaries to share with friends. And by this, I mean >>>> the parts of the programmer facing documentation. I believe the Steel >>>> Banks Common Lisp manual does not mention how to create binary executa- >>>> bles? I believe I learned that from /Stack Overflow/ which everyone
here in comp.lang.lisp knows is not a good place to learn how to do
anything; not anymore.
See SBCL's sb-ext:save-lisp-and-die.
(sb-ext:save-lisp-and-die #P"my-executable.exe"
:toplevel #'my-package:main
:executable t
:save-runtime-options t)
Source:
https://www.sbcl.org/manual/
And herein lies the conundrum. I believe I took a quick glance at the
manual, looked at the able of contents, and even tried ctrl+f and the
terms /binary/ or /binaries/, and /executable/, and found nothing.
Being /technically/ in the manual does not help if one cannot easily
find what one is looking for. It also doesn't help if one doesn't have
expectations of finding it in the first place.
Try the ``executable'' keyword; you'll find this:
--8<-------------------------------------------------------->8---
Executable Delivery: The :executable argument to
sb-ext:save-lisp-and-die can produce a "standalone" executable
containing both an image of the current Lisp session and an SBCL
runtime.
--8<-------------------------------------------------------->8---
Source:
https://www.sbcl.org/manual/
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
Hm, as-is, there seems to be a /blank/ in my knowledge, when it comes to
thinking of an equivalent book in Lisp. Specifically about these /patt-
erns/, and how to use them.
Winston and Horn "Lisp" was a favorite way back in the day:
https://en.wikipedia.org/wiki/LISP_(book)
It was originally part of the book "Artificial Intelligence" but the
Lisp part split off into a separate volume, per the Wikipedia article
above.
The thing is, CL's design makes some sense, but only up to a point.
It's not holistic like Scheme, so don't expect too much consistency.
CL's unifying purpose was to maintain some level of commonality with a
bunch of incompatible predecessor Lisps of varying origin. It didn't
try to run earlier dialects without modification, but it tried to keep
the porting effort manageable, as I understand it. Old timers here will
know more about this than I do. There are some good history documents
around whose names I don't remember.
In my case I found CLTL1 to be pretty understandable after first gaining
an understanding of Lisp by reading through the Emacs Lisp interpreter
source code (written in C) and mucking around with some Emacs Lisp code.
The CADR manual was also enlightening, even though I never actually used
a CADR or any other Lisp machine (I guess that's a sign of a deprived childhood). See:
https://tumbleweed.nu/r/lm-3/uv/chinual.html
As for Scheme, I think of it more as an assembly language for a cosmic
sized computer, than as something for humans program much in directly.
Others believe the opposite.
On Tue, 11 Aug 2026 18:31:24 +0100, Aidan Kehoe wrote:
If you use any emacs itrCOs hard to avoid Lisp. Emacs Lisp is not a paragon of good design nor of good implementation-- (aset
(symbol-name nil) 0 ?\u0192) , (fillarray obarray 0) , anyone?--so
the natural thing is to look around for something better. The
consensus within XEmacs was that Common Lisp was better. On
investigating, yes, it is.
ItrCOs a museum-worthy spec. Needs updating to, at least support POSIX-type features that we take for granted nowadays.
Even if the update process is manual, e.g. when IrCOm using Debian and migrating a server to a new VM, I do not actually want to spend my
time working out with trial and error what invocation of certbot
will allow me to put Letsencrypt certificates on a new server that
already has Apache installed. (Spoiler; spin down Apache, use
certbot --certonly, which spins up its own HTTP server.)
But you need to be able to keep the certs up to date without having to
shut down Apache (or whatever web server yourCOre using) each time.
Trust the standard Debian packages to take care of this automatically.
[...] I have never developed any web app from scratch in PHP. The only time IrCOve used it is to maintain existing code, or write plugins for existing code (WordPress, WooCommerce).
As a language, its features read like a shopping list of sadness.
tfb <tfb@work.it.out> wrote or quoted:The price for that is the need to rewrite the codebase in whatever
A very long time ago, Lisp had many unique features. Today it has exactly >> one, but that feature is critical. It just seems weird to me to ignore its >> defining characteristic. Not wrong: weird.
Reddit concluded that with macros they were now supposed to learn
to read several entirely unique, personalized programming languages,
and preferred to rewrite their system in Python.
Python's wrappers and resource contexts give developers a way to
pass executable blocks to functions or objects achieving what devel-
opers often use macros for without exposing the chaotic power of
full AST manipulation.
On 2026-08-10, Andreas Eder <a_eder_muc@web.de> wrote:
On So 09 Aug 2026 at 05:26, Johann 'Myrkraverk' Oskarsson wrote:
I've found the Common Lisp macro system annoying enough that I rarely
use it. I'm OK with functions most of the time, and CLOS the rest of
the time. And only resort to macros when I can't do anything else in
the situation.
That us exactly where it should be used - when there is no other way.
I don't agree, because that amounts to macros never being used.
It's never the case that there is no other way, because in place of
any macro, you can write the expansion by hand.
Ar an dara l|i d|-ag de m|! L||nasa, scr|!obh Lawrence DrCOOliveiro:
[Common Lisp is] a museum-worthy spec. Needs updating to, at least
support POSIX-type features that we take for granted nowadays.
ItrCOs better than Emacs Lisp.
But you need to be able to keep the certs up to date without having to
shut down Apache (or whatever web server yourCOre using) each time.
Trust the standard Debian packages to take care of this automatically.
This wasnrCOt practical. In any event I wasnrCOt asking for help ...
As a language, [PHPrCOs] features read like a shopping list of sadness.
Yep. And, of course, itrCOs one of the most popular programming
languages around.
Similarly, as far as I can tell the most used Lisp is AutoCAD Lisp.
This is not the most full-featured or well-thought-through Lisp out
there.
Aidan Kehoe <kehoea@parhasard.net> writes:
[...] My first degree was 1998-2002 and the professor (clearly taking shelter from the first AI winter) assigned the GNU Emacs manual as required reading for the first class. (This is, I understand, not typical.)
Very atypical these days. Your first degree must have been Computer Science? So you got two degrees. Having a degree or not in such areas,
I think that understanding the fundamentals of computers and programming
is a pretty good skill these days. There might be other areas I miss
for sheer lack of wisdom here.
I took a ``programming 102'' engineering class a few years ago in which
the professor offered us a ZIP package containing the GNU EMACS set up
with Python. Students on the first day of class protested against their ``programming 101'' (a Python primer) saying it was essentially useless
with no real-world anything (which I fully agree: that course's real objective was to teach us the syntax of Python [with no OOP, which is
the job of ``programming 102'']).
The professor replied saying he would present us with some illustrations
of real-world stuff. To my surprise, one of these things was the GNU
EMACS. His EMACS came with all of its default configuration but some additional ones for people to run Python and ESHELL. (To run it, we'd double click on a icon on the desktop.) Students were welcome to ignore
it all and use Python's IDLE or whatever, which I think 99% of them did. What students couldn't ignore, which was cool (lol), was that the way to turn in homework was through fossil. The professor introduced us to
fossil in another lecture, saying he chose fossil over git due to
slightly greater simplicity (compared to git, which I couldn't quite
see). I was likely the one exception that didn't struggle with
fossil----I had never heard of it until then, but I've been using git
for years.
Anyway, after these lectures, he went on with the course, which didn't work very well at all because I think after the GNU EMACS and fossil most students had already given up on him---there were many other professors teaching the same course in a way that it had a lot less new things to learn.
At that point XEmacs was a better editor so after using GNU Emacs for
a few weeks I switched to XEmacs. It still meets my needs and I have
no plan to switch away from it.
I never ran XEmacs, but I watched a documentary once that said that
XEmacs was born out of something to do with font locking---my intuition
says XEmacs started out with coloring? IIRC, Stallman or someone would
have said that the idea was not properly designed. I can't recall, but
I might research the question and report back here.
[...] If you use any emacs itrCOs hard to avoid Lisp. Emacs Lisp is not a paragon of good design nor of good implementation-- (aset (symbol-name nil) 0 ?\u0192) , (fillarray obarray 0) , anyone?--so the natural thing is to look around for something better. The consensus within XEmacs was that Common Lisp was better. On investigating, yes, it is. But, XEmacs needs work, no-one else is doing it, so my software work these days is C with a very Common-Lisp-oriented Emacs Lisp.
I tried the code above on the GNU EMACS. The first crashes it
immediately. The second doesn't seem to do its job anymore, throwing a
type error. They must have created a new type called obarray. Saying (type-of obarray) produces obarray, while fillarray expects a vector.
(I certainly donrCOt want to have to migrate well-written PHP of twenty years ago that carefully wrapped access to a database using then-best-practice APIs because those APIs are unmaintained and
removed, but that is entirely on me, we all know PHP is terrible, and
I knew it then. But Debian shouldnrCOt be terrible, and in the grand scheme of things it isnrCOt terrible.)
What did you write 20 years ago?
That's indeed PHP's prime time. I know the language. I used it seriously back then as well. I never went into PHP 4, remaining in PHP 3 for as long as I could until I gave up on PHP completely---I've always appreciated language stability.
[...] And speaking of Medicine, how is it disrespectful these days as well, but I won't digress on this (and it's perhaps just something that plagues the entirety of society).
What do you mean? Respect towards and from medicine varies by
country. Doctors are regularly assaulted in India by family members of patients unhappy with the patientsrCO care. I get Christmas presents.
It is indeed. If my sources are correct, in the United States (for example), we get deaths due to medical error top ranked---I don't mean
top 1st, but highly ranked (top 3 a while ago?).
But what I had meant was that I get the feeling from hearing from the population that the attention and time doctors spend with patients now
has been greatly reduced; that doctors are often rude, get easily
irritated and so on. That then makes me think they might be working too much.
I in fact see a parallel with programmers: in the typical company, the typical programmer can be slightly arrogant, easily irritated, the explanation for which might be too much work, not very competent and not living very joyful days. So in the end I don't see anything specific to Medicine, but something much larger. I'm a student at a large university---what can I say about professors? They're very easily offended with students' lack of interest; they inadvertently and incorrectly take a lot of things personally; my overall conclusion is that they're not doing very well health-wise, not living very joyful days (they might miss days in which there was more glamour in the profession, when they feel they would be better regarded). Something like that.
ItrCOs better than Emacs Lisp. (I admit, with RMS not as active, GNU Emacs including their Emacs Lisp, has made impressive progress over the last few years, but itrCOs still shaped by years of his technical decisions, and the development culture was shaped by him.)
> ZetaLisp's innovations extended beyond Flavors to include proper
IrCOm sure they do have their own extensions to make up for the
deficiencies of Common Lisp. But then, they are no longer rCLCommonrCY,
are they?
Right, if the language you already has supports every construct anyone
might ever want to do anything, then nobody needs macros.
Do they say that? Which ones? This one thinks that domain-specific
and application-specific languages are useful and thinks that
languages with facilities which allow the simple incremental
construction of such languages are therefore also useful.
And herein lies the conundrum. I believe I took a quick glance at the manual, looked at the able of contents, and even tried ctrl+f and the
terms /binary/ or /binaries/, and /executable/, and found nothing.
Being /technically/ in the manual does not help if one cannot easily
find what one is looking for. It also doesn't help if one doesn't have expectations of finding it in the first place.
On Mon, 10 Aug 2026 17:41:30 -0300, Anton Antimo wrote:
For select (called unix-fast-select in SBCL), see sb-unix.
select(2) is considered an archaic way of doing things these days,
because of its ABI limitations. The modern way is poll() <https://manpages.debian.org/poll(2)> (POSIX) or even epoll() <https://manpages.debian.org/epoll(7)> (Linux-specific).
On 14/08/2026 7:58 AM, Anton Antimo wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
On 13/08/2026 11:19 PM, Anton Antimo wrote:
[...]
Personally, I think Lisp people need -- well, need is a strong word, but >>>>> I'll go with it -- to get a little bit more behind the notion of practi- >>>>> cality. I mean, the Steel Banks Common Lisp is fine, but many others >>>>> aimed at beginners are exclusively geared towards facing the programmer >>>>> him- -- or her- -- self. There is very little attention paid to the de- >>>>> tails of creating binaries to share with friends. And by this, I mean >>>>> the parts of the programmer facing documentation. I believe the Steel >>>>> Banks Common Lisp manual does not mention how to create binary executa- >>>>> bles? I believe I learned that from /Stack Overflow/ which everyone >>>>> here in comp.lang.lisp knows is not a good place to learn how to do
anything; not anymore.
See SBCL's sb-ext:save-lisp-and-die.
(sb-ext:save-lisp-and-die #P"my-executable.exe"
:toplevel #'my-package:main
:executable t
:save-runtime-options t)
Source:
https://www.sbcl.org/manual/
And herein lies the conundrum. I believe I took a quick glance at the
manual, looked at the able of contents, and even tried ctrl+f and the
terms /binary/ or /binaries/, and /executable/, and found nothing.
Being /technically/ in the manual does not help if one cannot easily
find what one is looking for. It also doesn't help if one doesn't have
expectations of finding it in the first place.
Try the ``executable'' keyword; you'll find this:
--8<-------------------------------------------------------->8---
Executable Delivery: The :executable argument to
sb-ext:save-lisp-and-die can produce a "standalone" executable
containing both an image of the current Lisp session and an SBCL
runtime.
--8<-------------------------------------------------------->8---
Source:
https://www.sbcl.org/manual/
Please be patient with me. Here is a screenshot. I'm afraid the link
is ridiculously long, and I don't use url shorteners anymore.
https://www.dropbox.com/scl/fi/07asmp90gza39utr55wro/SBCL-manual-execu.jpg?rlkey=jd3tcevbchchpsge37xfmjh1j&st=pk2y5hvh&dl=0
What I'm looking at here seems to be the word "execu" -- or the prefix
of which -- not being found. Should I have continued to type the whole
word? I thought this worked like Emacs' incremental search, and as I
typed more characters, it would search longer words, until it wouldn't
find what I've typed so far.
Is this perhaps a matter of not using the right browser? I mean, what browser do the team players behind S.B.C.L. habitually use themselves?--
On 14/08/2026 12:14 AM, tfb wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
If I'm not mistaken, we also have this problem with Racket. Racket is
aimed at students, mostly, learning to code in Scheme, or the Scheme
dialect that is Racket, but not how to create binaries to share their
work with their loved ones who don't code.
In practise the answer is 'raco exe' which makes an executable. You have
to have a suitable main function &c, but it's not hard.
Well, aside from technically correct answers, I was talking about the culture. In my recollection, and by now I guess that would be an old Racket,* there was no emphasis on creating binaries in the Racket intro- ductory material, nor user interface. It's more like, here's a pro-
gramming language, use it!
And until binaries are habitually made with Racket, and by that I mean production binaries, with code signatures for the Microsoft and fruit
vendor platforms, that's not likely to change.
Best wishes, and happy Racketteering!
* Pun totally intended afterwards.--
On 14/08/2026 3:52 AM, Anton Antimo wrote:
tfb <tfb@work.it.out> writes:
Anton Antimo <anton@safunu.org> wrote:
I never ran XEmacs, but I watched a documentary once that said that
XEmacs was born out of something to do with font locking---my intuition >>>> says XEmacs started out with coloring? IIRC, Stallman or someone would >>>> have said that the idea was not properly designed. I can't recall, but >>>> I might research the question and report back here.
The Emacs schism was not fundamentally technical: it happened because
cooperation with RMS is impossible. Lucid needed some features in what
would have been Emacs 19 to support a programming environment (for C++, I >>> think, not Lisp, despite them being Lucid) and were willing to donate the >>> time to implement them & donate the results (remember Emacs 18 had an
entirely minimal interface to X: equivalent to running it in a terminal
emulator). And ... cooperation with RMS turned out to be impossible. So >>> LEmacs happened, which became XEmacs after Lucid died.
I wasn't there, but I was around a few months later and perhaps before the >>> split was really final. I perhaps no longer have the trove of emails from >>> the split: they made depressing reading.
(If you're thinking of posting a followup explaining why cooperation with >>> RMS is, in fact, possible, just ... don't, please.)
Thank you for describing the matter. You must be the best one here
to elaborate on the schism? Can you elaborate it more technically?
For instance, there's font locking today on the GNU EMACS---was it
done in a dramatically different way relative to LEmacs?
Just to chime in for the newcomers who don't know about this publicly available summary.
https://www.xemacs.org/Documentation/21.5/html/internals_4.html
And.
https://www.xemacs.org/About/XEmacsVsGNUemacs.html
That said, I do hope tfb is willing to write out a technical summary, or
even a social one like in the first link.
Note that since then, GNU Emacs did indeed add loadable modules in C.
Adding comp.emacs.xemacs to the discussion, because that group shouldn't
be empty all the time.
Happy text editing in XEmacs!
LLMs [I agree it's a stupid name] are hidden node models having tens
of thousands (or more) of nodes, and many millions of inputs [and
weights and offsets]. You can't build one without a supercomputer.
I suppose that a typical medic is of a different personality type than
a typical computer programmer. I do not think that being overworked is
the overriding cause of the behavior of medics and programmers.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
No language has 100% of constructs anyone might ever want. If it has
90% and requires a little stretching for the other 10%, it's doing ok.
There's more to language than syntax, even if you find syntax important.
E.g. some users want fancy type systems including for their DSL's.
There are Lisp dialects that have that, but it's unfeasible in CL other
than through the Turing tarpit of macros.
For students, it'd perhaps be much more valuable to teach them how to
disable anything that nags if the resulting binary doesn't carry a
signature made with a certificate from the CA system, especially when it needs to be a more expensive certificate and/or requires ID validation.
George Neuner <gneuner2@comcast.net> writes:
[...]
LLMs [I agree it's a stupid name] are hidden node models having tens
of thousands (or more) of nodes, and many millions of inputs [and
weights and offsets]. You can't build one without a supercomputer.
On the names. I don't think LLM is such a stupid name---it describes
what it is (at least for now, since sizes evolve over time). But isn't ChatGPT even sillier? Who came up with the idea of tagging GPT on the
name of the thing? I suppose the idea was to make it very clear it was
not a person? In that case, they shouldn't be done like it's always
been done: GPT meaning [G]PT is not a [P]erson, [T]hanks (for asking)! (Lol---I'm so good at this.)
One I've seen used that's adequate is "Generative Autocomplete".
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
And herein lies the conundrum. I believe I took a quick glance at the
manual, looked at the able of contents, and even tried ctrl+f and the
terms /binary/ or /binaries/, and /executable/, and found nothing.
Being /technically/ in the manual does not help if one cannot easily
find what one is looking for. It also doesn't help if one doesn't have
expectations of finding it in the first place.
Um, section 2.4.3 Generating Executables, in the manual. It's not quite in the first page on my screen, but, ad they say, RTFM.
On 2026-08-13, Johann 'Myrkraverk' Oskarsson wrote:
On 14/08/2026 12:14 AM, tfb wrote:
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
If I'm not mistaken, we also have this problem with Racket. Racket is >>>> aimed at students, mostly, learning to code in Scheme, or the Scheme
dialect that is Racket, but not how to create binaries to share their
work with their loved ones who don't code.
In practise the answer is 'raco exe' which makes an executable. You have >>> to have a suitable main function &c, but it's not hard.
Well, aside from technically correct answers, I was talking about the
culture. In my recollection, and by now I guess that would be an old
Racket,* there was no emphasis on creating binaries in the Racket intro-
ductory material, nor user interface. It's more like, here's a pro-
gramming language, use it!
And until binaries are habitually made with Racket, and by that I mean
production binaries, with code signatures for the Microsoft and fruit
vendor platforms, that's not likely to change.
For students, it'd perhaps be much more valuable to teach them how to
disable anything that nags if the resulting binary doesn't carry a
signature made with a certificate from the CA system, especially when it needs to be a more expensive certificate and/or requires ID validation.
And perhaps teach them about more suitable means to sign executables,
like OpenPGP, that actually is based on a web of trust and not on some centralized issuer?
No, I'm not so "lucky" to get payments for other people's criminal acti- vities. Do you?Best wishes, and happy Racketteering!
Running afoul of RICO, are we? :-P
No single language has 1% of constructs anyone might ever want.
Sometimes there is a pretense of some limited form of democracy: perhaps
you, as a mere serf, can join the politburo and have a vote on what happens to the language.
I haven't seen this url in a while but I guess it's time to post it
again.
https://www.marktarver.com/bipolar.html
I haven't seen this url in a while but I guess it's time to post it
again.
https://www.marktarver.com/bipolar.html
On Sat, 21 Feb 2026 12:25:06 +0100, Mario Rosell wrote:
Just for fun. It seems like a pretty interesting language.
Lisp is a pretty interesting language, but it was never standardized
to the extent that we expect of languages today. Look at the Common
Lisp spec, and it still retains a lot of baggage to maintain
compatibility with obsolete OSes that simply donrCOt matter any more.
And also, which particular Lisp do you want to learn? There are a
number in common use today:
* In the rCLLisp-2rCY camp: Emacs Lisp, SBCL
* In the rCLLisp-1rCY camp: GNU Guile
And thatrCOs just what I think of as the most notable ones.
On 2026-02-21, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
Lisp is a pretty interesting language, but it was never
standardized to the extent that we expect of languages today. Look
at the Common Lisp spec, and it still retains a lot of baggage to
maintain compatibility with obsolete OSes that simply donrCOt matter
any more.
And also, which particular Lisp do you want to learn? There are a
number in common use today:
* In the rCLLisp-2rCY camp: Emacs Lisp, SBCL
* In the rCLLisp-1rCY camp: GNU Guile
And thatrCOs just what I think of as the most notable ones.
Guile and every other Scheme it's both lib, SRFI and R_RS
incompatible with each other. CL with ANSI and the HyperSpec in the
end can be ironicaly much smaller and compact.
Personally, I think Lisp people need -- well, need is a strong word, but
I'll go with it -- to get a little bit more behind the notion of practi- >cality. I mean, the Steel Banks Common Lisp is fine, but many others
aimed at beginners are exclusively geared towards facing the programmer
him- -- or her- -- self. There is very little attention paid to the de- >tails of creating binaries to share with friends. And by this, I mean
the parts of the programmer facing documentation. I believe the Steel
Banks Common Lisp manual does not mention how to create binary executa-
bles? I believe I learned that from /Stack Overflow/ which everyone
here in comp.lang.lisp knows is not a good place to learn how to do
anything; not anymore.
Games with Gabe wrote* about that extensively in his YouTube video, at
https://www.youtube.com/watch?v=IbDAmvUwo5c
and I heartily agree.
If I'm not mistaken, we also have this problem with Racket. Racket is
aimed at students, mostly, learning to code in Scheme, or the Scheme
dialect that is Racket, but not how to create binaries to share their
work with their loved ones who don't code.
So I believe we need more books about Common Lisp. Especially how to
make production games in Common Lisp. I mean, the Steel Banks Common
Lisp garbage collector cannot be worse than the old one in Unity, and
I currently believe C.L.O.S. is eminently suitable for three dimensional
game objects.
is it possible to use a truth maintenance system? Just curious, it would >probably take up too much space and time. Just a jtms is a lot of
overhead. You could try to use an LTMS but we all know that this just
leads to more wasted space and aggravation. I would think an ATMS would
work; I dunno, I do not have a super computer or a billion dollars.
On 2026-08-14, Anton Antimo wrote:
George Neuner <gneuner2@comcast.net> writes:
[...]
LLMs [I agree it's a stupid name] are hidden node models having tens
of thousands (or more) of nodes, and many millions of inputs [and
weights and offsets]. You can't build one without a supercomputer.
On the names. I don't think LLM is such a stupid name---it describes
what it is (at least for now, since sizes evolve over time). But isn't
ChatGPT even sillier? Who came up with the idea of tagging GPT on the
name of the thing? I suppose the idea was to make it very clear it was
not a person? In that case, they shouldn't be done like it's always
been done: GPT meaning [G]PT is not a [P]erson, [T]hanks (for asking)!
(Lol---I'm so good at this.)
One I've seen used that's adequate is "Generative Autocomplete".
I'd also propose "GIGO As A Service".
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 51:25:11 |
| Calls: | 1,101 |
| Calls today: | 1 |
| Files: | 1,339 |
| Messages: | 276,021 |
