Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #50554 > unrolled thread

Implementing lisp in Forth. Chapter 4.

Back to article view | Back to comp.lang.forth

Contents

  Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-29 18:41 +0200
    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-08-29 09:39 -0700
      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-30 10:49 +0200
    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-08-29 09:46 -0700
      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-30 11:07 +0200
        Re: Implementing lisp in Forth. Chapter 4. Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-08-30 08:00 -0400
          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-02 12:34 +0200
        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-08-31 14:23 -0700
          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-01 02:15 +0200
            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-01 19:49 -0700
              Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-02 11:49 +0200
                Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-04 11:28 -0700
                  Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-05 03:31 +0200
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-04 21:03 -0700
                    Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-05 07:47 +0000
                      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-05 12:05 +0200
                        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-05 12:04 -0700
                          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 11:48 +0200
                            Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-06 15:32 +0000
                              Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 21:27 +0200
                                Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-06 19:50 +0000
                                  Re: Implementing lisp in Forth. Chapter 4. Stefan Monnier <monnier@iro.umontreal.ca> - 2016-09-08 12:15 -0400
                                    Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-08 20:09 +0200
                                      Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-08 12:34 -0700
                                      Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 10:17 +0000
                                        Re: Implementing lisp in Forth. Chapter 4. Stefan Monnier <monnier@iro.umontreal.ca> - 2016-09-12 11:50 -0400
                                          Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 16:48 +0000
                                            Re: Implementing lisp in Forth. Chapter 4. Stefan Monnier <monnier@iro.umontreal.ca> - 2016-09-12 13:41 -0400
                                Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-06 22:03 -0700
                                Re: Implementing lisp in Forth. Chapter 4. George Neuner <gneuner2@comcast.net> - 2016-09-08 16:50 -0400
                                  Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-08 16:34 -0700
                                    Re: Implementing lisp in Forth. Chapter 4. George Neuner <gneuner2@comcast.net> - 2016-09-09 00:12 -0400
                                      Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-08 22:22 -0700
                                Re: Implementing lisp in Forth. Chapter 4. Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-27 08:51 +0200
                                  Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-27 00:47 -0700
                        Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-06 13:18 +0000
                          Re: Implementing lisp in Forth. Chapter 4. "WJ" <w_a_x_man@yahoo.com> - 2016-09-06 20:52 +0000
                          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-02 19:15 +0100
                        Re: Implementing lisp in Forth. Chapter 4. Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-09 10:05 +0200
                          Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 10:11 +0000
                            Re: Implementing lisp in Forth. Chapter 4. Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-12 13:15 +0200
                              Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 17:25 +0000
                  Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-09 16:19 +0200
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-09 10:55 -0700
                      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-09 21:39 +0200
                        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-09 13:06 -0700
                          Re: Implementing lisp in Forth. Chapter 4. franck.bensusan@gmail.com - 2016-09-10 07:23 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-11 01:28 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-13 21:37 +0000
                              Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-14 09:55 +0200
                              Re: Implementing lisp in Forth. Chapter 4. franck.bensusan@gmail.com - 2016-09-14 01:04 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-13 14:40 -0700
                              Re: Implementing lisp in Forth. Chapter 4. franck.bensusan@gmail.com - 2016-09-14 03:37 -0700
                  Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-10 01:17 -0700
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 12:01 -0700
                      Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-10 21:57 -0700
                        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 22:12 -0700
                          Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-10 23:30 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 23:48 -0700
                              Re: Implementing lisp in Forth. Chapter 4. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-11 02:59 -0500
                                Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-11 01:16 -0700
                                  Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-11 19:02 -0700
                              Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-11 19:00 -0700
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 12:08 -0700
                    Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 09:43 +0000
                      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 13:42 +0200
                        Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 17:26 +0000
                          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 20:56 +0200
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-12 13:08 -0700
                            Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-14 07:38 +0000
      Re: Implementing lisp in Forth. Chapter 4. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-30 07:48 +0100
        Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-30 11:22 +0200
        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-30 18:36 -0700
          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-01 11:19 +0200
            Re: Implementing lisp in Forth. Chapter 4. luser droog <mijoryx@yahoo.com> - 2016-10-01 19:34 -0700
    Implementing lisp in Forth. Garbage collection. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 12:30 +0200
      Re: Implementing lisp in Forth. Garbage collection. Spiros Bousbouras <spibou@gmail.com> - 2016-09-06 15:34 +0000
        Re: Implementing lisp in Forth. Garbage collection. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 21:12 +0200
      Re: Implementing lisp in Forth. Garbage collection. Paul Rubin <no.email@nospam.invalid> - 2016-09-06 14:52 -0700
        Re: Implementing lisp in Forth. Garbage collection. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-07 01:50 +0200
          Re: Implementing lisp in Forth. Garbage collection. Paul Rubin <no.email@nospam.invalid> - 2016-09-06 17:49 -0700
    Re: Implementing lisp in Forth. Chapter 4. luser droog <mijoryx@yahoo.com> - 2016-10-21 17:02 -0700
      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-22 02:43 +0200

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#50715

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>  the whole memory in use by the application is considered as potential pointers

