Path: csiph.com!weretis.net!feeder9.news.weretis.net!border-2.nntp.ord.giganews.com!nntp.giganews.com!Xl.tags.giganews.com!local-4.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 05 Sep 2026 02:15:13 +0000 From: steve g Newsgroups: comp.lang.lisp Subject: Re: Resources to learn common lisp? References: <110a9pp$ckmk$6@dont-email.me> <115n0v3$2h2oe$1@dont-email.me> <87zeyoo77t.fsf@nightsong.com> <116h0dv$2m9e2$1@dont-email.me> <116hd1l$2qooi$1@dont-email.me> <116hgb5$2s4uh$1@dont-email.me> <87tsojm54k.fsf@nightsong.com> <116jmt4$3jrlq$1@dont-email.me> <87fr01mplp.fsf@nightsong.com> <87tsogiuxx.fsf@safunu.org> <877blcmk4z.fsf@nightsong.com> <116pidp$3n6fk$1@paganini.bofh.team> <8733vzmixj.fsf@nightsong.com> <116tib9$8gg0$1@paganini.bofh.team> Date: Fri, 04 Sep 2026 22:15:12 -0400 Message-ID: <87jyp0zbnz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:i71/4TRZqjjuKR0MBzqVWUXtFD0= MIME-Version: 1.0 Content-Type: text/plain Lines: 79 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-MyWzRm+YOHz7hRwNJ0WT0lleeZm9VSsXzBAdB5KsZBIfdQMQYKjN7ibdj9gtTxIHWfvL9iQVawJE9Om!QJ8qhkyxhEHosDj2q/kWu08tSjko/z7YsH3dCxIwY4rioRk= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: csiph.com comp.lang.lisp:61627 antispam@fricas.org (Waldek Hebisch) writes: > Paul Rubin wrote: >> antispam@fricas.org (Waldek Hebisch) writes: >>> And normally functions do not return, simply tail-call to passed >>> "continuation". >> >> Continuations are nontrivial precisely because of the non-tail-call >> case, where the continuation is re-used. So you can use them to >> implement coroutines, multitasking, etc. If they can't do that, they're >> not "full" continuations. I don't see how to implement full >> continuations using CL macros. > Le me try again. Do you see how to implement continuations at say > assembler level? I remeber, actually not really. I remeber this intel used to have a leave and enter statement. This would allow for local space for local functions and such. I believe they were called frames or leaves? dunno. it was a long time ago. This was before threads. > If not, then I affraid that CL macros will not > help you. At assembly level each function has some machine code > and environment. In simple case environment reduces to stack frame, > it is created when function is invoked and destroyed when it exits. > Closures complicate this, function may access lexical variable of > containing functions and we must ensure that this access is possible > even after retrun from containing function. Continations add similar > problem, we can only discard a stack frame if it is not reachable > via continations or closures. One possible way to do this is to have > garbage collector capable of garbage collecting stack frame. you just subtract the stack pointer assuming you're not using frames. (It has been a long time). > But > there is another possiblity, namely to keep only return address on > the stack and keeping all other data in heap. In such case tail > call optimization will ensure bounded stack use, so no need to > garbage collect stack frames. I usually use alloca in C. that takes care of all this mess of assembler, CPU #/type , in terms of stack memory. > As I wrote, idea is to treat Lisp as a garbage collected assembly > language. With tail call optimization calls are translated to > goto-s, so collection of Lisp functions can implement arbitrary > control flow. If additinaly all local variables are collected > into a data structure allocated at function entry and if needed > passed as an extra argument, then your program at abstract level > will work as before, but data which previously was stored on the > stack is on the heap. After contination passing transformation > you may support continations. > How macros enter the picture: Lisp macro can perform arbitrary > transformation, in particular can "compile" code into low > level form indicated above. In a sense this is Turing completeness, > but we avoid general argument going via interpretation and > instead use compilation. And this clearly depends on ability > to do non-local transformations. Simple AST substitution > would be too weak. > AFAICS main trouble with continuations is efficiency. this is the common complaint. > If you do not need efficiency, then implementing continuations is just > some extra work, but otherwise not a problem. Trouble is that > relatively easy tactic of allocating stack frames on the heap puts > serious load on garbage collector and on caches. If program is doing > small number of function calls, then impact may be negligible. But > people wanting continuations are likely to have a lot of function > calls in their programs and speed is likely to suffer. So basically, > you need to do some serious optimization work which would be > unnecessery in language that does not implement continuations. I never could figure out call/cc .