From Newsgroup: comp.lang.c

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

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:

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.

As always, you start off by mouthing your own ignorance.

* OpenVMS is both sold and ported to the x86. https://vmssoftware.com/

I am actually glad to heear this! the women of the 70's loved these
things :)

* OS/2 is being sold and supported, under a new brand name.
https://www.arcanoae.com/

not the best solution in the world but it did/does work.
I still think that PC-DOS was worth it's weight. Automatic IRQ, DMA,
HIGHMEM managment all automated. Wow!


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

tfb <tfb@work.it.out> writes:

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.

you are quite the poet.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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:

[...]

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.

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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. As
always. Garbage collection is /not bad/. And we have a practical de- monstration of this in OpenSSL, hence adding comp.lang.c to the dis-
cussion, where their lack of GC was causing a problem in the real world.


https://securityaffairs.com/195588/hacking/openssl-fixes-hollowbyte-memory-exhaustion-bug.html

I don't know why you're always trying to "sound smart" when everyone can
see that you're just making a fool of yourself. /Every/. /Time/.

You can stop being a troll any time you want. All you have to do, is to
start to use the Illumos operating system for your desktop, with CDE as
is proper on a Unix workstation. You can even use Xlibre because they
love their X server on all kinds of operating system, unlike x.org.

Now, once you've been illuminated enough by the Illumos operating system
your outer troll shell will turn into stone. There won't be a speck of
Rust on you.

And then, only then, can you stop being a troll on comp.lang.lisp!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 05/08/2026 10:50 AM, steve g wrote:

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:

[...]

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. >>>

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.

That's good. If you want to brush up on your German, this course looks
solid,


https://shop.thegreatcourses.com/learning-german-a-journey-through-language-and-culture

and I've been meaning to take it. Note that if you buy it now online,
you only get it streaming, so if you want to download it, you can look
for a DVD copy on Ebay.

I haven't checked if it's available on the binary discussion groups of
Usenet.

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.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

--8<-------------------------------------------------------->8---
Let Over Lambda (ISBN 978-1-4357-1275-1, 376+iv pp.) is one of the
most hardcore computer programming books out there. Starting with the
fundamentals, it describes the most advanced features of the most
advanced language: COMMON LISP. The point of this book is to expose
you to ideas that you might otherwise never be exposed to.

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.
--8<-------------------------------------------------------->8---

Source:
Doug Hoyte, https://letoverlambda.com/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/5/2026 3:26 AM, Johann 'Myrkraverk' Oskarsson wrote:

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/.

Yeah. Until its really bad. If you find yourself "needing" a GC, try to reevaluate your system.


[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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).



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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? 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. 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!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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 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.

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?

https://www.sbcl.org/manual/#networking

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.

Indeed. If you want to manipulate C code at the AST level, in C, all
you need to do is to hook your code with libclang. It's annoying to
use, because it's a private API for the fruit vendor, and mostly un- documented. That's why I basically gave up on using it in my own pro-
jects.


Good luck with libclang!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

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!

Have you tried shortwave radio? You'll get all kinds of people talking different languages; not to mention it is rather entertaining.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/8/2026 11:11 AM, Johann 'Myrkraverk' Oskarsson wrote:

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!

Kind of makes my ears go all pointy wrt, is that from an ai?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/10/2026 1:11 AM, Paul Rubin wrote:

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.

select works fine, but put it under pressure... Well, no so much... ;^o
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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 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.

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)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

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).

Both poll(2) and select(2) are fully supported POSIX interfaces.

select derives from BSD, poll derives from System V.

There are issues with select (due to the defintion of fd_set)
that make it unsuitable for certain applications (such as those
that use file descriptors greater than FD_SETSIZE).

https://pubs.opengroup.org/onlinepubs/9699919799/functions/select.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 11/08/2026 7:53 AM, Lawrence DrCOOliveiro wrote:

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).

Dear Lawrence,

You really don't keep up with the times. The /modern/ way to do this
is to install FreeBSD over whatever other Unix you may have installed,
and I suspect it's still S.C.O. UnixWare for you, and then use kqueues.

https://man.freebsd.org/cgi/man.cgi?kqueue

On the other hand, if you insist on using the illuminated operating sys-
stem without cross porting the kqueue mechanism, there's always the port
API.

https://www.illumos.org/man/3C/port_create


Happy queuing!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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 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.

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.

I also admit to just using the two or three available socket libraries
in QuickLisp, whenever I need to deal with raw sockets. I once imple-
mented a D.N.S. server -- or service -- in Common Lisp, that replied un- helpfully with an error message to every query, as a practice in the
D.N.S. protocol. I'm not sure if that source code is still public.

You can trivially make your own, if you need the D.N.S. protocol in
Common Lisp.

That code was then adopted and the D.N.S. protocol removed, to do some-
thing with raw U.D.P. datagrams. That is the beauty of sharing source
code; one never knows what other people do with it.

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.