That's wrong.  If it was, cyclic structures would not be collected,
and a lot of other stuff would also not be collected (e.g., even if
there was no spurious pointer to a dead linked list, it would only
collect one element (the current first one) per collection).

For an automatic collector (conservative or no), the root set is the
static memory (data and bss segments in Unix), stacks, and registers.
My garbage collector is not as automatic and requires you to register
the roots, because there is no standard way in Forth to scan
everything where there might be roots.

>  conservative: garbage may not be freed, but if it is freed it is
>     certainly garbage

Actually, no garbage collector guarantees that any memory it keeps is
accessed later.  Conservative garbage collectors may keep stuff around
because something that is not a real pointer seems to point to it,
whereas precise collectors do not have this problem.  Because precise
collectors know what is a pointer and what is not, they can also copy
the live data around.

>What about pointers in the middle of an area?
>Do they prevent the area from being freed?

That's up to the collector.  My collector doesn't.  In general, for
conservative collectors, that would significantly increase the number
of spurious pointers.  It also depends on the application.  In a basic
Lisp system, all pointers are to the start of objects, so there is no
point in handling pointers to the middle of an object.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#50749

>> the whole memory in use by the application is considered as potential
>> pointers
> That's wrong.  If it was, cyclic structures would not be collected,

That depends on how you interpret "use".


        Stefan

[toc] | [prev] | [next] | [standalone]

#50752

In article <jwvmvji74hy.fsf-monnier+comp.lang.lisp@gnu.org>,
Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>>> the whole memory in use by the application is considered as potential
>>> pointers
>> That's wrong.  If it was, cyclic structures would not be collected,
>
>That depends on how you interpret "use".

In the context of conservative garbage collectors, I expect that sometimes
cyclic structures are not collected.

>
>
>        Stefan

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50757

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> In the context of conservative garbage collectors, I expect that sometimes
> cyclic structures are not collected.

There shouldn't be anything different about them from non-cyclic
structures as regards the gc finding them.  Anton's point was that a
conservative gc doesn't scan all of memory; but rather, it recursively
traces outward from a predefined root set, like any other gc.  If
there's a cyclic structure out there that's unreachable from the roots,
it will get collected.

[toc] | [prev] | [next] | [standalone]

#50883

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <jwvmvji74hy.fsf-monnier+comp.lang.lisp@gnu.org>,
>Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>>>> the whole memory in use by the application is considered as potential
>>>> pointers
>>> That's wrong.  If it was, cyclic structures would not be collected,
>>
>>That depends on how you interpret "use".

All memory that the collector has given out to the application and
that has not been reclaimed.

>In the context of conservative garbage collectors, I expect that sometimes
>cyclic structures are not collected.

If you use the "in use" memory as specified above as the root set,
then cyclic structures will never be collected.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#50898

>>>>> the whole memory in use by the application is considered as potential
>>>>> pointers
>>>> That's wrong.  If it was, cyclic structures would not be collected,
>>> That depends on how you interpret "use".
> All memory that the collector has given out to the application and
> that has not been reclaimed.

I read it as: the memory that was found to be reachable.


        Stefan

[toc] | [prev] | [next] | [standalone]

#50899

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>>> the whole memory in use by the application is considered as potential
>>>>>> pointers
>>>>> That's wrong.  If it was, cyclic structures would not be collected,
>>>> That depends on how you interpret "use".
>> All memory that the collector has given out to the application and
>> that has not been reclaimed.
>
>I read it as: the memory that was found to be reachable.

