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 91 — 16 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? 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? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:27 -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? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:56 +0000
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? 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-12 12:42 +0000
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? 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? 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? 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? 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? 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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-10 00:14 +0000 |
| Message-ID | <110aa8j$ckmk$7@dont-email.me> |
| In reply to | #60837 |
On Tue, 09 Jun 2026 12:07:43 +0200, Axel Reichert wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: > >> What’s a homoiconic language with postfix operation syntax? > > https://factorcode.org/ > https://concatenative.org/wiki/view/Factor/Features/The%20language I see it needs to have an explicit “macro" construct to implement homoiconicity. This was unnecessary in PostScript. Here <https://gitlab.com/ldo/gxscript> is my attempt at a PostScript revival.
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-11 17:22 +0000 |
| Message-ID | <110eqtf$1k9f5$1@dont-email.me> |
| In reply to | #60836 |
Lawrence D´Oliveiro <ldo@nz.invalid> wrote: > How about this for a definition: “homoiconicity with minimal syntax”. I think this is close. This would define what my friend Zyni would call a 'lispoid'. She is mostly a mathematician, and this is by analogy with terms like 'groupoid', which is something on the way to being a group. For almost all purposes a lispoid is enough: it is not a term meant to denigrate lispoids! In particular lispoids are enough to support seamless macros. I think Clojure is probably a lispoid by this definition. A lisp is then a lispoid where the underlying representation of source code is singly-linked lists. -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-13 13:59 -0700 |
| Message-ID | <87cxxu88cf.fsf@nightsong.com> |
| In reply to | #60836 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > How about this for a definition: “homoiconicity with minimal syntax”. Nah, it's more of a state of mind. At the center of it is lambda calculus, but even that only sometimes. Picolisp uses FEXPRs instead of macros and I remember hearing that those break lambda calculus in some way that I don't understand.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 00:55 +0000 |
| Message-ID | <110ku5g$3a32m$3@dont-email.me> |
| In reply to | #60877 |
On Sat, 13 Jun 2026 13:59:44 -0700, Paul Rubin wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: >> >> How about this for a definition: “homoiconicity with minimal >> syntax”. > > Nah, it's more of a state of mind. At the center of it is lambda > calculus, but even that only sometimes. λ-calculus is at the centre of *everything* in CompSci, like it or not. (Did you know that λ-calculus offers a way to reason about logical paradoxes, by representing them as endless loops? Mathematicians seem to be scared of paradoxes for some reason, but as you know in CompSci we deal with them all the time, it doesn’t drive us mad or anything.) > Picolisp uses FEXPRs instead of macros and I remember hearing that > those break lambda calculus in some way that I don't understand. I had a quick look at picolisp.com. I have this suspicion the language has no lexical binding -- maybe that’s the issue you’re thinking of? If so, I would consider that a bug, not a feature.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2026-06-14 01:43 -0700 |
| Message-ID | <87o6hd7br8.fsf@nightsong.com> |
| In reply to | #60880 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > λ-calculus is at the centre of *everything* in CompSci, like it or not. I'd say the correspondence between traditional imperative programs and lambda calculus is at best way more obscure than it is in Lisp. I'm not versed enough in PL theory to know if it appears at all. > (Did you know that λ-calculus offers a way to reason about logical > paradoxes, by representing them as endless loops? Not sure what you mean by that? >> Picolisp uses FEXPRs > I had a quick look at picolisp.com. I have this suspicion the language > has no lexical binding -- maybe that’s the issue you’re thinking of? No it's a completely separate issue. https://en.wikipedia.org/wiki/Fexpr describes some issues with FEXPRs. I guess the problem wasn't as serious as an inconsistency in the resulting lambda calculus, but more a matter of making FEXPR-using code difficult to compile. I've never used Picolisp but I've studied its documentation a little. It has some cute ideas but overall it didn't excite me very much.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-14 05:45 +0000 |
| Message-ID | <110lf56$3dqkh$5@dont-email.me> |
| In reply to | #60877 |
On Sat, 13 Jun 2026 13:59:44 -0700, Paul Rubin wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: >> >> How about this for a definition: “homoiconicity with minimal >> syntax”. > > Nah, it's more of a state of mind. At the center of it is lambda > calculus, but even that only sometimes. λ-calculus is at the centre of *everything* in CompSci, like it or not. (Did you know that λ-calculus offers a way to reason about logical paradoxes, by representing them as endless loops? Mathematicians seem to be scared of paradoxes for some reason, but as you know in CompSci we deal with their endless-loop equivalents all the time, it doesn’t drive us mad or anything.) > Picolisp uses FEXPRs instead of macros and I remember hearing that > those break lambda calculus in some way that I don't understand. I had a quick look at picolisp.com. I have this suspicion the language has no lexical binding -- maybe that’s the issue you’re thinking of? If so, I would consider that a bug, not a feature.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-09 00:35 +0000 |
| Message-ID | <1107n4i$3k6ea$6@dont-email.me> |
| In reply to | #60820 |
On Mon, 08 Jun 2026 12:41:56 -0400, steve g wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: > >> Lisp is a pretty interesting language, but it was never >> standardized to the extent that we expect of languages today. Look >> at the Common Lisp spec, and it still retains a lot of baggage to >> maintain compatibility with obsolete OSes that simply don’t matter >> any more. > >> And also, which particular Lisp do you want to learn? There are a >> number in common use today: > > this is false. common lisp is a programming language. In today’s terms, Common Lisp is only a partial language spec. It has all that historical baggage, and yet it leaves out crucial things that other languages, like Python, implement more uniformly today.
[toc] | [prev] | [next] | [standalone]
| From | steve g <sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-08 12:37 -0400 |
| Message-ID | <87pl21m1i6.fsf@gmail.com> |
| In reply to | #60748 |
Mario Rosell <mario@mariorosell.es> writes: < > Finally, what do you want learn it for? It might just be for fun or < > it might be because you have a very specific goal in mind for which < > someone might have some specific recommendations. actually lisp is best for researchers trying to test new alogrithims. Fun as much as programming is fun... > Just for fun. It seems like a pretty interesting language. hook, line, and sinker!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-09 00:33 +0000 |
| Message-ID | <1107n17$3k6ea$5@dont-email.me> |
| In reply to | #60819 |
On Mon, 08 Jun 2026 12:37:53 -0400, steve g wrote: > actually lisp is best for researchers trying to test new [algorithms]. Lisp is purely garbage-collected though, isn’t it? 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. I think you can use all three in Jupyter notebooks, anyway. That’s an environment I recommend for just about any kind of “scratchpad” or quick “experimentation” programming.
[toc] | [prev] | [next] | [standalone]
| From | steve g <sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-09 00:22 -0400 |
| Message-ID | <87tsrcxrz8.fsf@gmail.com> |
| In reply to | #60825 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > On Mon, 08 Jun 2026 12:37:53 -0400, steve g wrote: > < > actually lisp is best for researchers trying to test new [algorithms]. > Lisp is purely garbage-collected though, isn’t it? 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. i will not deny my love of this languagw. yes liSP uses GC. A hybride approad? like unboxed numbers?
[toc] | [prev] | [next] | [standalone]
| From | Alan Bawden <alan@csail.mit.edu> |
|---|---|
| Date | 2026-06-09 01:22 -0400 |
| Message-ID | <865x3sthhu.fsf@williamsburg.bawden.org> |
| In reply to | #60825 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > Lisp is purely garbage-collected though, isn’t it? 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. 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. 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. -- Alan Bawden
[toc] | [prev] | [next] | [standalone]
| From | tfb <no_email@invalid.invalid> |
|---|---|
| Date | 2026-06-09 06:17 +0000 |
| Message-ID | <1108b4u$3p13j$1@dont-email.me> |
| In reply to | #60830 |
Alan Bawden <alan@csail.mit.edu> wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: > > 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. > Those of us who had to write code to laboriously decircularize about-to-be-dead structures on d machines definitely did! But your point is right: these are implementation, not language, questions. (I also hate the stupid 'reference counting is better' thing. It is 2000 already, machines live or die on their caches. I drop a large structure on the floor. A reference-counted implementation now dutifully walks over the entire structure reducing all the counts to zero *and ensuring the machine's caches are full of data that will never be used again*. An implementation with a copying GC ... never touches that memory again. One of these approaches is a lot less hostile to caches than the other.) -- www.tfeb.org/computer/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-09 06:50 +0000 |
| Message-ID | <1108d3q$3p7sr$2@dont-email.me> |
| In reply to | #60830 |
On Tue, 09 Jun 2026 01:22:53 -0400, Alan Bawden wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: > >> Lisp is purely garbage-collected though, isn’t it? 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. > > 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. It does have some subtle, but far-reaching, implications for language usage, though. For example, pure GC makes it easy to support multithreading. But the downside is that it is easy for a single long-running program to consume all available memory, even if its memory needs at any particular moment are not that great. So you need to put arbitrary constraints on its heap size. And if turns it that wasn’t enough for a particular run, then you need to stop and re-run with a larger heap allocation. Which defeats some of the point of dynamic memory allocation when you have to micromanage such things, doesn’t it? This is why both Perl and Python stuck with the hybrid approach. In Perl’s case, they kind of fudged their approach to multithreading as a consequence, with implications for sharing objects across threads. While the Python folks have put a lot of effort into coming up with a more comprehensive solution, making reference counts just a little bit nondeterministic in return for greater performance while still allowing object sharing to work the way you would expect.
[toc] | [prev] | [next] | [standalone]
| From | steve g <sgonedes1977@gmail.com> |
|---|---|
| Date | 2026-06-10 12:40 -0400 |
| Message-ID | <875x3q2vsf.fsf@gmail.com> |
| In reply to | #60835 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes: > On Tue, 09 Jun 2026 01:22:53 -0400, Alan Bawden wrote: > < > Lawrence D’Oliveiro <ldo@nz.invalid> writes: < > < >> Lisp is purely garbage-collected though, isn’t it? 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. < > < > 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. > > It does have some subtle, but far-reaching, implications for language > usage, though. > > For example, pure GC makes it easy to support multithreading. !!? Ummm ??! But the > downside is that it is easy for a single long-running program to > consume all available memory, even if its memory needs at any > particular moment are not that great. So you need to put arbitrary > constraints on its heap size. > And if turns it that wasn’t enough for a > particular run, then you need to stop and re-run with a larger heap > allocation. Which defeats some of the point of dynamic memory > allocation when you have to micromanage such things, doesn’t it? > This is why both Perl and Python stuck with the hybrid approach. In > Perl’s case, they kind of fudged their approach to multithreading as a > consequence, with implications for sharing objects across threads. 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... > While the Python folks have put a lot of effort [...] there is no perfect solution; python can be compiled with LTO, I don't have the numbers on me... from what I understand this is a new method.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-11 00:26 +0000 |
| Message-ID | <110cvc6$13kte$8@dont-email.me> |
| In reply to | #60844 |
On Wed, 10 Jun 2026 12:40:48 -0400, steve g wrote: > with all due respect, garbage collection is very difficult. Why are there so many languages using it, then? It’s difficult to implement efficiently -- that I would agree with. Because that’s my point. > Most programmers will use the best algorithm available; like guile > does. If there was a “best algorithm available”, then why would there need to be a diversity of implementations? > 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... And Perl is precisely one of the examples I mentioned, is it not, that tries to keep reference-counting as a first resort before falling back to garbage collection? Wasn’t there a claim made by somebody in another posting that reference-counting adds performance-sapping overhead compared to a pure garbage collection approach? Yet here you are unwittingly disproving that.
[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-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]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.lisp
csiph-web