Happy network coding in Common Lisp!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/08/2026 11:59 AM, Paul Rubin wrote:

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?

I admit ignorance of how io_uring works. I haven't done low level code
like this in Linux for a very long time, and I believe back then io_ur-
ing didn't exist.

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.


Hope that helps!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 09/08/2026 4:52 PM, tfb wrote:

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.

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


Happy coding disturbing things!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.
--
Alan Bawden
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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)>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

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.

Finally, every time that I open a PR with that pattern I get questioned
and frown. It's such disturbing.

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

unless you find some code base that use hash table all over the place.
:)

bix
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.

One of the calls you can do that way is opening a file. Historically in
Unix and Linux, there was no way to do that asynchronously. If you used
open() and the operation was slow (for example NFS, or even anything on
a hard disk), your program would be blocked until the call returned. If
you don't want to block, you have to do the open() in a separate thread.
GHC and Erlang BEAM have lightweight threads/processes, but they also
had a pool of OS threads to handle operations like opening files.

io_uring lets you open files asynchronously, so you can in principle
simulate an OS in a single user-level process. More typically though,
io_uring is used as an alternative to something like epoll, for
listening on lots of sockets at the same time. There are a lot of
benchmarks around that I think say io_uring is a little faster.
io_uring also can replace AIO, which never worked very well. AIO was
for asynchronous disk i/o operations after the file was already open.

I haven't had occasion to use io_uring yet but I saw its importance when
it first appeared.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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 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.

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.''
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/11/2026 8:59 PM, Paul Rubin wrote:

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?

io_uring is meant for io completion. Its more low level than IOCP over
on the windozer. Heck, on win, we can use it (IOCP) for files and
sockets. io_uring takes special care with padding and alignment to get
the mmapped memory to work with the kernel.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Paul Rubin <no.email@nospam.invalid> writes:

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.

Ah! I didn't understand your original question because I didn't have
the context of knowing what io_uring was. Thanks for introducing me to something new.
--
Alan Bawden
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place.
:)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables. Putting those two
features together made for an extremely useful high-level language,
which is what I think finally killed BASIC.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place.
:)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.
And hash tables were popular from Awk, which influenced Perl
as well.

Putting those two
features together made for an extremely useful high-level language,
which is what I think finally killed BASIC.

I don't see how you could come to that conclusion. Some folks
abandoned BASIC as early as possible, i.e. with any language
that is in any respect "better" (and there were many), and I
know other folks that still use a MS BASIC variant these days
for scripting. - Is it dead, is it alive? - Who cares...

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 13/08/2026 10:18 AM, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place.
:)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables. Putting those two features together made for an extremely useful high-level language,
which is what I think finally killed BASIC.

As always, Lawrence, you're mistaken about everything. I believe it was
A.W.K. that popularized both regular expressions and hash tables. Of
course, I'm now on a second thought about the has tables, but I'm abso-
lutely certain it was the A.W.K. programming language that popularized
the regular expressions, and that popularity is what drove people to
make Perl use basically the same syntax, a syntax that has also found
its way into Dtrace, which is a tool you've never used, because I don't
think the /Santa Cruz Operation/ ever put Dtrace into OpenServer. You
can correct me about that, if I'm wrong.

In any case, a casual web search, which too often relies on L.L.M. summ-
aries these days, seems to indicate both G.N.U. and the /Invisible Is-
land/ m- A.W.K. have hash tables built-in.

So now you get to correct me, if and only if, the hash tables in Perl
are older than any implementation of A.W.K. Good luck!

Now, on the subject of BASIC, I belive it was universities choosing
Wirth's Pascal as a first programming language in their curriculum
that killed B.A.S.I.C. Do you disagree with that?

Then of course, Borland Pascal with the Pascal edition of Turbo Vision
which is unrelated to /dark vision/ among magical creatures in fantasy literature, became extremely popular, and only managed to get replaced
by the Herculean efforts of Stroustrup's C++.


Or we'd all be coding our massively multiplayer online video games in
a dialect of Delphi!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/08/2026 3:50 PM, Lawrence DrCOOliveiro wrote:

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)>

Lawrence, we don't care about Posix here in comp.lang.lisp, nor do we
care about what the Linux kernel people think is a good idea. They al-
most never have good ideas anyway.

So stop trying to force Posix discussion into kqueues and Illumos ports,
unless you're also working for the Open Group, and trying to get some
things standardized.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/08/2026 3:23 PM, Alan Bawden wrote:

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.

Thank you. Are you aware of any book on this subject? One that teaches
the ins and outs of how to use kqueues in FreeBSD? Something similar to /Advanced Programming in the UNIX Environment/ by Stevens?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/12/2026 7:56 PM, Janis Papanagnou wrote:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

On the subject of Common Lisp, I find it more than disturbing when
a codebase lacks the basic usage of hash tables.

-a-a https://www.sbcl.org/manual/#hash-table-extensions