But you need the pointers to find reachable memory, so your reading is
not sufficient for determining live memory; the other reading also has
it's problems, as pointed out above, and more importantly, it's not
what conservative collectors do, so I just would not use this wording
at all.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#50904

>>>>>>> the whole memory in use by the application is considered as potential
>>>>>>> pointers
>>>>> That's wrong.  If it was, cyclic structures would not be collected,
>>>>> That depends on how you interpret "use".
>>> All memory that the collector has given out to the application and
>>> that has not been reclaimed.
>> I read it as: the memory that was found to be reachable.
> But you need the pointers to find reachable memory,

Right, and the conservative GC considers anything that looks like
a pointer to be pointer w.r.t deciding if something is reachable or not.
So you *do* have "the pointers".

> it's not what conservative collectors do, so I just would not use this
> wording at all.

I wouldn't either, but in the context I find it understandable. 


        Stefan

[toc] | [prev] | [next] | [standalone]

#50722

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> Neither of these points came through from wikipedia.

You should probably look at the gc.html documentation file from Anton's
package, if you haven't already:

  http://www.complang.tuwien.ac.at/forth/garbage-collection.zip

unfortunately it's not on its own web page afaik, so you have to extract
it from the zip file.  It explains stuff like that pretty well.

[toc] | [prev] | [next] | [standalone]

#50760

If you are really interested in how GC operates, you should read the
bible:
	
Garbage Collection: Algorithms for Automatic Dynamic Memory
Management; Richard Jones and Rafael D Lins; 1996.
ISBN-13: 978-0471941484
ISBN-10: 0471941484 

Don't be too concerned about the age - this book is mainly theory and
little has changed since it was written.


For a survey of modern implementation techniques, see:

The Garbage Collection Handbook: The Art of Automatic Memory
Management; Richard Jones, Antony Hosking and Eliot Moss; 2011.
ISBN-13: 978-1420082791
ISBN-10: 1420082795 

This book is light on theory ... it is not a good intro text, but IMO
it is invaluable to an implementor.


Hope this helps,
George

[toc] | [prev] | [next] | [standalone]

#50763

George Neuner <gneuner2@comcast.net> writes:
> The Garbage Collection Handbook: The Art of Automatic Memory
> Management; Richard Jones, Antony Hosking and Eliot Moss; 2011.

Is that something other than an update on the 1996 book?

I do know there have been some real advances since then, especially for
parallel gc, though that wouldn't be relevant to a basic Lisp
interpreter.

[toc] | [prev] | [next] | [standalone]

#50766

On Thu, 08 Sep 2016 16:34:10 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>George Neuner <gneuner2@comcast.net> writes:
>> The Garbage Collection Handbook: The Art of Automatic Memory
>> Management; Richard Jones, Antony Hosking and Eliot Moss; 2011.
>
>Is that something other than an update on the 1996 book?
>
>I do know there have been some real advances since then, especially for
>parallel gc, though that wouldn't be relevant to a basic Lisp
>interpreter.

The 2nd book is *not* an update of the 1st.  

The 1996 book was mainly about theory [which really has _not_ changed
all that much].  The 2011 book is light on the theory and is mainly
about implementation techniques for modern processors, and it covers
HRT implementation (the older book covered only SRT).

The books complement each other.  A practitioner might get by with
only the 2011 book, but someone looking for in-depth understanding
needs the 1996 as well.

George

[toc] | [prev] | [next] | [standalone]

#50768

George Neuner <gneuner2@comcast.net> writes:
> The books complement each other.  A practitioner might get by with
> only the 2011 book, but someone looking for in-depth understanding
> needs the 1996 as well.

Thanks.  I've only seen the 2011 one, which I liked.  I'll look for the
1996 one as well.  I didn't realize there was much theory behind the
subject to begin with.

[toc] | [prev] | [next] | [standalone]

#51362

"A Forth Implemenation of LISP"

http://soton.mpeforth.com/flag/jfar/vol5/no1/article22.pdf

[toc] | [prev] | [next] | [standalone]

#51365

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> "A Forth Implemenation of LISP"
> http://soton.mpeforth.com/flag/jfar/vol5/no1/article22.pdf

