Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Implementing lisp in Forth. Chapter 4. Date: Sun, 04 Sep 2016 21:03:34 -0700 Organization: A noiseless patient Spider Lines: 101 Message-ID: <87bn03ngbt.fsf@jester.gateway.pace.com> References: <87twdznhhz.fsf@jester.gateway.pace.com> <87fupfo6xl.fsf@jester.gateway.pace.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="7bfc8f5b1c0c0e2e29d3a5c3abe51644"; logging-data="30721"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+edE4LijtzRsXYF+TCbZPx" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:0IUBvOtXtAgQBOhn+gGwQqDikmU= sha1:ERyvDfRw4zQifNVEF7FK+qLMNjc= Xref: csiph.com comp.lang.forth:50675 albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >> http://www.complang.tuwien.ac.at/forth/garbage-collection.zip > The constraints that package imposes interferes with the non-existing > constraints I will impose on a yet non-existent lisp. I'd be interested to know what your objections are. The technique that package uses works very well and its C counterpart is used in many real-world systems. > I tell you what I'll do. I just ALLOCATE away in my 16 Gbyte space. > If I know I can FREE I'll do it. Then I'll add GC as an afterthought. Well, that's a start, though if you were doing a serious implementation then a lot of the implementation details would be enmeshed in the gc strategy so you'd want to think it all through from the beginning. > the fib procedure remains there in all eternity and there is nothing > to collect. I can do (fib 10) any time I please. Or will there be > anonymous memory places and are the boxes they are in such as > (a,b,i,n) collectable? It depends on your scheme's implementation details, the number representation, etc. But if they are fixnums and you have a compiler that looks for such chances, that function can avoid consing. A simple implementation would just cons everything. CPython works like that (it caches 100 or so small integers and conses/gc's the rest) and tons of people use it. It's not as bad as it sounds. > 354224848179261915075 does that leave garbage in your run of the mill > scheme? Yes, bignums are usually heap-allocated so if you create them as intermediate results, they will leave garbage. > In the procedure fib can I optimise the fib into machine code with > (optimise fib) > that optimises the underlying Forth code, without getting on > someones toes? In principle that could be ok. You could look at Chicken Scheme, which compiles Scheme to C if I remember properly. > Obviously that may leave some garbage that may be harder to collect. I don't think you should worry about optimizing this, especially for your first implementation. Just spew garbage wherever it's convenient and let the GC take care of it. > No it isn't, not in the Forth philosophy. The reader is the glue and > Lisp doesn't exist, it is just turtles all the way down. But I thought the idea of implementing Lisp was so you could program with the Lisp philosophy, which is much different from the Forth philosophy. Forth is like building a brick outhouse, carefully cementing each brick in place before moving to the next, getting something compact and solid. Lisp is more like dancing in the air. You can create a palace of data with a wave of your hand, use it for something, then fly away from it, leaving the GC to reclaim the building materials for you to use in your next adventure. > (It may well be that Lisp doesn't exist in the Lisp philosophy, > just cdr's all the way down to the atom's. Dunno yet.) Lisp very much exists in the traditional Lisp philosophy (you can build up programs and eval them), even though this isn't supported in Scheme. > It is not the gain, it is the loss. I loose an interpreter for Backus > Naur forms. Less is more. There's no BNF in a usual Lisp reader, but rather just a simple recursive procedure that recognizes a few special characters and otherwise acts like a Forth parser. But you then have a tree to manipulate, maybe for macro expansion or other purposes. It's easier to handle that in Lisp than in Forth. > I just read the description of Guile. That is a Scheme dialect and > Scheme is supposed to be simple. I can't detect the simplicity in it > (not from the info file). It kind of deters me. I see that guile > binary is 3K, that seems okay, but it calls horrific c-libraries like > the infamous readline, maybe even malloc. Guile is quite large and complex these days, maybe to compete with higher end Javascript implementations like v8. That 3k binary is certainly a dynamic loader client that pulls in other libraries. It looks like libguile-2.0.so.22 on my system is about 1.6MB and it also pulls in a lot of other code. You might look at this old (2.0) version of SIOD if you want to see a minimal Scheme: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/impl/siod/siod_20.tgz This version is nice because it has two different gc's (mark-sweep and copying) where you choose which one you want with a command line option. Each gc is just a few dozen LOC. Earlier versions only had the copying GC. Later versions became bigger and more complicated, maybe more useful for practical purposes, but less easy to study. SIOD stands for Scheme In One Day because the original version was supposedly written in under 24 hours. It's around 1 KLOC of C.