unless you find some code base that use hash table all over the place.
:)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.
And hash tables were popular from Awk, which influenced Perl
as well.

Putting those two
features together made for an extremely useful high-level language,
which is what I think finally killed BASIC.

I don't see how you could come to that conclusion. Some folks
abandoned BASIC as early as possible, i.e. with any language
that is in any respect "better" (and there were many), and I
know other folks that still use a MS BASIC variant these days
for scripting. - Is it dead, is it alive? - Who cares...

Basic is fun. Care a bit. Fwiw:

From the thread Macro issue...
(kind of miss google groups wrt linking...)

Basically using C++ to help generate BASIC code:




Humm... Actually, is this use of my macro(s), CT_ASB_*, okay for this
little code example I wrote to "help" me write AppleSoft BASIC? Can you
run it, is the code Kosher, so to speak, well, does it work for you or
not...? Any undefined behavior in my macro? The macros seem a bit
hackish, but they seem to work okay for now: ______________________________________
#include <iostream>
#include <sstream>


// Macro kosher? Seems to be...
namespace ct_basic {

struct program_counter {
unsigned long m_origin;
unsigned long m_cur;
unsigned long m_inc;
std::stringstream m_prog;

program_counter(
unsigned long cur = 0,
unsigned long inc = 10
) : m_origin(cur), m_cur(cur), m_inc(inc) {
}

void line(std::stringstream const& line0) {
m_prog << m_cur << " " << line0.str() << std::endl;
m_cur += m_inc;
}
};

#define CT_ASB_LINE(mp_pc, mp_x) \
{ \
std::stringstream line0; \
line0 << mp_x; \
(mp_pc).line(line0); \
}


#define CT_ASB_GOSUB(mp_pc0, mp_pc1, mp_indent) \
CT_ASB_LINE(mp_pc0, mp_indent "GOSUB " << mp_pc1.m_origin)
}


int
main()
{
{
std::cout << "ctBasic testing 123... :^)\n";
std::cout << "__________________________\n";

{

ct_basic::program_counter pc0(100);
ct_basic::program_counter pc1(1000);

// ct_main
{
ct_basic::program_counter& PC = pc0;

CT_ASB_LINE(PC, "REM ct_main");
CT_ASB_LINE(PC, " PRINT \"ct_main\"");
CT_ASB_GOSUB(PC, pc1, " ");
CT_ASB_LINE(PC, "END");
}

// ct_init
{
ct_basic::program_counter& PC = pc1;

CT_ASB_LINE(PC, "REM ct_init");
CT_ASB_LINE(PC, " PRINT \"ct_init\"");
CT_ASB_LINE(PC, "RETURN");
}

std::cout << pc0.m_prog.str() << "\n\n";
std::cout << pc1.m_prog.str() << "\n\n";
}

std::cout << "__________________________\n";
}

std::cout << "Complete! Well, time to test the\n";
std::cout << "generated AppleSoft BASIC";

return 0;
}
______________________________________


Fwiw, I get an output of:

ctBasic testing 123... :^)
__________________________
100 REM ct_main
110 PRINT "ct_main"
120 GOSUB 1000
130 END


1000 REM ct_init
1010 PRINT "ct_init"
1020 RETURN


__________________________
Complete! Well, time to test the
generated AppleSoft BASIC







100 REM ct_vfield_applesoft_basic
110 HOME
120 HGR: HCOLOR = 3: VTAB 22
130 PRINT "ct_vfield_applesoft_basic"
140 GOSUB 1000
150 GOSUB 3000
160 SP = 0
170 RS(SP, 0) = 0
180 RS(SP, 1) = -1
190 RS(SP, 2) = 0
200 RS(SP, 3) = 1
210 RS(SP, 4) = 0
220 GOSUB 8000
230 V1(1) = 0: V1(2) = 0: V1(3) = 1: V1(4) = 128
240 GOSUB 6000
245 PRINT "Chris Thomasson's Koch Complete!"
250 END

1000 REM ct_init
1010 PRINT "ct_init"
1020 DIM A0(6)
1030 DIM V0(4)
1040 DIM V1(4)
1050 DIM V2(4)
1060 DIM V3(4)
1070 DIM V4(4)
1080 DIM V5(4)
1090 RN = 3
1100 DIM RS(RN, 16)
1110 GOSUB 2000
1120 RETURN

2000 REM ct_init_plane
2010 PRINT "ct_init_plane"
2020 A0(1) = 279: REM m_plane.m_width
2030 A0(2) = 191: REM m_plane.m_height
2040 A0(3) = 0.0126106: REM m_plane.m_xstep
2050 A0(4) = 0.0126316: REM m_plane.m_ystep
2060 A0(5) = -1.75288: REM m_plane.m_axes.m_xmin
2070 A0(6) = 1.2: REM m_plane.m_axes.m_ymax
2080 RETURN