Interesting but unfortunately gives almost no implementation details.

[toc] | [prev] | [next] | [standalone]

#50706

On Mon, 5 Sep 2016 12:05:26 +0200 (CEST)
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
> I've cross posted to comp.lang.lisp
> The context is writing a minimal lisp, but with Forth instead of
> c as the implementation language.
> 
> In article <_p9zz.1142663$OC.48142@fx39.am4>,
> Spiros Bousbouras  <spibou@gmail.com> wrote:
> <SNIP>
> >
> >I don't think that garbage collection is something to be added as an
> >afterthought. The existence of garbage collection affects the allocation (and
> >possible recollection) of every object (see examples below) so it's one of
> >the issues you need to be thinking about from the start. It's likely more
> >fundamental than the syntax of the language. Having said that , it's not that
> >big a hurdle. I don't know why you don't like Anton Ertl's package but there
> >is also the Boehm-Demers-Weiser garbage collector which is used in Embeddable
> >Common Lisp , Guile Scheme and was used in an early implementation of Racket
> >Scheme. Even writing your own precise garbage collector is not terribly
> >difficult , see
> >    http://www.cs.cornell.edu/courses/cs312/2003fa/lectures/sec24.htm
> >for a simple algorithm.
> >
> >> About garbage: Is this correct (the infamous Fibonacci series)?
> >>
> >> After:
> >> (define (fib n)
> >>   (do ((i 1 (+ 1 i))
> >>          (a 1 (+ a b))
> >>          (b 1 a ))
> >>          ((>=  i n ) b)))
> >> 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?
> >
> >As long as you don't redefine it then yes it remains there for all eternity.
> 
> Maybe there is a confusion between dynamic allocation / knowing
> exactly where each piece of memory hangs out, and garbage
> collection.
> Such a fib consist (in my view) of a Forth word header of 5 CELLS which
> is dynamically allocated *using my Forth ALLOCATE* and pointed to by some
> pointer sitting in some tree or list or hash as a global heap.

Are those 5 CELLS going to be reused every time the function gets called ?
For this function it doesn't matter if they are but in Lisp you can create
closures which return storage local to the function (i.e. lexical variables)
up the call stack. For example (I'll use Common Lisp syntax because I'm
more familiar with it than Scheme)

(defun adder (n)
    (lambda (i) (+ n i)))

If you're going to translate  adder  in Forth it won't do to have 1 CELL for
n  which gets reused every time  adder  gets called ; you need to create fresh
storage space for  adder  every time it gets called unless you can prove that
its return value (which is an anonymous function) gets discarded.

> Then the code is high level Forth code, and again it is allocated
> dynamically and a pointer to it is present in the header.
> (High level Forth code is, of course a list of code tokens.)
> Contrary to malloc, my ALLOCATE knows a lot about
> the size etc of pieces allocated.

malloc()  also knows about the size of pieces allocated otherwise it wouldn't
work. The interface does not make such information available to the programmer
but the internals of  malloc() (and related functions) certainly need to know.

> Of course I make sure that analysing the heap is possible to find
> out what is no longer needed. But I call actually doing that
> the garbage collection.

It's part of garbage collection but you also need to reclaim the space.

> There is no doubt in my mind that
> I can implement a garbage collector even if it is
> very inefficient. What one needs is all knowledge about pointers to
> dynamically allocated area and into dynamically allocated area and
> know which is which, and a means to know the sizes.
> That may not be properly called an afterthought.
> If I wouldn't keep that information from the start, an attempt to
> write a Lisp would be ludricous indeed. If I want to investigate how
> a Forth can morph into a lisp, I can't have an external tool
> dictate me how to do the allocation. Using my own ALLOCATE I can change
> it, if I want properties specifically needed for LISP

Well , if you're going to change ALLOCATE so that it stores the necessary
information to do garbage collection then I would most certainly would not call
it an "afterthought" ; on the contrary you design with garbage collection in
mind starting from the most basic components.

