I'd like to announce the availability of a small Lisp
interpreter. Versions exist for MS-DOS and UNIX (AIX).
It is written in ANSI-C, the source is available, and is
Public Domain.
The MS-DOS version supports CGA/EGA/VGA graphics and the Microsoft
Mouse.
The interpreter is a shallow-binding, reference counting design
making it suitable for experimenting with real-time and
graphic user interface programming.
Common Lisp compatibility macros are provided, and most of the examples
in "Lisp" by Winston & Horn have been run on RefLisp.
RefLisp comes with an ASCII manual and many demonstration
programs, including an analogue clock which never stops for garbage
collection.
To obtain source or binary copies, please email me at the address below.
A Question: I don't have access to an anonymous ft server, is there
a server somewhere that I can _upload_ RefLisp to?
This would allow people to take copies without email
drama.
Thanks for your attention,
Bill Birch
--
Bill Birch | ·······@uk03.bull.co.uk
Bull Info. Sys. Ltd. | Bull Tel: 773 4770
Maxted Road, | Bull Mail: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884770
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
Aviate, Navigate, Communicate...
From: Stefan Voss
Subject: Re: Yet another Lisp Interpreter Available (RefLisp)
Date:
Message-ID: <1gk60iINNjg8@iraul1.ira.uka.de>
In article <······················@uk03.bull.co.uk>, ······@hemel.bull.co.uk (Bill Birch) writes:
|> I'd like to announce the availability of a small Lisp
|> interpreter. Versions exist for MS-DOS and UNIX (AIX).
|> It is written in ANSI-C, the source is available, and is
|> Public Domain.
|>
Can you shortly describe the features of RefLisp ?
How close is it to Common Lisp ? What are the differences ?
|> Bill Birch
|> --
|> Bill Birch | ·······@uk03.bull.co.uk
|> Bull Info. Sys. Ltd. | Bull Tel: 773 4770
|> Maxted Road, | Bull Mail: HM14 UK03
|> Hemel Hempstead, | Tel: +44 442 884770
|> HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
|> Aviate, Navigate, Communicate...
Stefan Voss
(····@ira.uka.de)
····@i40s16.ira.uka.de (Stefan Voss) writes:
>Can you shortly describe the features of RefLisp ?
- RefLisp is not Common Lisp (CL), there are already plenty of
good, free Common Lisps available.
- RefLisp has reference counting garbage collection, that means
memory is reclaimed as soon as it is un-used. It is a "non-stop"
system, in that there is never any halt for garbage collection (GC).
This means that you can write programs which rely on a deterministic
response time. For example there is a demo program: "clock.lsp"
which draws an analogue clock-face, and the hands move every
clock tick, without stopping. I think if you tried to do this
with a GC interpreter, every so often the clock would stop
working while the interpreter cleaned up memory. There
is also a very basic flight simulator in Lisp on the RefLisp
distribution, it draws the track an aircraft might make on
a radar screen.
Another example is in a
drawing program "gob.lsp"; there is Lisp code which does
rubber-banding. The line follows the mouse movement. If a
GC system was used, the mouse-following would probably stop
occasionally during GC, leaving the user somewhat bewildered!
RefLisp collects garbage on the fly, therefore this never happens,
so you get a responsive User Interface. In theory, one could write
a playable space-invaders game in RefLisp. [I would if I had time.]
On a small PC with limited memory, a GC system would
be continually running out of memory resulting in a garbage
collection. Since each GC takes some time, my guess is that
the interpreter would spend most of its time in the GC.
By contrast, RefLisp would only do garbage collection
when required, and should therefore be faster. (I have no proof
for this, just a hunch based on experience with Cambridge Lisp for
the Sinclair QL, a 64kbyte home computer).
Reference-counting (as implemented in RefLisp) also makes it
relatively easy to convert from Lisp to 'C'. This is because
any foreign C program can mark Lisp objects and release them
when finished. The reference-count works like a PV semaphore,
so any module has access to garbage collection. I think
is quite trivial to embed RefLisp into major 'C' programs.
For example there is a RefLisp binding for Tuxedo
(a Transaction Processing Monitor).
So to sum up, RefLisp lets you play around with algorithms which
demand a deterministic response time.
- RefLisp is shallow binding.
- it's a "small" Lisp system, ie there is no compiler, nor
are there 1000s of in-built functions.
- RefLisp is just a small portable system for experimenting with
reference-counting garbage collection.
>How close is it to Common Lisp ?
Close enough to run under-graduate type examples from
introduction texts to Common Lisp.
Reflisp does implement: ' ` , ,@ #' &rest &optional
and a few other important CL features. At present most CL
functions are provided in Lisp source form, dolist etc
What are the differences ?
Without wanting to offend anyone, CL is huge, RefLisp is
tiny. RefLisp does not implement even a small fraction of CLtL2.
RefLisp is shallow binding, ie everything has dynamic scope.
Reflisp has no Compiler
RefLisp makes no distinction between symbol-values and function-values,
a symbol is either but not both.
A symbol can have an s-expression as it's print name.
There are some optional extensions which are not-standard.
Please, email me for more details.
Best Wishes for the season,
Bill
--
Bill Birch | ·······@uk03.bull.co.uk
Bull Info. Sys. Ltd. | Bull Tel: 773 4770
Maxted Road, | Bull Mail: HM14 UK03
Hemel Hempstead, | Tel: +44 442 884770
HERTS, HP2 7DZ, U.K. | Fax: +44 442 884570
Aviate, Navigate, Communicate...
From: Barry Margolin
Subject: Reference counting (was Re: Yet another Lisp Interpreter Available (RefLisp) Long)
Date:
Message-ID: <1gr5ejINN3k5@early-bird.think.com>
In article <······················@uk03.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
> - RefLisp has reference counting garbage collection, that means
> memory is reclaimed as soon as it is un-used. It is a "non-stop"
> system, in that there is never any halt for garbage collection (GC).
This is a frequent claim that is simply not true. A reference counting
system simply changes the time and distribution of the GC delays, but it
doesn't eliminate it. For instance, if you allocate a million-element
list, and then lose the pointer to the first element, that operation will
take a million times longer than losing a pointer to the head of a
one-element list, as it has to recursively deallocate all the objects in
the list (assuming there are no other pointers into the list). No matter
how fast your reference counting scheme is, I can always construct a data
structure that takes a noticeable amount of time to deallocate it when the
last pointer to the first element is dropped (assuming there's enough
memory).
Reference counting GC's also have the misfeature that they must reference
the object that a pointer points to when the pointer is reassigned. On a
system with demand-paged virtual memory, this could cause an unnecessary
page fault, further slowing down the assignment.
Modern generational garbage collectors also distribute the GC delays more
evenly than old stop-and-copy or mark-sweep GCs.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
From: Marty Hall
Subject: Re: Reference counting (was Re: Yet another Lisp Interpreter Available (RefLisp) Long)
Date:
Message-ID: <BzMD1E.EGp@aplcenmp.apl.jhu.edu>
······@think.com (Barry Margolin) writes:
>······@hemel.bull.co.uk (Bill Birch) writes:
>> - RefLisp has reference counting garbage collection, that means
>> memory is reclaimed as soon as it is un-used. It is a "non-stop"
>> system, in that there is never any halt for garbage collection (GC).
>
>This is a frequent claim that is simply not true. A reference counting
>system simply changes the time and distribution of the GC delays, but it
>doesn't eliminate it. For instance [...]
A PostScript version of a good (in my non-expert opinion) survey of GC
techniques is available by anonymous FTP from cs.utexas.edu, in
/pub/garbage/gcsurvey.ps.
Wilson, Paul R., "Uniprocessor Garbage Collection Techniques", to appear
in _Proceedings of the 1992 International Workshop on Memory Management_.
- Marty
(proclaim '(inline skates))
From: Robert Virding
Subject: Re: Reference counting (was Re: Yet another Lisp Interpreter Available (RefLisp) Long)
Date:
Message-ID: <1992Dec22.141011.8019@eua.ericsson.se>
In article <············@early-bird.think.com>, ······@think.com (Barry Margolin) writes:
>In article <······················@uk03.bull.co.uk> ······@hemel.bull.co.uk (Bill Birch) writes:
>> - RefLisp has reference counting garbage collection, that means
>> memory is reclaimed as soon as it is un-used. It is a "non-stop"
>> system, in that there is never any halt for garbage collection (GC).
>
>This is a frequent claim that is simply not true. A reference counting
>system simply changes the time and distribution of the GC delays, but it
>doesn't eliminate it. For instance, if you allocate a million-element
>list, and then lose the pointer to the first element, that operation will
>take a million times longer than losing a pointer to the head of a
>one-element list, as it has to recursively deallocate all the objects in
>the list (assuming there are no other pointers into the list). No matter
>how fast your reference counting scheme is, I can always construct a data
>structure that takes a noticeable amount of time to deallocate it when the
>last pointer to the first element is dropped (assuming there's enough
>memory).
There are reference counting schemes in which the GC delays can be
made arbitarily small, even real-time. It is not my scheme but I know
because I have made a real-time implementation using it. See
Glaser, H.W., and Thompson, P., "Lazy Garbage Collection". Software -
Practice and Experience, 17(1), 1-4, January 1987.
Robert Virding @ Ellemtel Utvecklings AB, Stockholm
EMAIL: ··@erix.ericsson.se