3000 REM ct_display_plane
3010 PRINT "ct_display_plane"
3020 FOR I0 = 1 TO 6
3030 PRINT "A0("; I0; ") = " A0(I0)
3040 NEXT I0
3050 RETURN

4000 REM ct_project_point
4010 REM PRINT "ct_project_point"
4020 V0(3) = (V0(1) - A0(5)) / A0(3)
4030 V0(4) = (A0(6) - V0(2)) / A0(4)
4040 IF V0(3) < 0 THEN V0(3) = INT(V0(3) - .5)
4050 IF V0(3) >= 0 THEN V0(3) = INT(V0(3) + .5)
4060 IF V0(4) < 0 THEN V0(4) = INT(V0(4) - .5)
4070 IF V0(4) >= 0 THEN V0(4) = INT(V0(4) + .5)
4080 RETURN

5000 REM ct_plot_point
5010 REM PRINT "ct_plot_point"
5020 GOSUB 4000
5030 IF V0(3) > -1 AND V0(3) <= A0(1) AND V0(4) > -1 AND V0(4) <=
A0(2) THEN HPLOT V0(3), V0(4)
5040 RETURN

6000 REM ct_plot_circle
6010 PRINT "ct_plot_circle"
6020 AB = 6.28318 / V1(4)
6030 FOR I1 = 0 TO 6.28318 STEP AB
6040 V0(1) = V1(1) + COS(I1) * V1(3)
6050 V0(2) = V1(2) + SIN(I1) * V1(3)
6060 GOSUB 5000
6070 NEXT I1
6080 RETURN

7000 REM ct_plot_line
7010 PRINT "ct_plot_line"
7020 V0(1) = V5(1): V0(2) = V5(2)
7030 GOSUB 4000
7040 IF V0(3) < 0 THEN V0(3) = 0
7050 IF V0(3) > A0(1) THEN V0(3) = A0(1)
7060 IF V0(4) < 0 THEN V0(4) = 0
7070 IF V0(4) > A0(2) THEN V0(4) = A0(2)
7080 HPLOT V0(3), V0(4)
7090 V0(1) = V5(3): V0(2) = V5(4)
7100 GOSUB 4000
7110 IF V0(3) < 0 THEN V0(3) = 0
7120 IF V0(3) > A0(1) THEN V0(3) = A0(1)
7130 IF V0(4) < 0 THEN V0(4) = 0
7140 IF V0(4) > A0(2) THEN V0(4) = A0(2)
7150 HPLOT TO V0(3), V0(4)
7160 RETURN

8000 REM ct_koch
8010 IF RS(SP, 0) >= RN THEN RETURN
8020 PRINT "ct_koch = "; RS(SP, 0); " "; RS(SP, 1); " "; RS(SP, 2);
" "; RS(SP, 3); " "; RS(SP, 4)"
8030 RS(SP, 5) = RS(SP, 3) - RS(SP, 1) : REM difx
8040 RS(SP, 6) = RS(SP, 4) - RS(SP, 2) : REM dify
8050 RS(SP, 7) = RS(SP, 1) + RS(SP, 5) / 2 : REM dify
8060 RS(SP, 8) = RS(SP, 2) + RS(SP, 6) / 2 : REM dify
8070 RS(SP, 9) = -RS(SP, 6) : REM perpx
8080 RS(SP, 10) = RS(SP, 5) : REM perpy
8090 RS(SP, 11) = RS(SP, 7) + RS(SP, 9) / 3 : REM tipx
8100 RS(SP, 12) = RS(SP, 8) + RS(SP, 10) / 3 : REM tipy
8110 RS(SP, 13) = RS(SP, 1) + RS(SP, 5) / 3 : REM k0x
8120 RS(SP, 14) = RS(SP, 2) + RS(SP, 6) / 3 : REM k0y
8130 RS(SP, 15) = RS(SP, 3) - RS(SP, 5) / 3 : REM k1x
8140 RS(SP, 16) = RS(SP, 4) - RS(SP, 6) / 3 : REM k1y

8145 IF RS(SP, 0) < RN - 1 GOTO 8230
8150 V5(1) = RS(SP, 1): V5(2) = RS(SP, 2): V5(3) = RS(SP, 13): V5(4)
= RS(SP, 14)
8160 GOSUB 7000
8170 V5(1) = RS(SP, 13): V5(2) = RS(SP, 14): V5(3) = RS(SP, 11):
V5(4) = RS(SP, 12)
8180 GOSUB 7000
8190 V5(1) = RS(SP, 11): V5(2) = RS(SP, 12): V5(3) = RS(SP, 15):
V5(4) = RS(SP, 16)
8200 GOSUB 7000
8210 V5(1) = RS(SP, 15): V5(2) = RS(SP, 16): V5(3) = RS(SP, 3):
V5(4) = RS(SP, 4)
8220 GOSUB 7000