> >But if you call it then the arguments  fib  and  n  as well as the local
> >(lexical in Lisp parlance) variables  i , a , b  will have to be allocated
> >somewhere. So whether they create garbage , which will need to be reclaimed
> >eventually , depends on the allocation strategy of the implementation. A
> >perfectly reasonable strategy is that the implementation gets a big chunk of
> >memory from the operating system and every time it needs a new object it uses
> >the smallest address from that space which it hasn't used yet. If the space
> >fills up then the implementation may ask for more memory from the operating
> >system or do garbage collection ; obviously , eventually it will have to do
> >garbage collection rather than keep asking for more and more memory. With
> >such an allocation scheme , every time you call  fib  and it returns then it
> >will create garbage for  fib , n , etc. Now a sufficiently clever Lisp
> >implementation may be able to prove that none of the variables of  fib  can
> >be referenced after  fib  terminates and therefore allocate them on the
> >hardware stack as it would (likely) happen in a language like C.
> >en.wikipedia.org/wiki/Escape_analysis  has some related content. But if it's
> >not that clever then every call to  fib  creates garbage and if that garbage
> >isn't cleared every now and again , it will consume eventually all available
> >memory.
> 
> My Forth allocation strategy is simpler. At the start a large chunk
> is asked from Linux (which overcommits memory). Then my ALLOCATE
> gives out memory on a first free basis. Maybe I get stuck and have to
> do garbage collection, which amounts to calling FREE from the allocator.

What you're describing here is the same thing I describe in the quoted paragraph
above so I wouldn't call it simpler. I mentioned "escape analysis" as an
optimisation but it's not necessary.

> If the large stuck wasn't enough, that is the end.
> With a toy Lisp and a 16 gByte heap, I can do a lot of testing before
> the GC needs to kick in.

[...]

> >I don't know why you think readline is infamous but it's for providing a more
> >pleasant interface and not necessary. On the other hand , Guile certainly
> >uses the GNU multiprecision library and being able to handle arbitrarily
> >large integers *is* part of the core functionality. Since it uses the
> >Boehm-Demers-Weiser garbage collector , I'm guessing it doesn't call  malloc()
> >(or  realloc()) but the analogous functions Boehm-Demers-Weiser provides.
> 
> (In the context of toy lisps that can be implemented in 1000 lines,
> I hate readline which is itself couple of hundred lines,
> is not written in lisp and is not strictly needed.
> I'm glad to see that it is a loadable extension to Guile.)
> 
> BDW is a c-package? I'm disappointed, because people told me that
> Lisp can be implemented using 5 basic operations.

BDW (Boehm-Demers-Weiser) is not necessary. I only brought it up because in an
earlier post you said "The GC seems to be a difficult part. How can there be
one if there is no lisp yet to speak of? A c-library?" .Now you seem confident
that you can write your own garbage collector. In which case you can forget
about BDW.

> That means
> something different than saying that yourforth is implemented
> with 38 basic words (in assembler) apparently.
> In analysing what is minimally needed in Forth always
> KEY and EMIT come up. That is realistic. If you can't tell the
> computer what to do, and can't see what it has done, your
> language is incomplete. Lispers seem to think that REPL is
> a tucked on part.

Not in the slightest ; I can't imagine what gave you that idea. Incremental
development where you test things as you write them is valued in the Lisp
world as much as it is in the Forth world. Note that Common Lisp has the
function READ which reads from a stream and returns Lisp objects. It also has
extensive specifications about how the various standard Common Lisp objects
should be printed as well as the ability to define your own methods to print
user defined objects in any way you like.

> If you would program a LISP machine like I have a Forth machine
> (just a tower that has Forth in the boot sector), would it then contain
> a couple of giant binary blobs being the GNU multiprecision lib,
> the compiled readline lib and maybe even a compiled BDW library written
> in C?
> Eech!

GNU multiprecision lib , etc. are shared libraries so in order to work they
need an operating system or at least parts of it like a dynamic linker. The
readline library is just an interface and not one well suited for Lisp so it's
not relevant to writing an operating system in Lisp. An operating system in
Lisp probably doesn't need support for arbitrarily large integers either ; I'm
not sure that such support would be considered essential for a Lisp under any
circumstances but for desktop applications it's certainly convenient to have.
For garbage collection , a Lisp from scratch would be best served by a precise
garbage collector so not BDW. Actually , an operating system with garbage
collection from the bottom up would be a fascinating thing to have regardless
of the implementation language.

> >  Jorgen Grahn
> >  James K. Lowden
> 
> Two names in a signature, but you're Spiros?

My multiple personality disorder has been acting up  :-D

-- 
it's just that in C++ and the like, you don't trust _anybody_, and in CLOS you
basically trust everybody.  the practical result is that thieves and bums use C++
and nice people use CLOS.  :)
  Erik Naggum

