Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.lisp > #60742 > unrolled thread
| Started by | Mario Rosell <mario@mariorosell.es> |
|---|---|
| First post | 2026-02-20 22:53 +0100 |
| Last post | 2026-06-03 03:16 +0000 |
| Articles | 20 on this page of 181 — 20 participants |
Back to article view | Back to comp.lang.lisp
Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-20 22:53 +0100
Re: Resources to learn common lisp? Ben Bacarisse <ben@bsb.me.uk> - 2026-02-20 22:00 +0000
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:25 +0100
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-02-21 10:24 -0500
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-21 21:30 +0000
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-22 01:08 +0100
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 04:59 +0000
Re: Resources to learn common lisp? Madhu <enometh@meer.net> - 2026-02-22 10:59 +0530
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 21:48 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:43 -0400
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:41 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-08 20:02 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:23 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:28 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:32 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:27 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:33 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:16 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:53 +0000
Re: Resources to learn common lisp? Axel Reichert <mail@axel-reichert.de> - 2026-06-09 12:07 +0200
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:14 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-17 00:01 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 05:53 +0000
[OT] Disappearing documentation (was: Re: Resources to learn common lisp?) Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-17 09:06 +0100
Re: [OT] Disappearing documentation steve g <Sgonedes1977@gmail.com> - 2026-06-19 19:05 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 19:01 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 00:02 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:22 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:59 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:43 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:45 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:35 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:37 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:33 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:22 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-09 01:22 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:17 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:50 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:40 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:26 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:10 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 21:37 -0700
Re: Resources to learn common lisp? Joerg Mertens <joerg-mertens@t-online.de> - 2026-06-17 12:04 +0200
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-17 11:17 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 13:57 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:06 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 09:17 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 13:32 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-18 14:21 -0700
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-19 08:12 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-19 04:27 -0700
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 21:24 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-20 13:00 -0400
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-18 12:53 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-18 21:28 -0400
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-19 15:08 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-19 22:32 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-20 13:56 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-20 13:43 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 19:06 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:27 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:12 -0400
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:24 -0400
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:57 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-11 21:07 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 13:06 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:13 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:25 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 08:25 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:46 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:52 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:57 +0000
Re: Resources to learn common lisp? Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-15 10:10 +0100
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:56 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:03 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 07:52 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 20:56 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-13 00:55 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:43 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:37 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:09 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:02 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 10:12 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:54 -0400
Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-17 00:07 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 08:33 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:48 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:28 -0400
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:42 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:32 -0400
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-09 09:36 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:06 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-10 08:43 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:22 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-11 08:57 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:42 -0400
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:15 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:42 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:19 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:18 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:27 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 01:25 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-17 10:13 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 13:57 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:11 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-18 02:30 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-18 09:32 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 14:15 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:53 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 05:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-17 01:43 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 01:07 +0000
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:58 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-19 18:52 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 00:04 +0000
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 06:37 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:30 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:58 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:46 -0700
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-15 06:59 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-15 12:25 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:42 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:34 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:11 +0000
Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-13 04:06 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:37 -0700
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 21:25 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 15:26 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:37 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:34 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:43 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:23 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:29 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 04:59 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:10 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 13:34 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:36 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:43 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-14 10:36 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 23:55 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 18:04 -0700
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 12:33 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-15 09:51 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 03:14 -0700
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:29 -0700
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-16 10:23 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 21:34 -0700
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-17 15:02 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 04:14 +0000
Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-18 12:44 -0400
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 13:14 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 02:30 +0000
Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-18 15:34 +0000
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 07:01 +0000
Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-19 11:41 +0000
Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:22 -0700
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:55 +0000
Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-02-20 17:44 -0500
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:30 +0100
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-20 23:50 +0000
Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-21 00:24 +0000
Re: Resources to learn common lisp? Andreas Eder <a_eder_muc@web.de> - 2026-02-21 11:36 +0100
Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:44 +0100
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-03-31 17:47 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 23:41 +0000
Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-04-01 13:23 -0400
Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:59 -0400
Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:52 -0400
Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:57 -0400
Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 11:06 -0400
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-01 14:56 -0400
Re: Resources to learn common lisp? "Robert B. Carleton" <rbc@rbcarleton.net> - 2026-06-01 23:02 +0000
Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-02 21:32 -0400
Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-03 03:16 +0000
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-19 19:06 -0400 |
| Message-ID | <87y0gai0zb.fsf@gmail.com> |
| In reply to | #60942 |
Paul Rubin <no.email@nospam.invalid> writes: > That's Perl living up to its own motto, "there's more than one way to do > it". ;-) Yes, I do love PERL! thanx for the remembrance...
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-06-11 05:27 -0400 |
| Message-ID | <4muk2llts0ljgn94ebvcgr7073up4mg0qj@4ax.com> |
| In reply to | #60844 |
On Wed, 10 Jun 2026 12:40:48 -0400, steve g <sgonedes1977@gmail.com> wrote: >with all due respect, garbage collection is very difficult. Most >programmers will use the best algorithm available; like guile does. PERL >is the fastest interpreter I have ever used, compiling the code to C >results in slower running speed. There is an issue with heap... There is no one "best" algorithm. GC is not "difficult" per se, but it is exacting and tedious to get correct. GC is heavily dependent on - and often integrated with - the allocation methods used, so heap layouts and data formats generally determine what is the most effective method. Moreover, any implementation that is not a toy will be a hybrid using multiple different algorithms - short term data, long term data, and "large" data (for some definition of "large") all routinely will be handled differently. Aside: reference counting doesn't work for cyclic data structures, so although it is a valid method, it has to have some form of heap sweeping backup if cyclic data structures are to be permitted.
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 22:12 -0400 |
| Message-ID | <8733ylrk2j.fsf@gmail.com> |
| In reply to | #60848 |
George Neuner <gneuner2@comcast.net> writes: > On Wed, 10 Jun 2026 12:40:48 -0400, steve g <sgonedes1977@gmail.com> > wrote: > > >>with all due respect, garbage collection is very difficult. Most >>programmers will use the best algorithm available; like guile does. PERL >>is the fastest interpreter I have ever used, compiling the code to C >>results in slower running speed. There is an issue with heap... > > There is no one "best" algorithm. > > GC is not "difficult" per se, but it is exacting and tedious to get > correct. GC is heavily dependent on - and often integrated with - the > allocation methods used, so heap layouts and data formats generally > determine what is the most effective method. > > Moreover, any implementation that is not a toy will be a hybrid using > multiple different algorithms - short term data, long term data, and > "large" data (for some definition of "large") all routinely will be > handled differently. > > > Aside: reference counting doesn't work for cyclic data structures, so > although it is a valid method, it has to have some form of heap > sweeping backup if cyclic data structures are to be permitted. (setq *PRINT-CIRCLE* t)
[toc] | [prev] | [next] | [standalone]
| From | steve g <sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-10 12:24 -0400 |
| Message-ID | <87ecie2wj0.fsf@gmail.com> |
| In reply to | #60830 |
Alan Bawden <alan@csail.mit.edu> writes: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: > < > Lisp is purely garbage-collected though, isn’t it? yes common lisp uses GC. <> Languages like Perl < > and Python try for a hybrid reference-counted/garbage-collected < > approach, for speed and also more deterministic memory usage in many < > common scenarios. what about C ? " The Boehm-Demers-Weiser conservative garbage collector can be used as a garbage collecting replacement for C malloc or C++ new. 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. A simple example of such a use is given here." > I don't think any of Common Lisp, Java, Perl or Python promise to employ > any particular algorithm for collecting garbage. It's not something you > really need to put in your language specification document. All you > need to say is that storage management is not something the programmer > needs to worry about. Nothing prevents you from implementing a Common > Lisp that does reference counting. you must be a newbie. > It seems to be fashionable these days to consider reference counting to > be somehow different from garbage collection, but historically reference > counting was just another tool used for garbage collection. At least > one of the InterLisp implementations used reference counting as part of > its garbage collector, and nobody thought that it had less of a true > garbage collector as a result. Hmmm. Seriously, my once a month statement is to read Baker: "Henry Givens Baker Jr. is an American computer scientist who has made contributions in garbage collection, functional programming languages, and linear logic. He was one of the founders of Symbolics, a company that designed and manufactured a line of Lisp machines. In 2006, he was recognized as an ACM Distinguished Member." He is notable for his research in garbage collection, particularly Baker's real-time copying collector, and on the Actor model. Baker received his B.Sc. (1969), S.M. (1973), E.E. (1973), and Ph.D. (1978) degrees at M.I.T. " just google for Henry baker +lisp +GC . When I program in C I do not use GC, I use exit.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-06-11 05:57 -0400 |
| Message-ID | <o90l2lh6t92787445ks8tt3iid03p2te73@4ax.com> |
| In reply to | #60842 |
On Wed, 10 Jun 2026 12:24:51 -0400, steve g <sgonedes1977@gmail.com> wrote: > >Seriously, my once a month statement is to read Baker: > >"Henry Givens Baker Jr. is an American computer scientist who has made >contributions in garbage collection, functional programming languages, >and linear logic. He was one of the founders of Symbolics, a company >that designed and manufactured a line of Lisp machines. In 2006, he was >recognized as an ACM Distinguished Member." > >He is notable for his research in garbage collection, particularly >Baker's real-time copying collector, and on the Actor model. > >Baker received his B.Sc. (1969), S.M. (1973), E.E. (1973), and Ph.D. >(1978) degrees at M.I.T. >" > >just google for >Henry baker +lisp +GC Baker advocated what is generally known as the "full black" barrier in terms of the tri-color abstraction. Baker felt that the mutator (ie. the program) should only ever see black data - never white or gray - and most of his systems employed black allocation and rather heavy handed read barriers to guarantee it. The problem is that black data always will be retained through the next collection, and studies have shown that - at least for Lispy and FP languages - a large percentage of new allocations will die before the next collection starts. Baker's systems don't permit the memory to be reclaimed until (at least) the 2nd GC cycle following its allocation. So while I agree that Baker is excellent reading for GC theory, his implementation proposals should be taken with a dose of salt as many of them are not terribly efficient in practice.
[toc] | [prev] | [next] | [standalone]
| From | Alan Bawden <alan@csail.mit.edu> |
|---|---|
| Date | 2026-06-11 21:07 -0400 |
| Message-ID | <86zf10sh11.fsf@williamsburg.bawden.org> |
| In reply to | #60842 |
steve g <sgonedes1977@gmail.com> writes: > Alan Bawden <alan@csail.mit.edu> writes: > >> I don't think any of Common Lisp, Java, Perl or Python promise to employ >> any particular algorithm for collecting garbage. It's not something you >> really need to put in your language specification document. All you >> need to say is that storage management is not something the programmer >> needs to worry about. Nothing prevents you from implementing a Common >> Lisp that does reference counting. > > you must be a newbie. That's hilarious. I worked for the Lisp Machine project at MIT back in the 70's. Back then, Garbage Collection was a pretty hot topic. I did not work on the Lisp Machine's GC, but I was in the room while other people worked on it, and I was full of curiosity in those days, so I gained a pretty good understanding of the state of the art in garbage collection at that time. Henry Baker's paper about "real time" garbage collection was indeed one of the inspirations for the Lisp Machine's GC, although I do not think that Henry himself had any active role in that work. I'm not sure what I said in the paragraph you quoted above that made you think I was a "newbie". That paragraph was intended to contain the non-controversial part of what I wanted to say. Can you point to something in the language definitions for any of those languages that explicitly requires any particular form of garbage collector? For Common Lisp, Java or Python there may be things in some runtime libraries that let you query and control the GC, but the language specification itself is generally limited in what it says about storage management. The Common Lisp standard, for example, tells you that there is a condition called STORAGE-CONDITION, that might get signaled sometimes -- but the description of STORAGE-CONDITION is vague enough that I don't think you can draw any conclusions about what the underlying storage manager is doing. There is also the ROOM function, which promises to output something useful about storage -- but exactly what that includes is unspecified. Other than those two entries, I don't see much else. Actually, I can't find anyplace in the Common Lisp standard that even says outright that a Common Lisp implementation is expected to do automatic storage management, although that's clearly implied all over the place. In contrast the Java language specification says right up front in the 3rd paragraph of the introduction: [Java] includes automatic storage management, typically using a garbage collector, [...] And the Python language reference says (in the "Data Model" chapter): An implementation is allowed to postpone garbage collection or omit it altogether — it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable. So I don't see anything preventing a Common Lisp or Java implementation from doing reference counting, or a Python implementation from _not_ doing reference counting. (what's Jython doing after all?) -- Alan Bawden
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-12 13:06 +0000 |
| Message-ID | <110h094$26v7v$1@dont-email.me> |
| In reply to | #60857 |
Alan Bawden <alan@csail.mit.edu> wrote: > Other than those two entries, I don't see much else. I think the other thing would be the DYNAMIC-EXTENT declaration, although that's more about language semantics than anything to do with storage management. > > Actually, I can't find anyplace in the Common Lisp standard that even > says outright that a Common Lisp implementation is expected to do > automatic storage management, although that's clearly implied all over > the place. > I didn't use LispMs until much later than you, but isn't it the case that early machines often ran either with the GC disabled or without one at all because it wasn't working yet? That would be an implementation (not yet of CL of course) which had no storage reclamation. > So I don't see anything preventing a Common Lisp or Java implementation from > doing reference counting, or a Python implementation from _not_ doing > reference counting. (what's Jython doing after all?) > The D-machines used reference counting, and the Medley release had a pretty competent (pre-ANSI) CL environment. So that's a CL which used (uses, even) reference counting, -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-13 00:13 +0000 |
| Message-ID | <110i7bu$2iqm8$8@dont-email.me> |
| In reply to | #60860 |
On Fri, 12 Jun 2026 13:06:44 -0000 (UTC), tfb wrote: > ... isn't it the case that early machines often ran either with the > GC disabled or without one at all because it wasn't working yet? I recall hearing that the machines would typically run OK for a day or two before they ran out of memory. Instead of GC, you just rebooted. > The D-machines used reference counting, and the Medley release had a > pretty competent (pre-ANSI) CL environment. So that's a CL which > used (uses, even) reference counting, Did it do multithreading?
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 07:25 +0000 |
| Message-ID | <110j0lm$2otbu$1@dont-email.me> |
| In reply to | #60863 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > Did it do multithreading? > Interlisp-D did and you could call Interlisp from CL (and vice versa), so yes. I mean, you can just try it out: the Medley Interlisp project is extremely active. https://interlisp.org -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-13 08:25 +0000 |
| Message-ID | <110j45f$2pomq$1@dont-email.me> |
| In reply to | #60865 |
On Sat, 13 Jun 2026 07:25:42 -0000 (UTC), tfb wrote: > Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >> >> On Fri, 12 Jun 2026 13:06:44 -0000 (UTC), tfb wrote: >>> >>> The D-machines used reference counting, and the Medley release had a >>> pretty competent (pre-ANSI) CL environment. So that's a CL which >>> used (uses, even) reference counting, >> >> Did it do multithreading? >> > Interlisp-D did and you could call Interlisp from CL (and vice > versa), so yes. So they must have had some kind of global lock to ensure the reference counts stayed correct, like Python’s soon-to-be-extinct GIL? > I mean, you can just try it out: the Medley Interlisp project is > extremely active. https://interlisp.org I searched for “threading” and “multithread”, and found nothing.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 08:46 +0000 |
| Message-ID | <110j5do$2q7dn$1@dont-email.me> |
| In reply to | #60868 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > So they must have had some kind of global lock to ensure the reference > counts stayed correct, like Python’s soon-to-be-extinct GIL? I don't know. That stuff was all in microcode I think. And unlike Python it wasn't someone's 'my first big program' so chances are it was quite a lot cleverer. > > I searched for “threading” and “multithread”, and found nothing. > Lisps have traditionally called what Unixoid languages call 'threads' 'processes'. Chapter 23 of the manual. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-13 08:52 +0000 |
| Message-ID | <110j5nr$2qajs$1@dont-email.me> |
| In reply to | #60870 |
tfb <no_email@invalid.invalid> wrote: > Chapter 23 of the manual. 22, sorry. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 05:57 +0000 |
| Message-ID | <110lfsf$3dqkh$7@dont-email.me> |
| In reply to | #60871 |
On Sat, 13 Jun 2026 08:52:11 -0000 (UTC), tfb wrote: > tfb <no_email@invalid.invalid> wrote: >> >> Chapter 23 of the manual. > > 22, sorry. The table of contents uses one numbering, the pages themselves use another!
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2026-06-15 10:10 +0100 |
| Message-ID | <110ofib$7l4s$2@dont-email.me> |
| In reply to | #60889 |
On 2026-06-14, Lawrence D’Oliveiro wrote: > On Sat, 13 Jun 2026 08:52:11 -0000 (UTC), tfb wrote: > >> tfb <no_email@invalid.invalid> wrote: >>> >>> Chapter 23 of the manual. >> >> 22, sorry. > > The table of contents uses one numbering, the pages themselves use > another! What was between §Compiler and §DWIM? It kind of looks like a Chapter 19 went missing? -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 05:56 +0000 |
| Message-ID | <110lfr8$3dqkh$6@dont-email.me> |
| In reply to | #60870 |
On Sat, 13 Jun 2026 08:46:48 -0000 (UTC), tfb wrote:
> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>
>> So they must have had some kind of global lock to ensure the
>> reference counts stayed correct, like Python’s soon-to-be-extinct
>> GIL?
>
> I don't know. That stuff was all in microcode I think. And unlike
> Python it wasn't someone's 'my first big program' so chances are it
> was quite a lot cleverer.
I would say not. Remember, multiprocessor machines were not exactly
common back then. So a multithreaded architecture with a global lock
would have been considered perfectly adequate on the hardware of the
time, since only a single thread could be executing at any point
anyway.
>> I searched for “threading” and “multithread”, and found nothing.
>
> Lisps have traditionally called what Unixoid languages call
> 'threads' 'processes'. Chapter 23 of the manual.
OK, found chapter 23. And page 23-11, which talks about “Global
Resources”: this makes it clear that concurrent “processes” (i.e.
threads) cannot safely share access to global objects without explicit
locking:
Two processes cannot both use the same global resource if there
can be a process switch in the middle of their use (currently this
means calls to BLOCK, but ultimately with a preemptive scheduler
means anytime). Thus, user code should be wary of its own use of
global variables, if it ever makes sense for the code to be run in
more than one process at a time. "State" variables private to a
process should generally be bound in that process; structures that
are shared among processes (or resources used privately but
expensive to duplicate per process) should be protected with
monitor locks or some other form of synchronization.
So no, they had no magical solution to the problem. Note that point
about the “process switch in the middle of their use” -- such a
qualification would only have meaning in the context of a uniprocessor
architecture.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-16 11:46 +0000 |
| Message-ID | <110rd25$137br$2@dont-email.me> |
| In reply to | #60888 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > Resources”: this makes it clear that concurrent “processes” (i.e. > threads) cannot safely share access to global objects without explicit > locking: > That is nothing, nothing at all, to do with reference counting. It's to do with handling shared resources which is a famously hard problem which, surprise, Interlisp-D did not solve. -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-18 01:03 +0000 |
| Message-ID | <110vg5d$292a0$1@dont-email.me> |
| In reply to | #60922 |
On Tue, 16 Jun 2026 11:46:13 -0000 (UTC), tfb wrote: > Lawrence D´Oliveiro <ldo@nz.invalid> wrote: >> >> Resources”: this makes it clear that concurrent “processes” (i.e. >> threads) cannot safely share access to global objects without >> explicit locking: > > That is nothing, nothing at all, to do with reference counting. It's > to do with handling shared resources which is a famously hard > problem which, surprise, Interlisp-D did not solve. So what was that you said earlier: “so chances are it was quite a lot cleverer”?
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-18 07:52 +0000 |
| Message-ID | <1110844$2epdc$1@dont-email.me> |
| In reply to | #60955 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > > So what was that you said earlier: “so chances are it was quite a lot > cleverer”? > You said 'Sothey must have had some kind of global lock to ensure the reference counts stayed correct, like Python’s soon-to-be-extinct GIL?' I said 'I don't know. That stuff was all in microcode I think. And unlike Python it wasn't someone's 'my first big program' so chances are it was quite a lot cleverer.' Can you do topic analysis of text? Can you work out that the topic of those sentences was *a lock needed to deal with reference count consistency* and not something else? -- tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | steve g <Sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-16 20:56 -0400 |
| Message-ID | <871pe6rnl8.fsf@gmail.com> |
| In reply to | #60863 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > On Fri, 12 Jun 2026 13:06:44 -0000 (UTC), tfb wrote: > >> ... isn't it the case that early machines often ran either with the >> GC disabled or without one at all because it wasn't working yet? > > I recall hearing that the machines would typically run OK for a day or > two before they ran out of memory. Instead of GC, you just rebooted. Thank you! exit and reset baby :) >> The D-machines used reference counting, and the Medley release had a >> pretty competent (pre-ANSI) CL environment. So that's a CL which >> used (uses, even) reference counting, > > Did it do multithreading? take this with a grain of salt: the lisp machine I have was more about parallel operations. you fill two pipelines; if the first does not overflow the machine halts on the second pipeline terminating bignum arithmetic. IMHO
[toc] | [prev] | [next] | [standalone]
| From | Alan Bawden <alan@csail.mit.edu> |
|---|---|
| Date | 2026-06-13 00:55 -0400 |
| Message-ID | <86v7bnrqe2.fsf@williamsburg.bawden.org> |
| In reply to | #60860 |
tfb <no_email@invalid.invalid> writes: > Alan Bawden <alan@csail.mit.edu> wrote: >> Other than those two entries, I don't see much else. > > I think the other thing would be the DYNAMIC-EXTENT declaration, although > that's more about language semantics than anything to do with storage > management. Yeah, that does admit that a Common Lisp implementation probably has both a stack and a heap, and that heap allocation is the norm. But since implementations are allowed to completely ignore DYNAMIC-EXTENT, an implementation remains free to do something completely different! > I didn't use LispMs until much later than you, but isn't it the case that > early machines often ran either with the GC disabled or without one at all > because it wasn't working yet? That would be an implementation (not yet of > CL of course) which had no storage reclamation. There must have been a time when the CONS machine (only one of which was ever built), had no working GC. I don't recall if that was still the case when I joined the project. When I joined, a lot of stuff still wasn't fully working. It was still common in those days to develop code using a compatability layer that ran in MacLisp! But by the time we built the first CADR machine, the GC was working. >> So I don't see anything preventing a Common Lisp or Java implementation from >> doing reference counting, or a Python implementation from _not_ doing >> reference counting. (what's Jython doing after all?) > > The D-machines used reference counting, and the Medley release had a pretty > competent (pre-ANSI) CL environment. So that's a CL which used (uses, > even) reference counting, You mentioned in another thread that Interlisp-D didn't handle cycles as well a you would have liked. I was suprised to read that, because if so, I would expect that those of us at MIT would have never stopped making fun of Interlisp-D for that! Was there some argument for why that wasn't really a problem that we all accepted at the time? Or have I just forgotten knowing that once... -- Alan Bawden
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web