8230 REM line 0
8240 SP = SP + 1
8250 RS(SP, 0) = RS(SP - 1, 0) + 1
8260 RS(SP, 1) = RS(SP - 1, 1)
8270 RS(SP, 2) = RS(SP - 1, 2)
8280 RS(SP, 3) = RS(SP - 1, 13)
8290 RS(SP, 4) = RS(SP - 1, 14)
8300 GOSUB 8000
8310 SP = SP - 1
8320 REM line 1
8330 SP = SP + 1
8340 RS(SP, 0) = RS(SP - 1, 0) + 1
8350 RS(SP, 1) = RS(SP - 1, 13)
8360 RS(SP, 2) = RS(SP - 1, 14)
8370 RS(SP, 3) = RS(SP - 1, 11)
8380 RS(SP, 4) = RS(SP - 1, 12)
8390 GOSUB 8000
8400 SP = SP - 1
8410 REM line 2
8420 SP = SP + 1
8430 RS(SP, 0) = RS(SP - 1, 0) + 1
8440 RS(SP, 1) = RS(SP - 1, 11)
8450 RS(SP, 2) = RS(SP - 1, 12)
8460 RS(SP, 3) = RS(SP - 1, 15)
8470 RS(SP, 4) = RS(SP - 1, 16)
8480 GOSUB 8000
8490 SP = SP - 1
8500 REM line 3
8510 SP = SP + 1
8520 RS(SP, 0) = RS(SP - 1, 0) + 1
8530 RS(SP, 1) = RS(SP - 1, 15)
8540 RS(SP, 2) = RS(SP - 1, 16)
8550 RS(SP, 3) = RS(SP - 1, 3)
8560 RS(SP, 4) = RS(SP - 1, 4)
8570 GOSUB 8000
8580 SP = SP - 1
8590 RETURN

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place.
:)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.

It was Ken Thompson who first put them in such practical use. And I
would guess it was in ed. And from ed, grep sprung as an executable.

And hash tables were popular from Awk, which influenced Perl as well.

And the reason I don't use Perl myself: if the program gets larger, I
choose Common Lisp. The rich syntax of Perl has never been too kind on
me, but I always wrote Perl happy (unlike Java, which always had the
same fate of Basic [to me]).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-08-13 17:25, Anton Antimo wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place. >>>> :)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.

It was Ken Thompson who first put them in such practical use. And I
would guess it was in ed. And from ed, grep sprung as an executable.

Yes, and add all the grep variants, then sed, awk, pager programs,
ex/vi, expr, and more (tcl, m4, lex may be amongst them but I'm not
sure they had regexps from the beginning).

And there was a C-library available, so one could easily add regexp
functions to own tools!

And hash tables were popular from Awk, which influenced Perl as well.

And the reason I don't use Perl myself: if the program gets larger, I
choose Common Lisp. The rich syntax of Perl has never been too kind on
me, but I always wrote Perl happy (unlike Java, which always had the
same fate of Basic [to me]).

Oh, I've never seen Java and Basic mentioned in one sentence before.

At least we have got some nice abbreviated forms for regex elements
from Perl; mostly syntactic sugar, maybe, but very useful, IMO. Good
that they spread also into other regexp supporting tools so that you
don't have to buy Perl just for the accommodating regexp formulations.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 8/13/2026 10:01 AM, Janis Papanagnou wrote:

On 2026-08-13 17:25, Anton Antimo wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

On the subject of Common Lisp, I find it more than disturbing when >>>>>> a codebase lacks the basic usage of hash tables.

-a-a-a https://www.sbcl.org/manual/#hash-table-extensions

unless you find some code base that use hash table all over the place. >>>>> :)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.

It was Ken Thompson who first put them in such practical use.-a And I
would guess it was in ed.-a And from ed, grep sprung as an executable.

Yes, and add all the grep variants, then sed, awk, pager programs,
ex/vi, expr, and more (tcl, m4, lex may be amongst them but I'm not
sure they had regexps from the beginning).

And there was a C-library available, so one could easily add regexp
functions to own tools!

And hash tables were popular from Awk, which influenced Perl as well.

And the reason I don't use Perl myself: if the program gets larger, I
choose Common Lisp.-a The rich syntax of Perl has never been too kind on
me, but I always wrote Perl happy (unlike Java, which always had the
same fate of Basic [to me]).

Oh, I've never seen Java and Basic mentioned in one sentence before.

Run the program I posted in this thread on this online applesoft basic emulator written i Java:

https://www.calormen.com/jsbasic/

;^)

At least we have got some nice abbreviated forms for regex elements
from Perl; mostly syntactic sugar, maybe, but very useful, IMO. Good
that they spread also into other regexp supporting tools so that you
don't have to buy Perl just for the accommodating regexp formulations.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 13 Aug 2026 12:25:55 -0300, Anton Antimo wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

Perl was a major advance on, I would say, two counts: it
popularized regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.

It was Ken Thompson who first put them in such practical use. And I
would guess it was in ed. And from ed, grep sprung as an executable.