[toc] | [prev] | [next] | [standalone]

#50716

Spiros Bousbouras wrote:

> it's just that in C++ and the like, you don't trust anybody, and in CLOS you
> basically trust everybody.  the practical result is that thieves and bums use C++
> and nice people use CLOS.  :)
>   Erik Naggum


Erik Naggum wrote:

> * Martin Rodgers
> | I guss Erik doesn't wish to heal any wounds.
> 
> you _are_ the wound.  if you go away, the wound will be healed.  I really
> want the wound to heal: JUST GET THE HELL OUT OF MY FACE!
> 
> and whoever gave you permission to quote from private communication?
> 
> please go die, Martin Rogders.  at least the maggots will like you.


Erik Naggum wrote:

>   You are a clever little asshole, aren't you?

> you incredibly retarded jerk!

> Man, how can you survive being so goddamn _stupid_?

> insufferably arrogant moron.

> Geez, you are such an idiot.

> your exceptionally pitiful brain

>   qualities are important?  Or are you so unphilosophical and such a
>   leering idiot with a moronic grin permanently attached to his skull that

>   had been able to think at all, you would probably experience _several_
>   revelations of such magnitude that one "god" would not be enough.



Erik Naggum wrote:

> | >   You have to get at the bytes where they are actually found, just
> | >   after they have been read, and just before they are written.
> | >   Anything else is pretty damn stupid.
> 
> | Sure. Who said otherwise?
> 
>   You have strongly implied "otherwise", you insuffable numbnut.

I have grudgingly to admit that this brilliant post proves
that Naggum was indubitably one of the leading luminaries of
the CL cosmos.

In fact, one could go so far as to say that he was the epitome
of all of the characteristics that make worshippers of CL so
special and precious.

If he were still alive, I would be sorely tempted to beseech
him for admittance into his pack of hyenas.

-- 
Jewish drug dealers, child porn pushers, and slave traders are free
from prosecution in Israel.  Israel does not consider these to be
crimes ... so long as the victims are non-Jews.
www.theoccidentalobserver.net/2009/08/the-culture-of-deceit/

[toc] | [prev] | [next] | [standalone]

#52404

In article <%mzzz.1531332$jB.1247427@fx43.am4>,
Spiros Bousbouras  <spibou@gmail.com> wrote:
<SNIP>
>> Then the code is high level Forth code, and again it is allocated
>> dynamically and a pointer to it is present in the header.
>> (High level Forth code is, of course a list of code tokens.)
>> Contrary to malloc, my ALLOCATE knows a lot about
>> the size etc of pieces allocated.
>
>malloc()  also knows about the size of pieces allocated otherwise it wouldn't
>work. The interface does not make such information available to the programmer
>but the internals of  malloc() (and related functions) certainly need to know.

That is true but that is in behalf of freeing and resizing and is in
general not byte count precise (e.g. a buddy implementation).
lisp needs the exact size of symbols, bignums and strings, and they
are available via my ALLOCATE, saving a cell and some hassle.

Groetjes Albert

>--
>it's just that in C++ and the like, you don't trust _anybody_, and in CLOS you
>basically trust everybody.  the practical result is that thieves and bums use C++
>and nice people use CLOS.  :)
>  Erik Naggum
>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50775

Can you make it Emacs Lisp, so we can use it to rewrite Emacs in Forth?

Just kidding.  Or maybe not?

[toc] | [prev] | [next] | [standalone]

#50882

Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Can you make it Emacs Lisp, so we can use it to rewrite Emacs in Forth?
>
>Just kidding.  Or maybe not?

There is Forthmacs, but there the macro language is Forth.
Otherwise, why rewrite the C part of GNU Emacs in Forth?  It's a big
and complex program, and you would have to maintain compatibility with
its big and complex interface (otherwise, why go for Lisp at all?).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web