And hash tables were popular from Awk, which influenced Perl as
well.

Notice whatrCOs missing: putting the two together into a common, much more powerful tool.

Awk was a precursor of this: but Perl does everything Awk can do, just
as concisely, and a lot more besides.

The rich syntax of Perl has never been too kind on me, but I always
wrote Perl happy (unlike Java, which always had the same fate of
Basic [to me]).

I did use Perl a lot for a while. But I always got the feeling that
there were things going on I never quite fully understood. Looking at
frequent examples of rCLobfuscated PerlrCY just confirmed that impression.

Then I discovered Python. Maybe not quite as concise (i.e. cryptic) as
Perl in some ways, but actually just as powerful, and in a more
digestible form.

It is not a coincidence that the Python community attracts the best
minds to keep building on it nowadays.

And the reason I don't use Perl myself: if the program gets larger,
I choose Common Lisp.

People say rCLCommon LisprCY, but no vanilla implementation of that would
be worth using nowadays.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

(Given I'm commenting on the content of the online manual on a Linux
system, I'm adding and followingup-to comp.os.linux.misc.)

On 2026-08-11, Lawrence DrCOOliveiro wrote:

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).

The online manual here (a GNU/Linux system) says:

"poll, ppoll - wait for some event on a file descriptor"

Perhaps that should be rewritten. Reading further, it's not singular,
but that description with "*A* file descriptor" does make it sound like
poll is not a suitable replacement for select.
--
Nuno Silva

(Not subscribed to comp.lang.c)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-13 17:25, Anton Antimo wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place. >>>>> :)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.

It was Ken Thompson who first put them in such practical use. And I
would guess it was in ed. And from ed, grep sprung as an executable.

Yes, and add all the grep variants, then sed, awk, pager programs,
ex/vi, expr, and more (tcl, m4, lex may be amongst them but I'm not
sure they had regexps from the beginning).

And there was a C-library available, so one could easily add regexp
functions to own tools!

And hash tables were popular from Awk, which influenced Perl as well.

And the reason I don't use Perl myself: if the program gets larger,
I
choose Common Lisp. The rich syntax of Perl has never been too kind on
me, but I always wrote Perl happy (unlike Java, which always had the
same fate of Basic [to me]).

Oh, I've never seen Java and Basic mentioned in one sentence before.

Lol. Don't take it seriously. I've never really used Basic and while I
tried dove into Java with a lot of enthusiasm (as I did with C++ after
feeling I was very good with C), I really couldn't continue---too much bureaucracy, I felt.

At least we have got some nice abbreviated forms for regex elements
from Perl; mostly syntactic sugar, maybe, but very useful, IMO. Good
that they spread also into other regexp supporting tools so that you
don't have to buy Perl just for the accommodating regexp formulations.

In ``Let Over Lambda'', Doug Hoyte guides you into implementing this
side of Perl in Common Lisp. In the prerequisites, he shows very neat
ideas in macro writing.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <115jbp0$189sr$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place.
:)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.
And hash tables were popular from Awk, which influenced Perl
as well.

Hash tables for fast lookups had been known for decades before
awk was written, and regular expressions applied to text
processing predate Unix by some years. Thompson's paper
described a technique (what has come to be known as "Thompson's
Construction") used on the IBM 7090 computer, predating Multics.

To bring this back to C, the expression of Thompson's
construction in C is rather straight-forward and elegant, and an
early example in K&R and K&R2 is implementing a hash table, with
closed addressing and chaining for collision resolution.
(Comparing the algorithms used between the two editions is
constructive).

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <8733wijb3w.fsf@safunu.org>, Anton Antimo <anton@safunu.org> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the place. >>>> :)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.

It was Ken Thompson who first put them in such practical use. And I
would guess it was in ed. And from ed, grep sprung as an executable.

Ken certainly popularized their use, though not in ed: it was in
QED, which predated ed by some number of years, and was used on
CTSS. Thompson's CACM paper on NFA simulation predated Unix
(and thus ed) by a year or so:
https://dl.acm.org/doi/10.1145/363347.363387

- Dan C.

(I think I said he targeted the 7090 in another post; it was the
7094, which was an upgraded 7090)

And hash tables were popular from Awk, which influenced Perl as well.

And the reason I don't use Perl myself: if the program gets larger, I
choose Common Lisp. The rich syntax of Perl has never been too kind on
me, but I always wrote Perl happy (unlike Java, which always had the
same fate of Basic [to me]).

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 13 Aug 2026 02:18:14 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the
place. :)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables. Putting those two features together made for an extremely useful high-level language,
which is what I think finally killed BASIC.

I would not call popularizing regular expression an advance.
IMHO, their popularity is rather unfortunate fact of computing life.
They are major attractor of mistakes and major source of surprize.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-08-14 14:17, Dan Cross wrote:

In article <115jbp0$189sr$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 2026-08-13 04:18, Lawrence DrCOOliveiro wrote:

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables.

Regexps were popular from many Unix tools before Perl came up.
And hash tables were popular from Awk, which influenced Perl
as well.

Hash tables for fast lookups had been known for decades before
awk was written, and regular expressions applied to text
processing predate Unix by some years. Thompson's paper
described a technique (what has come to be known as "Thompson's Construction") used on the IBM 7090 computer, predating Multics.

Yes, sure. (And I didn't claim that Unixes were where they first
appeared.) But above we spoke about their popularization.[*]

Would you also say that these appearances made Regexps "popular"?

With the dissemination of the Unixes they certainly became widely
popular; this is at least my observation.

Concerning hash tables, I haven't the whole historic picture here
(i.e. where they were implemented, their grade of dissemination
and popularity) beyond that they're comparably old as concept; my
point was just that Perl was not the "popularizing factor". In
(standard-)Awk they are actually the only non-primitive data type
available (as opposed to Perl or early Shells, the latter even with
only severely restricted arrays).

Janis

[*] I'm not sure you meant your post as addendum or corrigendum.

[...]

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-08-14 14:30, Michael S wrote:

On Thu, 13 Aug 2026 02:18:14 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

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

unless you find some code base that use hash table all over the
place. :)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables. Putting those two
features together made for an extremely useful high-level language,
which is what I think finally killed BASIC.

I would not call popularizing regular expression an advance.

Thanks for your opinion.

IMHO, their popularity is rather unfortunate fact of computing life.
They are major attractor of mistakes and major source of surprize.

Yes mistakes can happen everywhere, even when writing of posts
("surprize"). :-) And surprises appear where ignorance rules.

Regexps, OTOH, while appearing cryptic to the uninitiated, allow
in a compact way powerful search and match expression. Emulating
them by code is IME much more error-prone, though. They actually
help to reduce programming errors; this is my experience. (YMMV.)

Personally I used and appreciated them from the beginning. And
whenever I came in system contexts where they were not available
(back then typically in MS contexts) I cursed these systems for
their outdated primitive concepts that just made ones live hard.

You may be too old to learn or master them now but for the younger
folks around I strongly suggest to learn the concept of Regular
Expressions and identify where they can advantageously be used. It
certainly pays!

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 14/08/2026 16:45, Janis Papanagnou wrote:

On 2026-08-14 14:30, Michael S wrote:

On Thu, 13 Aug 2026 02:18:14 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

On the subject of Common Lisp, I find it more than disturbing when
a codebase lacks the basic usage of hash tables.

-a-a https://www.sbcl.org/manual/#hash-table-extensions

unless you find some code base that use hash table all over the
place. :)

Perl was a major advance on, I would say, two counts: it popularized
regular expressions, and it popularized hash tables. Putting those two
features together made for an extremely useful high-level language,
which is what I think finally killed BASIC.

I would not call popularizing regular expression an advance.

Thanks for your opinion.

IMHO, their popularity is rather unfortunate fact of computing life.
They are major attractor of mistakes and major source of surprize.

Yes mistakes can happen everywhere, even when writing of posts
("surprize"). :-)-a And surprises appear where ignorance rules.

Regexps, OTOH, while appearing cryptic to the uninitiated, allow
in a compact way powerful search and match expression. Emulating
them by code is IME much more error-prone, though. They actually
help to reduce programming errors; this is my experience. (YMMV.)

Personally I used and appreciated them from the beginning. And
whenever I came in system contexts where they were not available
(back then typically in MS contexts) I cursed these systems for
their outdated primitive concepts that just made ones live hard.

You may be too old to learn or master them now but for the younger
folks around I strongly suggest to learn the concept of Regular
Expressions and identify where they can advantageously be used. It
certainly pays!

Janis

While I think it is reasonable to learn the ideas of regular
expressions, and a little of the simplest and most common types, I don't
think it is practical for anyone to learn to "master" regexs. For one
thing, there are a dozen different variations. And while a lot of
people find them useful on occasion, few need them regularly enough to
be confident in writing them (or reading them, which can often be harder).

Fortunately, there is no good reason for mastering them unless you
really do have a lot of use of them. There are countless online
"generator" sites for them, as well as for testing them or interpreting existing ones (when you are faced with the "fun" of debugging someone
else's regex).

Like most things, they can be a useful tool, but some people get overly
smart about them and produce monstrosities that no one understands and
are impossible to debug or maintain. Keep them reasonable, and they are
fine.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-08-14 17:15, David Brown wrote:

[...]

While I think it is reasonable to learn the ideas of regular
expressions, and a little of the simplest and most common types, I don't think it is practical for anyone to learn to "master" regexs.

Mastering them comes from alone once you make an informed start
(and not pause in stasis).

(To me it appears like mathematics in real life; the majority of
folks in my country regularly says things like "it's confusing",
"it's complicated", "we don't expect that understand that (as I
don't)", "it's normal that one cannot understand that", "math is
just difficult", and so on. Children get systematically repelled
to listening and learning maths, they quit at the first obstacle
they encounter. - I'm recognizing the same discussion mechanics
in our IT domain with Regexps. - Here in this thread that they'd
"attract mistakes".)

As with many things we start with "the simplest and most common
types" (as you formulated it). But there's no reason to stop if
you want to get more productive.

(Reminds me how some folks using the Vi editor; and completely
missing the power it evolves when getting past 'i' and 'Esc'.
If you are modest and feel comfortable with that it's okay, as
it's okay if you use only primitive elements of Regexps. But if
you use it for editing power you should continue learn not only
the concept but also the non-trivialities, and you'll observe
that your skill will not get twice as fast but magnitudes. That
is not much different from other areas; including Regexps.)

For one thing, there are a dozen different variations.

This is true; certainly for different applications. But so what?
Are you saying that you have no problems switching to other tools
but the differences between the advanced regexp implementations
is an issue? If that is so for you, fair enough.

(BTW, for me it's at most only half a dozen that I occasionally
use.)

But at least we have a couple _common classes_ to distinguish.
POSIX standardized BRE and ERE or the pleasing PCRE (from Perl),
are the historically widely spread ones.

I observe that especially the basics (that you focused on above)
are widely the same. The details and differences come when you get
into it; in one tool the + meta-symbol isn't supported at all, in
another it needs an escape \+ . - Yes, that's what mastering may
mean, to know that. But you can also just try, in case you didn't
want to read the manual first. - Myself, in case of doubt, I just
try it, and I test my regexps, as I test my other program code.

And while a lot of
people find them useful on occasion, few need them regularly enough to
be confident in writing them (or reading them, which can often be harder).

Well, I cannot speak for "lot of people"; I can speak for myself,
friends with IT (or CS) background, and the people from the areas
I worked in during the past decades. - Where Regexps were sensible
to use those people just used them.

I mentioned in my previous post already that they may be "appearing
cryptic to the uninitiated". So I'd like to emphasize again that at
least some engagement is necessary to learn them. Otherwise you're
completely lost of course.

(Imagining a similar uninformed approach to some uninitiated "C"
programmers; and things like *p--, or C's declaration syntax.
"Here are a set of symbols, now go compose your C-programs!".
The Regexps are compared to the C-language like a piece of cake!)

At some (early point) of learning writing them is okay but reading
third-party Regexps may be a problem; in complex cases. - That is
correct. But no one prevents you from *commenting* complex Regexps
where they appear (as you should comment complex code). In case of
undocumented code decomposition helps; this method is as well not
restricted to Regexps. And some tools that support Regexps allow
composing them (like a BNF specification; very readable, been there
done that).

(If I imagine the bulk of code I'd have to write to replace a Regexp
I'm shuddering, and I'm pity for those who have been repelled from
learning them by the spread commonplace myths and FUD.)

Fortunately, there is no good reason for mastering them unless you
really do have a lot of use of them.

It's a personal choice whether you want to master them or just know
the concepts deeply enough to judge its application value. (Or if
you decide to abstain in advance, because they "attract mistakes"
or are "too difficult", or there are "too many subtle differences"
to even start using them.)

Yes. If you have no reason to use them you not only have no need to
master them but also not use them in the first place. - It's just a
pity if one cannot recognize where their applications would benefit.

There are countless online
"generator" sites for them, as well as for testing them or interpreting existing ones (when you are faced with the "fun" of debugging someone
else's regex).

Well, this I consider a counterproductive statement, but certainly
in the company of other "don't learn them" statements quoted above.

In this vein let me add to let an AI formulate (and analyze) your
Regexps. </sarcasm>

Like most things, they can be a useful tool, but some people get overly smart about them and produce monstrosities that no one understands and
are impossible to debug or maintain.-a Keep them reasonable, and they are fine.

I've seen monstrosities of Regexps as I've seen monstrosities of "C"
(or other) code. The problem there were always the programmers, not
"C", not Regexps.

What are the alternatives to Regexps (or Regexp-monstrosities)?

If you can answer that question the "problems" vanish into thin air.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown <david.brown@hesbynett.no> writes:
[...]

While I think it is reasonable to learn the ideas of regular
expressions, and a little of the simplest and most common types, I
don't think it is practical for anyone to learn to "master" regexs.
For one thing, there are a dozen different variations. And while a
lot of people find them useful on occasion, few need them regularly
enough to be confident in writing them (or reading them, which can
often be harder).

[...]

My own experience is very different. I won't comment further, since
this is not about C.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Fri, 14 Aug 2026 08:27:44 -0300, Anton Antimo wrote:

I've never really used Basic and while I tried dove into Java with a
lot of enthusiasm (as I did with C++ after feeling I was very good
with C), I really couldn't continue---too much bureaucracy, I felt.

rCLBureaucracyrCY is absolutely a good word to sum up Java.
--- Synchronet 3.22a-Linux NewsLink 1.2