From: sajiimori
Subject: Lisp w/out GC
Date: 
Message-ID: <StjIb.12073$lo3.4009@newsread2.news.pas.earthlink.net>
Note: I've only been using CL for a few weeks.

This question is directed mostly toward experienced users of both Lisp and
system-level or embedded C.  If you think that Lisp can be practical in all
cases where C is currently used, this thread is not for you.  (Think GameBoy
Advance.)

Clearly, a Lisp without garbage collection is no Lisp at all.  Explicit
memory management would turn currently elegant code into bloated cludgery.
Previously simple tasks would become arduous and bug-prone.

But let's forget that for a moment and look at it from a different
perspective:  If a language had all the features of Lisp (most notably the
equivalence of code and data) except those which make it impractical for
small systems (especially garbage collection), would it still be
significantly more expressive than C?

The reason I ask is because I intend to develop such a language if it's
worth the effort.

From: Thomas F. Burdick
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <xcvisjynlgg.fsf@famine.OCF.Berkeley.EDU>
"sajiimori" <··········@hotmail.com> writes:

> Note: I've only been using CL for a few weeks.
> 
> This question is directed mostly toward experienced users of both Lisp and
> system-level or embedded C.  If you think that Lisp can be practical in all
> cases where C is currently used, this thread is not for you.  (Think GameBoy
> Advance.)
> 
> Clearly, a Lisp without garbage collection is no Lisp at all.  Explicit
> memory management would turn currently elegant code into bloated cludgery.
> Previously simple tasks would become arduous and bug-prone.

There are a variety of ways to manage dynamic memory usage, with
malloc/free at one end of the spectrum, and full GC at the other.  I
agree that a Lisp that used malloc/free would be almost unusable
except for very low-level hackery (probably for bootstrapping a fully
GC'ed Lisp into existance).  However, I could imagine a perfectly
usable Lisp dialect that used pool- or arena-based memory allocation.

> But let's forget that for a moment and look at it from a different
> perspective:  If a language had all the features of Lisp (most notably the
> equivalence of code and data) except those which make it impractical for
> small systems (especially garbage collection), would it still be
> significantly more expressive than C?
> 
> The reason I ask is because I intend to develop such a language if it's
> worth the effort.

I think you'd do best to develop a Lisp dialect with a custom memory
management scheme.  Besides, you probably don't actually want to use a
malloc/free approach -- think of all the cycles you wast in calls to
free()!

I'm not even entirely sure I accept your premise that GC is not
appropriate in these environments.  There's a whole world of garbage
collection approaches out there, which all have different trade-offs.
Before you write off GC entirely, you should spell out exactly what
you need out of a memory management system, including what you're
willing to trade for what, and try to find approaches that would be
appropriate.  Maybe you'll find GC schemes, maybe not, but I'm pretty
sure you won't find malloc/free :-)

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Gareth McCaughan
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <87fzf1reuw.fsf@g.mccaughan.ntlworld.com>
Thomas Burdick wrote:

>                         think of all the cycles you wast in calls to
> free()!

That should be "thou wast", not "you wast". HTH. :-)

-- 
Gareth McCaughan
.sig under construc
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7xwu8eaxl7.fsf@ruckus.brouhaha.com>
"sajiimori" <··········@hotmail.com> writes:
> But let's forget that for a moment and look at it from a different
> perspective:  If a language had all the features of Lisp (most notably the
> equivalence of code and data) except those which make it impractical for
> small systems (especially garbage collection), would it still be
> significantly more expressive than C?

Unless you're talking about really tiny embedded platforms, GC is
worthwhile.  On really tiny platforms, dynamic typing probably hurts
you more than GC.  Look at Javacard or J2ME for example.  They are
statically typed, run on 8 bit embedded cpu's (Javacard), and support
GC.
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <r5lIb.12178$lo3.12136@newsread2.news.pas.earthlink.net>
> Unless you're talking about really tiny embedded platforms, GC is
> worthwhile.

I'm talking about 288K of RAM, a 16 MHz CPU, and realtime requirements.
Still worthwhile?

> On really tiny platforms, dynamic typing probably hurts
> you more than GC.

Agreed.  The reason I didn't specify "Lisp without dynamic typing" is
because static typing is possible in Lisp, but explicit memory management is
not (right?).
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7x3cb2jard.fsf@ruckus.brouhaha.com>
"sajiimori" <··········@hotmail.com> writes:
> > Unless you're talking about really tiny embedded platforms, GC is
> > worthwhile.
> 
> I'm talking about 288K of RAM, a 16 MHz CPU, and realtime requirements.
> Still worthwhile?

Yes of course.  A system like that is quite a bit more powerful than
the PDP-6's and some of the PDP-10's that Maclisp, Macsyma, etc. were
developed on.  I wouldn't even call it a small system.  By tiny
embedded platform I meant a few hundred bytes of ram or less.
Javacard runs with GC on smart cards having 6k or so.

Note that the Lisp dialect usually discussed here is Common Lisp which
is unrealistic to run in the machine you describe.  You'll need to
use something smaller.

> Agreed.  The reason I didn't specify "Lisp without dynamic typing"
> is because static typing is possible in Lisp, but explicit memory
> management is not (right?).

Nothing is impossible in Lisp :).  Seriously though, if you want a
statically typed language with no GC, what does that really leave you?
From: Thomas F. Burdick
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <xcvd6a6ni0h.fsf@famine.OCF.Berkeley.EDU>
"sajiimori" <··········@hotmail.com> writes:

> > Unless you're talking about really tiny embedded platforms, GC is
> > worthwhile.
> 
> I'm talking about 288K of RAM, a 16 MHz CPU, and realtime requirements.
> Still worthwhile?

Hah, that's more powerful than the first PC I had (a 10MHz 286, with
256Kb RAM, and a 20Gb HDD), and I know I had a Lisp that ran on it
(though I never did learn Lisp at the time).

If you're very conservative about allocating memory, you can probably
run for very long periods between GCs.  Just run the GC between game
levels (or some other place where a pause is acceptable), and you'll
be fine.  Or use memory pools :-)

> > On really tiny platforms, dynamic typing probably hurts
> > you more than GC.
> 
> Agreed.  The reason I didn't specify "Lisp without dynamic typing" is
> because static typing is possible in Lisp, but explicit memory management is
> not (right?).

Ick, I don't know why you'd want to.  The system you're describing
really isn't that tiny.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Paul Tarvydas
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <qe_Ib.252540$ea%.91676@news01.bloor.is.net.cable.rogers.com>
In the late '70's Fritz van der Wateren (sp?) lisp ran on a 8-bit 6800
(500Khz?).  The complete interpreter (+GC'er) fit in 4K (assembler code). 
It needed another 4K or so of RAM to do anything interesting.

I hand-translated it to Z80 (assembly) code.  The resulting interpreter was
5K of code.  When I wire-wrapped more memory onto the system - up to 22K -
I entered all of John R. Allen's Anatomy of Lisp lisp compiler (in lisp). 
The compiler resided and ran in the 22K Z80 and compiled and ran trivial
programs.

In contrast, my first C compiler was Small C (DDJJoCaO, ~1980).  I worked
for over 9 months to rewrite it to fit and run in less than 64K on an 8080.

pt
From: Paul Wallich
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bsso4s$ijv$1@reader2.panix.com>
sajiimori wrote:

>>Unless you're talking about really tiny embedded platforms, GC is
>>worthwhile.
> 
> 
> I'm talking about 288K of RAM, a 16 MHz CPU, and realtime requirements.
> Still worthwhile?

That would be somewhat better specs than the original amiga, on which
Cambridge Lisp ran quite nicely, with benchmarks comparable to some lisp 
machines of the time, somewhat worse specs than the Mac Plus, which ran 
an entire Lisp development environment (Coral) complete with GUI. I've
written perfectly useful (as in contributed to someone getting tenure) 
Lisp programs on machines with 64K of RAM.
> 
> 
>>On really tiny platforms, dynamic typing probably hurts
>>you more than GC.
> 
> 
> Agreed.  The reason I didn't specify "Lisp without dynamic typing" is
> because static typing is possible in Lisp, but explicit memory management is
> not (right?).

As someone else pointed out, it's possible to manage objects almost 
entirely by hand in Lisp if you really insist. It's somewhat harder to 
do stupid pointer tricks and type munging (which is what some folks 
asking for explicit memory management really seem to want).

I like Pascal's idea of Forth as Lisp without GC, although you could 
argue that stack discipline is a rudimentary form of automatic storage
management...

paul
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7xsmj125s3.fsf@ruckus.brouhaha.com>
Paul Wallich <··@panix.com> writes:
> I like Pascal's idea of Forth as Lisp without GC, although you could
> argue that stack discipline is a rudimentary form of automatic storage
> management...

Well, without GC and without any datatypes either static or dynamic.
Think of how you implement arrays in Forth.  It's more like assembly
anguage.
From: Paul Wallich
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bstmh2$rv5$1@reader2.panix.com>
Paul Rubin wrote:

> Paul Wallich <··@panix.com> writes:
> 
>>I like Pascal's idea of Forth as Lisp without GC, although you could
>>argue that stack discipline is a rudimentary form of automatic storage
>>management...
> 
> 
> Well, without GC and without any datatypes either static or dynamic.
> Think of how you implement arrays in Forth.  It's more like assembly
> anguage.

More like assembly language than what? Although the core language has 
minimal facilities for typing, the whole style of development by 
creating new words (and hence new accessors) tends to do a pretty good 
job of encapsulation.

paul
From: Larry Elmore
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <qaqIb.706157$Fm2.609382@attbi_s04>
Paul Rubin wrote:
> Paul Wallich <··@panix.com> writes:
> 
>>I like Pascal's idea of Forth as Lisp without GC, although you could
>>argue that stack discipline is a rudimentary form of automatic storage
>>management...
> 
> Well, without GC and without any datatypes either static or dynamic.
> Think of how you implement arrays in Forth.  It's more like assembly
> language.

Yes, albeit an extensible assembly language for a portable VM. I've 
wondered in the past about how a Lisp might be implemented using Forth 
as a base. Never had the time to do anything with it, though.

--Larry
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <S2tIb.13063$lo3.8464@newsread2.news.pas.earthlink.net>
> > Well, without GC and without any datatypes either static or dynamic.
> > Think of how you implement arrays in Forth.  It's more like assembly
> > language.
>
> Yes, albeit an extensible assembly language for a portable VM.

Would you agree that its extensibility is due to its consistency (a
necessary side-effect of its lack of syntax)?  That might explain the
special relationship it shares with Lisp.  A language with more syntax will
not appear to be extensible because user-defined operations are used
differently than built-in ones.  C++ tries to solve this problem with
operator overloading, but this results in even more horrendously complex
syntax.
From: Larry Elmore
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <0kpJb.35544$I07.106717@attbi_s53>
sajiimori wrote:
>>>Well, without GC and without any datatypes either static or dynamic.
>>>Think of how you implement arrays in Forth.  It's more like assembly
>>>language.
>>
>>Yes, albeit an extensible assembly language for a portable VM.
> 
> 
> Would you agree that its extensibility is due to its consistency (a
> necessary side-effect of its lack of syntax)?  That might explain the
> special relationship it shares with Lisp.  A language with more syntax will
> not appear to be extensible because user-defined operations are used
> differently than built-in ones.  C++ tries to solve this problem with
> operator overloading, but this results in even more horrendously complex
> syntax.

Yes, Forth and Lisp are alike in that user-created functions look and 
behave just like any part of the core language. In fact, any part of the 
core language can be replaced with user code. In part, I think Forth's 
worst problem is that the core Forth language is so small, and it's so 
easily extensible and rewritten, that there is an endless profusion of 
tiny, often incompatible Forths. It's kind of like the Scheme world in 
that regard, but even worse because the language is simpler to implement 
and so more people try their hand at implementing one. It's a valuable 
learning exercise, but doesn't really take the language very far.

--Larry
From: Will Hartung
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bt5a0k$3glkk$1@ID-197644.news.uni-berlin.de>
"Larry Elmore" <·········@_comcast_._net> wrote in message
···························@attbi_s53...
> sajiimori wrote:

> Yes, Forth and Lisp are alike in that user-created functions look and
> behave just like any part of the core language. In fact, any part of the
> core language can be replaced with user code. In part, I think Forth's
> worst problem is that the core Forth language is so small, and it's so
> easily extensible and rewritten, that there is an endless profusion of
> tiny, often incompatible Forths. It's kind of like the Scheme world in
> that regard, but even worse because the language is simpler to implement
> and so more people try their hand at implementing one. It's a valuable
> learning exercise, but doesn't really take the language very far.

My other complaint about Forth is that its stack like nature goes into its
vocabularies, in that you can not make a change to a word without changing
everything defined after it, which means that you're always reloading a lot
of code.

I understand WHY this is the case, but for larger systems with lots of
components, I think the ability of Lisp to change an older definition "in
place" is a "friendlier" environment. It also places a lot more dependency
on load order and whatnot.

It also makes it basically unusable for "generic" applications, as you
simply can't "load" an application, say, and then load another application,
and finally "reload" the first one. While I've seen requests for "Forth OS",
these aspects limit its domain, I think. Of course, it could certainly be
extended to handle this kind of thing.

This really only comes to mind for larger systems, but in its domain of
embedded systems etc, this isn't much of a problem.

(And yes, I know about DEFER'd words.)

Finally, the ultimate example of the similarity of Forth and Lisp is HP's
RPL, which is essentially, a Forth-like Lisp. A really neat environment.

Regards,

Will Hartung
(·····@msoft.com)
From: Pascal Costanza
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bstdu9$ijs$1@newsreader2.netcologne.de>
Paul Rubin wrote:

> Paul Wallich <··@panix.com> writes:
> 
>>I like Pascal's idea of Forth as Lisp without GC, although you could
>>argue that stack discipline is a rudimentary form of automatic storage
>>management...
> 
> 
> Well, without GC and without any datatypes either static or dynamic.
> Think of how you implement arrays in Forth.  It's more like assembly
> anguage.

...but it would be strange to go down to the metal in one respect but 
not in others, wouldn't it?

I have really tried to refer to the fact that Forth programming 
apparently means domain-oriented programming, so there seems to be some 
connection to Lisp in spirit.


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <SUsIb.13032$lo3.3016@newsread2.news.pas.earthlink.net>
> It's somewhat harder to
> do stupid pointer tricks and type munging (which is what some folks
> asking for explicit memory management really seem to want).

Stupid pointer tricks don't look so stupid after you use them to increase
the performance of your inner loop by 150%.

> I like Pascal's idea of Forth as Lisp without GC, although you could
> argue that stack discipline is a rudimentary form of automatic storage
> management...

Which part of it is automatic?  C has a much more automatic style of stack
management because arguments and local variables are cleaned up without
programmer intervention.  It's fault-proof and requires perhaps 2 CPU
instructions.
From: Matthew Danish
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <20031231054517.GA31217@mapcar.org>
On Wed, Dec 31, 2003 at 05:12:18AM +0000, sajiimori wrote:
> > It's somewhat harder to
> > do stupid pointer tricks and type munging (which is what some folks
> > asking for explicit memory management really seem to want).
> 
> Stupid pointer tricks don't look so stupid after you use them to increase
> the performance of your inner loop by 150%.

If that's the case, then it's the fault of the compiler for not
performing the proper optimizations (ie. loop invariant hoisting and
induction variable elimination, or partial redundancy elimination,
etc...)

> > I like Pascal's idea of Forth as Lisp without GC, although you could
> > argue that stack discipline is a rudimentary form of automatic storage
> > management...
> 
> Which part of it is automatic?  C has a much more automatic style of stack
> management because arguments and local variables are cleaned up without
> programmer intervention.  It's fault-proof and requires perhaps 2 CPU
> instructions.

Note that this can be done in Lisp too, with a compiler that supports
dynamic-extent declarations.

-- 
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <z1vIb.13249$lo3.10913@newsread2.news.pas.earthlink.net>
> > Stupid pointer tricks don't look so stupid after you use them to
increase
> > the performance of your inner loop by 150%.
>
> If that's the case, then it's the fault of the compiler for not
> performing the proper optimizations (ie. loop invariant hoisting and
> induction variable elimination, or partial redundancy elimination,
> etc...)

Hmm...you're right; I don't need pointer math.  I just saw GCC turn this:

  for(y = y1; y < y2; ++y)
    dst[y*w + x] = c;

into this:

  L7:
    movb %bl, (%eax)
    addl %esi, %eax
    decl %ecx
    jne L7

Sorry for my ignorance.
From: Greg Menke
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <m365fyyqzk.fsf@europa.pienet>
"sajiimori" <··········@hotmail.com> writes:

> > Unless you're talking about really tiny embedded platforms, GC is
> > worthwhile.
> 
> I'm talking about 288K of RAM, a 16 MHz CPU, and realtime requirements.
> Still worthwhile?

Sure.  Lisp on the Atari 800 had a gc- about 32k ram usable and a 1
mhz 6502.  How "realtime" is your realtime?
 
Gregm
From: Wade Humeniuk
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <ThlIb.48406$6b2.43011@edtnps84>
sajiimori wrote:
>>Unless you're talking about really tiny embedded platforms, GC is
>>worthwhile.
> 
> 
> I'm talking about 288K of RAM, a 16 MHz CPU, and realtime requirements.
> Still worthwhile?
> 

Embedded development is usually seperated into two parts with most
of the devolopment done on emulators.  Its a royal pain to develop and debug
on your target platform.  One of the great things that can be done with
Lisp is to "easily" create an emulator to develop and test your code
on, then "deliver" an app that runs on the embedded platform.  The
"embedded" language could be a subset of CL, kind of an embedded
Lisp, suitable for your real-time requirements, complete with a compiler.
Lisp excels at developing domain specific languages.  Would it need GC?
Its up to you, if most of your memory is statically allocated there may
be no need for any GC.

Most of this has probably been done at one time.

Wade
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <lulIb.12203$lo3.3586@newsread2.news.pas.earthlink.net>
> Its a royal pain to develop and debug on your target platform.

Agreed.  I am actually developing on a system with 256MB of RAM and a 700MHz
CPU.

> The "embedded" language could be a subset of CL, kind of an embedded
> Lisp, suitable for your real-time requirements, complete with a compiler.
> ...
> Most of this has probably been done at one time.

Anything publicly available?  Something that compiles to C perhaps?  If not,
what you described is exactly what I'll be doing.
From: Wade Humeniuk
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <3FmIb.98956$ss5.8786@clgrps13>
sajiimori wrote:
>>Its a royal pain to develop and debug on your target platform.
> 
> 
> Agreed.  I am actually developing on a system with 256MB of RAM and a 700MHz
> CPU.
> 
> 
>>The "embedded" language could be a subset of CL, kind of an embedded
>>Lisp, suitable for your real-time requirements, complete with a compiler.
>>...
>>Most of this has probably been done at one time.
> 
> 
> Anything publicly available?  Something that compiles to C perhaps?  If not,
> what you described is exactly what I'll be doing.
> 
> 

Maybe ThinLisp at http://www.thinlisp.org/

Wade
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <J4nIb.12347$lo3.4662@newsread2.news.pas.earthlink.net>
> Maybe ThinLisp at http://www.thinlisp.org/

Looks like exactly what I need.  Thanks!  :-)
From: Larry Clapp
Subject: CMUCL or ThinLisp bug?  WAS: Re: Lisp w/out GC
Date: 
Message-ID: <slrnbv691k.ih8.larry@theclapp.ddts.net>
In article <····················@clgrps13>, Wade Humeniuk wrote:
> sajiimori wrote:
>> Anything publicly available?  Something that compiles to C perhaps?
>> If not, what you described is exactly what I'll be doing.
> 
> Maybe ThinLisp at http://www.thinlisp.org/

I got ThinLisp 1.0.1 from SourceForge.  I had some problems compiling
it (using "CMU Common Lisp CVS release-18e-branch + minimal debian
patches").  ThinLisp has a function

(defun compile-load-tlt-module (module force-recompile? count total)
  (let* ((file-name (string-downcase (symbol-name module)))
     (lisp-file 
       (finalize-pathname
         (make-pathname :directory '(:relative "tlt" "lisp")
	        :name file-name
	        :type lisp-file-type)))
     (bin-file 
      (finalize-pathname (make-pathname
	          :directory 
	          #-clisp-old '(:relative "tlt" "dev")
	          #+clisp-old '(:relative "tlt" "lisp")
	          :name file-name
	          :type binary-file-type)))
    ; ... [entire function included below]

which uses COMPILE-FILE to compile LISP-FILE and output to BIN-FILE.
For example, it compiles tlt/lisp/boot.lisp and wants it to go into
tlt/dev/boot.x86f.  However, cmucl ends up trying to write to
tlt/lisp/tlt/dev/boot.x86f.  A traceback:


Error in function OPEN:
   Error creating #p"tlt/lisp/tlt/dev/boot.x86f", path does not exist.

Restarts:
  0: [CONTINUE] Return NIL.
  1: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

(OPEN #p"tlt/lisp/tlt/dev/boot.x86f" :DIRECTION :OUTPUT :ELEMENT-TYPE ...)
Source: 
; File: target:code/fd-stream.lisp
(CERROR "Return NIL."
        'SIMPLE-ERROR
        :FORMAT-CONTROL
        "Error creating ~S, path does not exist."
        ...)
0] ba

0: (OPEN #p"tlt/lisp/tlt/dev/boot.x86f" :DIRECTION :OUTPUT :ELEMENT-TYPE ...)
1: (C::OPEN-FASL-FILE #p"tlt/lisp/tlt/dev/boot.x86f" "tlt/lisp/boot.lisp" NIL)
2: (COMPILE-FILE #p"tlt/lisp/boot.lisp"
                 :OUTPUT-FILE
                 #p"tlt/dev/boot.x86f"
                 :ERROR-FILE
                 ...)
3: (COMPILE-LOAD-TLT-MODULE BOOT NIL 1 38)
4: (COMPILE-TLT :RECOMPILE NIL :FROM NIL ...)[:OPTIONAL]
5: (COMPILE-TLT :RECOMPILE NIL :FROM NIL ...)[:OPTIONAL]
6: (INTERACTIVE-EVAL (COMPILE-TLT))

Notice in particular steps 2 & 1.

It would appear that either

1. COMPILE-FILE should try to write to tlt/dev/boot.x86f instead of
tlt/lisp/tlt/dev/boot.x86f (CMUCL bug?)

or

2. BIN-FILE should = #p"boot.x86f" instead of #p"tlt/dev/boot.x86f"
(ThinLisp bug?)

or

3. Some other problem ...

So, should I report this to the CMUCL developers or the ThinLisp
developers?  ... Or have they fixed this in CMUCL CVS already?  (I
tried to check the current cvs, as mentioned in "Anonymous CVS access"
of the cmucl online manual, but anoncvs.cons.org won't talk to me.)

-- Larry

-- 

compile-load-tlt-module full source:

(defun compile-load-tlt-module (module force-recompile? count total)
  (let* ((file-name (string-downcase (symbol-name module)))
	 (lisp-file 
	   (finalize-pathname
	     (make-pathname :directory '(:relative "tlt" "lisp")
			    :name file-name
			    :type lisp-file-type)))
	 (bin-file 
	  (finalize-pathname (make-pathname
			      :directory 
			      #-clisp-old '(:relative "tlt" "dev")
			      #+clisp-old '(:relative "tlt" "lisp")
			      :name file-name
			      :type binary-file-type)))
	 (relative-bin-file 
	  #+lucid
	  (finalize-pathname (make-pathname
			      :directory '(:relative :up "dev")
			      :name file-name
			      :type binary-file-type))
	  #-lucid
	  bin-file)
	 (lisp-date (and (probe-file lisp-file)
			 (file-write-date lisp-file)))
	 (bin-date? (and (probe-file bin-file)
			 (file-write-date bin-file)))
	 (load-date? (get module :tlt-load-date)))
    #+clisp-old
    (declare (ignore relative-bin-file))
    (when (null lisp-date)
      (warn "Module ~a does not have a corresponding lisp file ~a."
	    module lisp-file))
    (ensure-directories-exist bin-file :verbose nil)
    (when (eq module 'exports)
      (setq exports-file-write-date lisp-date))
    (when (or force-recompile?
	      (null bin-date?)
	      (and lisp-date
		   (<= bin-date? lisp-date))
	      (and exports-file-write-date
		   (<= bin-date? exports-file-write-date)))
      ;; The following weird construction forces line output buffering.
      (write-string (format nil "Compiling   ~40a    [~3d/~3d] ~%" lisp-file count total))
      (force-output)
      (compile-file lisp-file #-clisp-old :output-file #-clisp-old relative-bin-file
		    :verbose nil :print nil)
      (setq bin-date? (file-write-date bin-file)))
    (when (or (null load-date?)
	      (/= load-date? bin-date?))
      ;; The following weird construction forces line output buffering.
      (write-string (format nil "Loading     ~40a    [~3d/~3d] ~%" bin-file count total))
      (force-output)
      (load bin-file :verbose nil)
      (setf (get module :tlt-load-date) bin-date?))))
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: CMUCL or ThinLisp bug?  WAS: Re: Lisp w/out GC
Date: 
Message-ID: <w4clloshbh3.fsf@boris.cd.chalmers.se>
Larry Clapp <·····@theclapp.org> writes:
<problem with building thinlisp>
> So, should I report this to the CMUCL developers or the ThinLisp
> developers?

I had a slight problem with that, last I tried to build ThinLisp
(which was two years ago). It seems there isn't very much activity
with ThinLisp, though. The only changes necessary then were (and seem
to be now) to add a conditional to the stuff about pathnames in
boot.lisp and system.lisp; where it says lucid, change to (or lucid
cmu).

A patch might be handy:

--- ./tlt/lisp/system.lisp.ORIG 2003-12-31 22:54:50.000000000 +0100
+++ ./tlt/lisp/system.lisp      2003-12-31 22:55:50.000000000 +0100
@@ -352,9 +352,9 @@
     (system-lisp-binary-dir system)))
 
 (defun system-lisp-relative-binary-file (system module-name-symbol)
-  #+lucid
+  #+(or lucid cmu)
   (declare (ignore system))
-  #+lucid
+  #+(or lucid cmu)
   (make-pathname
     :name (string-downcase (symbol-name module-name-symbol))
     :type lisp-binary-file-type
@@ -363,7 +363,7 @@
                     (if (eval-feature :development)
                         lisp-dev-binary-directory-name
                       lisp-macro-binary-directory-name)))
-  #-lucid
+  #-(or lucid cmu)
   (system-lisp-binary-file system module-name-symbol))
 
 (defun system-trans-data-file (system module-name-symbol)
--- ./tlt/lisp/boot.lisp.ORIG   2003-12-31 23:02:24.000000000 +0100
+++ ./tlt/lisp/boot.lisp        2003-12-31 23:02:46.000000000 +0100
@@ -263,12 +263,12 @@
                              :name file-name
                              :type binary-file-type)))
         (relative-bin-file 
-         #+lucid
+         #+(or lucid cmu)
          (finalize-pathname (make-pathname
                              :directory '(:relative :up "dev")
                              :name file-name
                              :type binary-file-type))
-         #-lucid
+         #-(or lucid cmu)
          bin-file)
         (lisp-date (and (probe-file lisp-file)
                         (file-write-date lisp-file)))


Also, it seems some stuff is done in the USER package; if you use the
December snapshot of CMUCL, you might need to define USER as an
additional nickname of the CL-USER package. (The way CMUCL is in 18e,
and all earlier releases.)

(defpackage :common-lisp-user (:nicknames :cl-user :user))
should do that.

Apart from that, it seems to be building nicely with 18e, and with a
few warnings in the December snapshot. The lecho binary seems to be
working, though. :)

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Andreas Eder
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <m3isjxoyyf.fsf@banff.eder.de>
"sajiimori" <··········@hotmail.com> writes:

> Agreed.  The reason I didn't specify "Lisp without dynamic typing" is
> because static typing is possible in Lisp, but explicit memory management is
> not (right?).

Look into the Hyperpec - there is no mention of gc or memory
management at all. So I'd say everyting is possible in Lisp with
respect to memory management.

Andreas
-- 
Wherever I lay my .emacs, there's my $HOME.
From: Duane Rettig
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <4hdzg92ak.fsf@franz.com>
Andreas Eder <············@t-online.de> writes:

> "sajiimori" <··········@hotmail.com> writes:
> 
> > Agreed.  The reason I didn't specify "Lisp without dynamic typing" is
> > because static typing is possible in Lisp, but explicit memory management is
> > not (right?).
> 
> Look into the Hyperpec - there is no mention of gc or memory
> management at all. So I'd say everyting is possible in Lisp with
> respect to memory management.

Actually, your statement is not quite true; it does mention garbage
collection.  But the spirit of your statement is true, in that the
spec doesn't _define_  garbage-collection or any specific gc
techniques.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Richard Fateman
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <MuGIb.3805$1c3.2859@newssvr27.news.prodigy.com>
Actually I think that CLtL1, while appearing to be
agnostic about various implementation decisions, implicitly
forced certain choices, never mentioned.

Some of these were VERY subtle.

Thus you could appear to use any GC technique or maybe none,
but in practice, as I recall, certain common techniques of previous
lisps could not be used without grave efficiency hits or
extreme inconvenience.
As I vaguely recall, CLtL1 made copying GC essentially
a requirement, and made BiBoP tags impossible.  (Or is there
an ANSI CL with these??)
RJF



Duane Rettig wrote:

> Andreas Eder <············@t-online.de> writes:
> 
> 
>>"sajiimori" <··········@hotmail.com> writes:
>>
>>
>>>Agreed.  The reason I didn't specify "Lisp without dynamic typing" is
>>>because static typing is possible in Lisp, but explicit memory management is
>>>not (right?).
>>
>>Look into the Hyperpec - there is no mention of gc or memory
>>management at all. So I'd say everyting is possible in Lisp with
>>respect to memory management.
> 
> 
> Actually, your statement is not quite true; it does mention garbage
> collection.  But the spirit of your statement is true, in that the
> spec doesn't _define_  garbage-collection or any specific gc
> techniques.
> 
From: Alexander Schreiber
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <slrnbv3nlv.53l.als@thangorodrim.de>
Paul Rubin <·············@NOSPAM.invalid> wrote:
>"sajiimori" <··········@hotmail.com> writes:
>> But let's forget that for a moment and look at it from a different
>> perspective:  If a language had all the features of Lisp (most notably the
>> equivalence of code and data) except those which make it impractical for
>> small systems (especially garbage collection), would it still be
>> significantly more expressive than C?
>
>Unless you're talking about really tiny embedded platforms, GC is
>worthwhile.  On really tiny platforms, dynamic typing probably hurts
>you more than GC.  Look at Javacard or J2ME for example.  They are
>statically typed, run on 8 bit embedded cpu's (Javacard), and support
>GC.

While we are at it, do the usual Lisp implementations (gcl, SBCL, CMUCL,
CLisp) have any means to explicitly _disable_ garbage collection? I'm
currently using Lisp for writing CGI scripts, which are very short
living processes anyway (expected runtime < 10 CPU seconds), where the
possible performance difference of not doing GC would be interesting.

Regards,
      Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <w4cpte6gfmb.fsf@boris.cd.chalmers.se>
···@usenet.thangorodrim.de (Alexander Schreiber) writes:
> While we are at it, do the usual Lisp implementations (gcl, SBCL, CMUCL,
> CLisp) have any means to explicitly _disable_ garbage collection? I'm
> currently using Lisp for writing CGI scripts, which are very short
> living processes anyway (expected runtime < 10 CPU seconds), where the
> possible performance difference of not doing GC would be interesting.

CMUCL:
EXT:GC-OFF, SYS:WITHOUT-GCING

SBCL:
SB-EXT:GC-OFF, SB-SYS:WITHOUT-GCING

I don't know about clisp or GCL.

I wouldn't think that you'd save any noticeable time in CMUCL or SBCL
by disabling garbage collection.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Michael Hudson
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <m31xqlqefo.fsf@pc150.maths.bris.ac.uk>
···@usenet.thangorodrim.de (Alexander Schreiber) writes:

> While we are at it, do the usual Lisp implementations (gcl, SBCL, CMUCL,
> CLisp) have any means to explicitly _disable_ garbage collection? I'm
> currently using Lisp for writing CGI scripts, which are very short
> living processes anyway (expected runtime < 10 CPU seconds), where the
> possible performance difference of not doing GC would be interesting.

If you allocate more data than fits in the L2 cache, I wouldn't be
surprised to see performance degrade without GC.  Like you say,
interesting, but don't be too optimistic...

Cheers,
mwh

-- 
  I'm okay with intellegent buildings, I'm okay with non-sentient
  buildings. I have serious reservations about stupid buildings.
     -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <4qvg7wl3.fsf@comcast.net>
Paul Rubin <·············@NOSPAM.invalid> writes:

> "sajiimori" <··········@hotmail.com> writes:
>> But let's forget that for a moment and look at it from a different
>> perspective:  If a language had all the features of Lisp (most notably the
>> equivalence of code and data) except those which make it impractical for
>> small systems (especially garbage collection), would it still be
>> significantly more expressive than C?
>
> Unless you're talking about really tiny embedded platforms, GC is
> worthwhile.  On really tiny platforms, dynamic typing probably hurts
> you more than GC.  Look at Javacard or J2ME for example.  They are
> statically typed, run on 8 bit embedded cpu's (Javacard), and support
> GC.


Those interested should take a look at PICBIT:

  PICBIT: A Scheme System for the PIC Microcontroller 
  Marc Feeley and Danny Dube 

Abstract

  This paper explains the design of the PICBIT R4RS Scheme system
  which specifically targets the PIC microcontroller family.  The PIC
  is a popular inexpensive single-chip microcontroller for very
  compact embedded systems that has a ROM on the chip and a very small
  RAM.  The main challenge is fitting the Scheme heap in only 2
  kilobytes of RAM while still allowing useful applications to be
  run.  PICBIT uses a novel compact (24 bit) object representation
  suited for such an environment and an optimizing compiler and
  bytecode interpreter that uses RAM frugally.  Some experimental
  measurements are provided to assess the performance of thesystem.  

It has a GC and dynamic types, by the way.

-- 
~jrm
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7xpte4mpdk.fsf@ruckus.brouhaha.com>
Joe Marshall <·············@comcast.net> writes:
>   This paper explains the design of the PICBIT R4RS Scheme system
>   which specifically targets the PIC microcontroller family.  The PIC
>   is a popular inexpensive single-chip microcontroller for very
>   compact embedded systems that has a ROM on the chip and a very small
>   RAM.  The main challenge is fitting the Scheme heap in only 2
>   kilobytes of RAM while still allowing useful applications to be run.

I thought most PIC's had only a few dozen bytes of ram, with some of
the larger ones having hundreds of bytes.  I didn't know there were
any with 2 kilobytes.  
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <brpn50pn.fsf@comcast.net>
Paul Rubin <·············@NOSPAM.invalid> writes:

> Joe Marshall <·············@comcast.net> writes:
>>   This paper explains the design of the PICBIT R4RS Scheme system
>>   which specifically targets the PIC microcontroller family.  The PIC
>>   is a popular inexpensive single-chip microcontroller for very
>>   compact embedded systems that has a ROM on the chip and a very small
>>   RAM.  The main challenge is fitting the Scheme heap in only 2
>>   kilobytes of RAM while still allowing useful applications to be run.
>
> I thought most PIC's had only a few dozen bytes of ram, with some of
> the larger ones having hundreds of bytes.  I didn't know there were
> any with 2 kilobytes.  

The PIC18F6520 has 2048 x 8 bits of RAM  (and 16K of ROM)
The PIC18F8720 has 3840 x 8 bits of RAM  (and 64K of ROM)



-- 
~jrm
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7x7k0bpgf9.fsf@ruckus.brouhaha.com>
Joe Marshall <·············@comcast.net> writes:
> > I thought most PIC's had only a few dozen bytes of ram, with some of
> > the larger ones having hundreds of bytes.  I didn't know there were
> > any with 2 kilobytes.  
> 
> The PIC18F6520 has 2048 x 8 bits of RAM  (and 16K of ROM)
> The PIC18F8720 has 3840 x 8 bits of RAM  (and 64K of ROM)

Interesting, thanks.  I thought that for applications that size, other
architectures were preferable to the venerable PIC.  The PIC that I'm
most familiar with is the 16CF84 which has 72 bytes of ram these days
(earlier versions had 36 bytes).
From: Marc Battyani
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bt235e$9tr@library2.airnews.net>
"Paul Rubin" <·············@NOSPAM.invalid> wrote
> Joe Marshall <·············@comcast.net> writes:
> > > I thought most PIC's had only a few dozen bytes of ram, with some of
> > > the larger ones having hundreds of bytes.  I didn't know there were
> > > any with 2 kilobytes.
> >
> > The PIC18F6520 has 2048 x 8 bits of RAM  (and 16K of ROM)
> > The PIC18F8720 has 3840 x 8 bits of RAM  (and 64K of ROM)
>
> Interesting, thanks.  I thought that for applications that size, other
> architectures were preferable to the venerable PIC.  The PIC that I'm
> most familiar with is the 16CF84 which has 72 bytes of ram these days
> (earlier versions had 36 bytes).

Another interesting CPU is the MSP430 (ultra-low power, 16 bits, up to 1 to
60KFlash and 128 bytes to 10K RAM). There are good C compilers for it. Or the
PIC18 serie (8 bits but C friendly)

Marc
(Working on a Lisp + MSP430 + PocketPC application)
From: Duane Rettig
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <4znd96f0k.fsf@franz.com>
"sajiimori" <··········@hotmail.com> writes:

> Note: I've only been using CL for a few weeks.
> 
> This question is directed mostly toward experienced users of both Lisp and
> system-level or embedded C.  If you think that Lisp can be practical in all
> cases where C is currently used, this thread is not for you.  (Think GameBoy
> Advance.)

Perhaps not Gameboy (I don't know of anyone who has attempted that
commercially) but think Playstation2 (a la Crash Bandicoot, Jak
and Daxter).  See:

http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml

> Clearly, a Lisp without garbage collection is no Lisp at all.

An interesting exercise for you might be to search for all occurrences
of the word "garbage" or "collector" in the CL specification.  The count
is not zero, but perhaps it's lower than you would expect.  And as you
may guess, Common Lisp does not define garbage collection, and does not
even mandate it.

>  Explicit
> memory management would turn currently elegant code into bloated cludgery.
> Previously simple tasks would become arduous and bug-prone.

Possibly so, but it doesn't stop people from doing so.  Garbage
collectors generally fire either by an explicit gc call, or else by
memory filling up with objects being allocated.  If you reduce the
amount of data allocated (especially that which will be quickly
gc'd away) then you slow down the need for gc.  If you stop allocating
altogether, then you stop gcing.  And if your application is
conducive to that, then it is possible.  Perhaps that requires some
explicit menory management, and to that extent it does indeed become
arduous and bug-prone, but the best way to not garbage-collect is
to not generate garbage!...

> But let's forget that for a moment and look at it from a different
> perspective:  If a language had all the features of Lisp (most notably the
> equivalence of code and data) except those which make it impractical for
> small systems (especially garbage collection), would it still be
> significantly more expressive than C?

The question is, how small is small?  You've answered this later on
for this thread, but it's not always the case that small needs to be
on that order.  Systems are also growing, and "small" systems sometimes
have a megabyte or more of memory.  As far as Lisps are concerned,
it is true that Common Lisp is a relatively large language, and it
is just now coming into its own for deployment in "smaller" systems
(since it has not grown much, and yet systems around it are growing
relatively rapidly).  There are some much smaller lisps out there,
with functionality that tends to be reduced somewhat the smaller
you go.  

> The reason I ask is because I intend to develop such a language if it's
> worth the effort.

Some of these questions have been answered later on this thread.
I assume you're happy with the lead you've been given.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Christopher C. Stacy
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <ud6a69krd.fsf@news.dtpq.com>
You don't need a garbage collector unless the amount of garbage
that you're going to create exceeds the amount of memory available.

Lisp on the Lisp Machine included features for explicit storage
management (although there were also tied into the garbage collector).
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <eklIb.12196$lo3.4868@newsread2.news.pas.earthlink.net>
> You don't need a garbage collector unless the amount of garbage
> that you're going to create exceeds the amount of memory available.

I'm not aiming to replace "slow memory management" with "no memory
management". =)
From: Rob Warnock
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <n5KdnZuNscLWN2-i4p2dnA@speakeasy.net>
Christopher C. Stacy <······@news.dtpq.com> wrote:
+---------------
| You don't need a garbage collector unless the amount of garbage
| that you're going to create exceeds the amount of memory available.
+---------------

Indeed. A friend of mine has a small Scheme implementation he wrote
that has no garbage collection at all [just allocates as needed with
"malloc()"]. He uses it for quick & dirty Unix shell scripting and
CGI scripts, and it's fine for that.

+---------------
| Lisp on the Lisp Machine included features for explicit storage
| management (although there were also tied into the garbage collector).
+---------------

Also, see the "PreScheme" dialect which is the implementation language
for the Scheme48 VM. PreScheme is compiled to C, and has no implicit GC.


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Pascal Costanza
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bsshme$3cr$1@newsreader2.netcologne.de>
sajiimori wrote:

> If a language had all the features of Lisp (most notably the
> equivalence of code and data) except those which make it impractical for
> small systems (especially garbage collection), would it still be
> significantly more expressive than C?
> 
> The reason I ask is because I intend to develop such a language if it's
> worth the effort.

My impression is that Forth is a kind of Lisp without GC. (Please take 
this with a grain of salt since I don't have any experience with Forth.)


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Gareth McCaughan
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <87pte6qff3.fsf@g.mccaughan.ntlworld.com>
Pascal Costanza <········@web.de> writes:

> sajiimori wrote:
> 
> > If a language had all the features of Lisp (most notably the
> > equivalence of code and data) except those which make it impractical for
> > small systems (especially garbage collection), would it still be
> > significantly more expressive than C?
> > The reason I ask is because I intend to develop such a language if
> > it's
> > worth the effort.
> 
> My impression is that Forth is a kind of Lisp without GC. (Please take
> this with a grain of salt since I don't have any experience with
> Forth.)

Apart from the absence of macros, strong typing[1], a broad
range of data structures, support for object-oriented programming,
closures, a condition system, and probably a few other trifling
details, yes, Forth is just like Lisp without GC :-).


[1] Not to be confused with static typing.

-- 
Gareth McCaughan
.sig under construc
From: Russell McManus
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <87y8suymc9.fsf@thelonious.dyndns.org>
Gareth McCaughan <················@pobox.com> writes:

> Apart from the absence of macros, strong typing[1], a broad
> range of data structures, support for object-oriented programming,
> closures, a condition system, and probably a few other trifling
> details, yes, Forth is just like Lisp without GC :-).

Forth does have macros.  You can run code at compile time, and operate
on the source text using the full power of Forth.  Of course, this is
not so elegant as in Lisp, but IMHO the important most important
aspects of macros are available.

Because of this, in fact, it is pretty easy to add support for OOP to
forth.  Go figure, sounds a bit like the way CLOS was added to Lisp.

-russ
From: David Golden
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <ddnIb.2556$HR.6198@news.indigo.ie>
Russell McManus wrote:


> Forth does have macros.  You can run code at compile time, and operate
> on the source text using the full power of Forth. 

Indeed.  On the off chance "source text" conveys the wrong impression to
unforthed lispers: forth macros work at a quite symbolic level - okay forth
words aren't /exactly/ lisp symbols, but are pretty close in important
respects. Forth macros are much closer to Lisp macros than C macros.
From: David Golden
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <f4mIb.2545$HR.6241@news.indigo.ie>
Gareth McCaughan wrote:

> Apart from the absence of macros, strong typing[1], a broad
> range of data structures, support for object-oriented programming,
> closures, a condition system, and probably a few other trifling
> details, yes, Forth is just like Lisp without GC :-).
> 
> 


Well, AFAIK most Forths worthy of the name have CREATE DOES> which is
vaguely similar in spirit to macros if not in letter.  Some Forths do have
(non-standard) message-passing OO support - but in forth, like in lisp,
basic mpoo is a few lines of hackery.

http://home.earthlink.net/~leonardm/Forth/definwds.htm

"It has been said that one does not write a program in Forth. Rather, one
extends Forth to make a new language specifically designed for the
application at hand."


Hmmm... sounds vaguely familiar, that...
From: David Golden
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <SwmIb.2551$HR.6197@news.indigo.ie>
N.B. create does> is arguably the "wrong" thing to start looking at first if
you're interested in forth macros - there are other forth words to know
about like [ and ] and POSTPONE.  This page would have been a better
example for forth macrology:

http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Compiling-words.html




 
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <w4cu13igi35.fsf@boris.cd.chalmers.se>
"sajiimori" <··········@hotmail.com> writes:
> The reason I ask is because I intend to develop such a language if it's
> worth the effort.

Take a look at ThinLisp, before doing any major work.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Ng Pheng Siong
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bstcie$iv9$1@reader01.singnet.com.sg>
According to sajiimori <··········@hotmail.com>:
> ... (Think GameBoy Advance.) ... Explicit memory management would turn
> currently elegant code into bloated cludgery.

My impression of embedded systems programming is that you know up front how
much memory you'll want/get and that's that. 

Kinda like CMUCL allocating 2GB RAM upon startup and then not asking
anymore.


-- 
Ng Pheng Siong <····@netmemetic.com> 

http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
From: Tim Bradshaw
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <ey3oetpienx.fsf@lostwithiel.cley.com>
* sajiimori  wrote:
> But let's forget that for a moment and look at it from a different
> perspective:  If a language had all the features of Lisp (most notably the
> equivalence of code and data) except those which make it impractical for
> small systems (especially garbage collection), would it still be
> significantly more expressive than C?

Why do you think GC makes Lisp impractical for small systems?  Well,
clearly any non-manual memory management would be impractical for
*very* small systems - say those with writable memory measured in
hundreds of small thousands of bytes - but systems like that are
probably not realistic targets for a high-level language at all, being
better served by C or assembler.  But many `small' systems are now
much larger than that.  Automatic memory management, possibly
supplemented by various semi-manual things (which many Lisp
implementations already support) can be a perfectly reasonable
approach for systems like that: I don't think the memory footprint
needs to be significantly more than non-GCd systems, and the
performance can be very good.  My calculator runs a GCd system in (I
think) 128k of addressable space, possibly 64k!

--tim
From: Marc Battyani
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bsu6s7$8m3@library2.airnews.net>
"Tim Bradshaw" <···@cley.com>
>
> Why do you think GC makes Lisp impractical for small systems?  Well,
> clearly any non-manual memory management would be impractical for
> *very* small systems - say those with writable memory measured in
> hundreds of small thousands of bytes - but systems like that are
> probably not realistic targets for a high-level language at all, being
> better served by C or assembler.  But many `small' systems are now
> much larger than that.  Automatic memory management, possibly
> supplemented by various semi-manual things (which many Lisp
> implementations already support) can be a perfectly reasonable
> approach for systems like that: I don't think the memory footprint
> needs to be significantly more than non-GCd systems, and the
> performance can be very good.  My calculator runs a GCd system in (I
> think) 128k of addressable space, possibly 64k!
>

In the 80's there was several Lisp for the micro-computers of that time.
LeLisp for instance was running on TRS80 mod1(8-bit Z80 + 48K RAM)

Marc
From: Jeff Greif
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <MOyIb.242932$_M.1097991@attbi_s54>
You can have a Lisp without GC.  The penalty is that you have to do explicit
memory management.  You do not lose any other capabilities of Lisp.  This
includes having a compiler and interpreter, macroexpander, treating code as
data, etc.  It is non-trivial to produce such a Lisp.

In the mid-1980s, the Inference expert system shell ART, written in CL, was
made garbage-free as long as only the constructs of the ART language were
used (the implementation of everything supported by this language, including
objects, forward-and-backward chaining rules, truth maintenance,
hypothetical reasoning, etc) was garbage-free, using a home-grown Lisp
runtime system that we implemented several ways (atop Lisp machine Lisp
(Symbolics and TI), atop Lucid Lisp, and as a homebrew dC runtime system).
The garbage-freeness did not extend to arbitrary Lisp functions users might
write to implement actions outside the supported ones on the on the
right-hand-side of rules, although it was possible to write such functions,
but difficult even with a substantial amount of documentation.  It was also
considerably more effort for the implementors to write garbage-free code.
The purposes of this implementation were:

1.  To be able to support a system in which the entire ART and its
underlying Lisp were automatically translated into C and run on a system
with no GC.  Originally, the users were not supposed to write any Lisp
functions themselves, but rather link in C functions to the translated
system.
2.  To reduce the incidence of garbage-collection on regular lisps, both the
overhead of garbage collection and the times when the system would stop in
order to collect garbage, which made realtime expert systems untenable.

These efforts were not completely successful (particularly the C
implementation, where various serious technical and project management
mistakes were made), but they enormously reduced the impact of GC.  The
machines in question were of a few MB in size.

Note that besides the programming difficulties, it is not clear how much the
performance improved.  Typically really sloppy lisp code which generates
tons of unnecessary garbage would almost always run lots faster if written
garbage-free, but tight lisp code without much unnecessary consing might
well perform better with gc than with completely garbage-free facilities.
What you get for such a system is better predictability about GC's impact on
any particular operation (unlikely to have a GC make that operation take
orders of magnitude longer than usual).

Jeff


"sajiimori" <··········@hotmail.com> wrote in message
·························@newsread2.news.pas.earthlink.net...
> Note: I've only been using CL for a few weeks.
>
> This question is directed mostly toward experienced users of both Lisp and
> system-level or embedded C.  If you think that Lisp can be practical in
all
> cases where C is currently used, this thread is not for you.  (Think
GameBoy
> Advance.)
>
> Clearly, a Lisp without garbage collection is no Lisp at all.  Explicit
> memory management would turn currently elegant code into bloated cludgery.
> Previously simple tasks would become arduous and bug-prone.
>
> But let's forget that for a moment and look at it from a different
> perspective:  If a language had all the features of Lisp (most notably the
> equivalence of code and data) except those which make it impractical for
> small systems (especially garbage collection), would it still be
> significantly more expressive than C?
>
> The reason I ask is because I intend to develop such a language if it's
> worth the effort.
>
>
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bBEIb.14170$lo3.12370@newsread2.news.pas.earthlink.net>
Thanks for all your responses!

It seems like the overriding themes here are:

1)  Lisp doesn't have to be GCd. (I wonder how many posts repeated that?)

2)  GC is always better (except on systems with less than 1K of RAM).

3)  Lisp is always appropriate (except on systems with less than 1K of RAM).

Honestly, I was expecting at least one or two people say that while Lisp is
their favorite language, it's not appropriate for all applications.

How about this:  Raise your hand if you honestly believe it would have been
appropriate to use Common Lisp to write Doom 3 (assuming availability of
necessary API hooks).
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7xekukltge.fsf@ruckus.brouhaha.com>
"sajiimori" <··········@hotmail.com> writes:
> How about this:  Raise your hand if you honestly believe it would have been
> appropriate to use Common Lisp to write Doom 3 (assuming availability of
> necessary API hooks).

Sure, why not?  Doom 3 is a huge package distributed on cd-rom, IIRC.
The low level rendering code would have had to be in asm through an
FFI, just like it is now from the C code, but writing the game logic
in CL sounds perfectly workable.
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <3aFIb.14230$lo3.12041@newsread2.news.pas.earthlink.net>
"Paul Rubin" <·············@NOSPAM.invalid> wrote in message
···················@ruckus.brouhaha.com...
> "sajiimori" <··········@hotmail.com> writes:
> > How about this:  Raise your hand if you honestly believe it would have
been
> > appropriate to use Common Lisp to write Doom 3 (assuming availability of
> > necessary API hooks).
>
> Sure, why not?  Doom 3 is a huge package distributed on cd-rom, IIRC.
> The low level rendering code would have had to be in asm through an
> FFI, just like it is now from the C code, but writing the game logic
> in CL sounds perfectly workable.

The low-level rendering code is not necessarily in asm.  In fact, John
Carmack has consistently used *less* asm for each successive project, and if
you look at the source code for Quake 2, you will find lots of low-level
routines written in C, with some assembly specializations for particular
platforms.

Anyway, I didn't specify only game logic code.  I mean the engine and all.

To be specific:  Let's assume that JC has used the same approach, and that
none of the assembly specializations are applicable to our platform.  Would
it be appropriate to use CL in place of all C code?
From: Thomas F. Burdick
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <xcv65fwol7h.fsf@famine.OCF.Berkeley.EDU>
"sajiimori" <··········@hotmail.com> writes:

> "Paul Rubin" <·············@NOSPAM.invalid> wrote in message
> ···················@ruckus.brouhaha.com...
> > "sajiimori" <··········@hotmail.com> writes:
> > > How about this:  Raise your hand if you honestly believe it would have
> been
> > > appropriate to use Common Lisp to write Doom 3 (assuming availability of
> > > necessary API hooks).
> >
> > Sure, why not?  Doom 3 is a huge package distributed on cd-rom, IIRC.
> > The low level rendering code would have had to be in asm through an
> > FFI, just like it is now from the C code, but writing the game logic
> > in CL sounds perfectly workable.
> 
> The low-level rendering code is not necessarily in asm.  In fact, John
> Carmack has consistently used *less* asm for each successive project, and if
> you look at the source code for Quake 2, you will find lots of low-level
> routines written in C, with some assembly specializations for particular
> platforms.
> 
> Anyway, I didn't specify only game logic code.  I mean the engine and all.
> 
> To be specific:  Let's assume that JC has used the same approach, and that
> none of the assembly specializations are applicable to our platform.  Would
> it be appropriate to use CL in place of all C code?

Yes, why wouldn't it be?  You're starting to sound like a troll.  Have
you actually looked at what can be done with compilers like Python
(CMUCL/SBCL) or the one in Allegro?

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <%pFIb.14257$lo3.2907@newsread2.news.pas.earthlink.net>
> You're starting to sound like a troll.

Alright then, thread over.  Sorry if I offended anyone.
From: Thomas F. Burdick
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <xcv3cb0oiao.fsf@famine.OCF.Berkeley.EDU>
"sajiimori" <··········@hotmail.com> writes:

> > You're starting to sound like a troll.

(note the "starting")

> Alright then, thread over.  Sorry if I offended anyone.

I'm not offended, nor am I trying to scare you off, but I am a little
annoyed.  If you're interested in game programming, you should check
out the highest performance CL implementations, and that means one of
the Python based ones, or ACL.  You can download a free trial of
Allegro.  I know the LispNYC group had a bootable CD they were working
on that ran Linux and various CL systems, if you're interested in
checking out CMUCL without installing a Unix.

You sem convinced that there is some lack in Lisp that makes it
inappropriate for general use.  There isn't.  If some general-purpose
language X is appropriate for a certain task, Common Lisp almost
certainly is, too.  Lisp compilers are good.  For tasks where you need
a very low-level language, a custom Lisp dialect hosted on a CL system
is fairly easy to construct, and can *always* handle the task.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Ray Dillinger
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <3FF34BED.B507AE5A@sonic.net>
"Thomas F. Burdick" wrote:
 
> You sem convinced that there is some lack in Lisp that makes it
> inappropriate for general use.  There isn't.  If some general-purpose
> language X is appropriate for a certain task, Common Lisp almost
> certainly is, too.  Lisp compilers are good.  For tasks where you need
> a very low-level language, a custom Lisp dialect hosted on a CL system
> is fairly easy to construct, and can *always* handle the task.

Observation: Simple Lisp programs have a bigger memory footprint than 
C programs of similar complexity.  It's unclear how much of this is due
to system libraries not taking up space in C due to being linked through
shared objects.  It's also clear that as the problem gets more complicated,
the difference in memory footprint goes away.  

Once upon a time, Lisp programs ran slower than C programs; but that hasn't 
been true for some time now, because in the 80's they figured out compilers
for dynamically typed languages like Lisp. 

				Bear
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <k74c4mm6.fsf@comcast.net>
Ray Dillinger <····@sonic.net> writes:

> Observation:  Simple Lisp programs have a bigger memory footprint than 
> C programs of similar complexity.  

They only *seem* to.  The Lisp expression (+ a b) is *far* more
complicated than the C expression "a + b" despite the syntactic
similarities.

> Once upon a time, Lisp programs ran slower than C programs; but that hasn't 
> been true for some time now, because in the 80's they figured out compilers
> for dynamically typed languages like Lisp. 

They figured that out in the 60's, well before C existed. 

-- 
~jrm
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <ZmHIb.28630$Pg1.1277@newsread1.news.pas.earthlink.net>
> You seem convinced that there is some lack in Lisp that makes it
> inappropriate for general use.

And you seem intent on putting words in my mouth.

I had concerns about garbage collection, and those have been addressed
(answer: GC is generally not too taxing, but you can always control its
cycles or turn it off).

I had concerns about low-level features, and those have been addressed
(answer: use a good algorithm and the optimizer should do the rest).

Dynamic typing was never a concern because I knew about type declarations.

When I could no longer think of any major concerns off the top of my head, I
asked a question that I hoped would rustle up any other performance issues
that more experienced Lispers could think of.  Nobody had any.

Thus, thread over, lest I do veer into troll territory.
From: Thomas F. Burdick
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <xcvznd7mq3w.fsf@famine.OCF.Berkeley.EDU>
"sajiimori" <··········@hotmail.com> writes:

> > You seem convinced that there is some lack in Lisp that makes it
> > inappropriate for general use.
> 
> And you seem intent on putting words in my mouth.

 [...]

> When I could no longer think of any major concerns off the top of my head, I
> asked a question that I hoped would rustle up any other performance issues
> that more experienced Lispers could think of.

*cough* *cough*

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <cW%Ib.15209$lo3.5868@newsread2.news.pas.earthlink.net>
"Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote in message
····················@famine.OCF.Berkeley.EDU...
> "sajiimori" <··········@hotmail.com> writes:
>
> > > You seem convinced that there is some lack in Lisp that makes it
> > > inappropriate for general use.
> >
> > And you seem intent on putting words in my mouth.
>
>  [...]
>
> > When I could no longer think of any major concerns off the top of my
head, I
> > asked a question that I hoped would rustle up any other performance
issues
> > that more experienced Lispers could think of.
>
> *cough* *cough*

I'm not sure how you interpreted that sentence that would make it sound bad.
I didn't actually *hope* there were performance issues, nor did I assume
that there were any.  I only hoped that they would come to light if they
exist.

Anyway, this is getting old.  You can choose to believe me, or you can
choose to assume that I have some sort of bias against Lisp.  It's up to
you.
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <dxFIb.14263$lo3.1170@newsread2.news.pas.earthlink.net>
> Have you actually looked at what can be done with compilers like Python
> (CMUCL/SBCL) or the one in Allegro?

BTW, no, CMUCL and SBCL don't run on my platform, and Allegro is not free.
I am using CLISP.
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <r7yk65lu.fsf@comcast.net>
"sajiimori" <··········@hotmail.com> writes:

>> Have you actually looked at what can be done with compilers like Python
>> (CMUCL/SBCL) or the one in Allegro?
>
> BTW, no, CMUCL and SBCL don't run on my platform, 

Windows?  Try Corman.

> and Allegro is not free.

The `trial' edition is.


-- 
~jrm
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <V5IIb.28672$Pg1.12745@newsread1.news.pas.earthlink.net>
"Joe Marshall" <·············@comcast.net> wrote in message
·················@comcast.net...
> "sajiimori" <··········@hotmail.com> writes:
>
> >> Have you actually looked at what can be done with compilers like Python
> >> (CMUCL/SBCL) or the one in Allegro?
> >
> > BTW, no, CMUCL and SBCL don't run on my platform,
>
> Windows?  Try Corman.
>
> > and Allegro is not free.
>
> The `trial' edition is.
>
>
> -- 
> ~jrm

At first I thought Corman was time-limited like Allegro, but I just checked
again and I guess it's only the IDE that isn't free for non-commercial use.

I can live with that. :-)
From: Pascal Costanza
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bt05rt$84f$1@newsreader2.netcologne.de>
sajiimori wrote:

>>Have you actually looked at what can be done with compilers like Python
>>(CMUCL/SBCL) or the one in Allegro?
> 
> BTW, no, CMUCL and SBCL don't run on my platform, and Allegro is not free.
> I am using CLISP.

It would be more helpful if you could give some more information about 
what you are actually trying to do. Until now, AFAICT, you have only 
said that you have been using CL only for several weeks, and that you 
want to do "system-level" programming or "something embedded".

This sounds like you have certain implicit assumptions about how things 
should be done that you may or may not have learned from other 
languages. However, more often than not, things are approached in quite 
different ways in Lisp.

Therefore, instead of asking how to do certain specific things according 
to your anticipated solution it would be better to actually state what 
the problem is that you are trying to solve, so that people in this 
newsgroup can give you some better hints.

I hope this makes sense to you.


Pascal

BTW, happy new year.

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <UnRIb.29208$Pg1.6561@newsread1.news.pas.earthlink.net>
> It would be more helpful if you could give some more information about
> what you are actually trying to do.

I get where you're coming from, but I'm only out for information myself.  I
have no immediate problem to solve, and perhaps that causes some annoyance.
Some folks seem to feel cheated if they take the time to answer a question,
if their answer is not immediately applied to the development of a specific
project.

Is the proliferation of wisdom not a worthy end in itself?
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <w4cd6a3hqbx.fsf@boris.cd.chalmers.se>
"sajiimori" <··········@hotmail.com> writes:
> Is the proliferation of wisdom not a worthy end in itself?

You can't learn, only earn, wisdom. What you get from learning from
people who have gained such wisdom is prejudice.

That said, information inferred from answers to vague questions is,
when applied through the filters of the person asking the vague
question, at best still vague, at worst misleading.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <_HZIb.29485$Pg1.3390@newsread1.news.pas.earthlink.net>
> You can't learn, only earn, wisdom.

I was using the term very loosely.  I couldn't think of another word for
what you gain by discovering what other people think.

> That said, information inferred from answers to vague questions is,
> when applied through the filters of the person asking the vague
> question, at best still vague, at worst misleading.

Don't worry -- I'm not doing an empirical study here.  It's not like I'm
going to run off and publish my "findings" in a paper.  I'm just asking for
opinions.

But thanks for your concern.
From: Kenny Tilton
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <___Ib.75252$4F2.7312513@twister.nyc.rr.com>
sajiimori wrote:
>>You can't learn, only earn, wisdom.
> 
> 
> I was using the term very loosely.  I couldn't think of another word for
> what you gain by discovering what other people think.

"Vulcan mind meld"?

:)

kt
From: Pascal Costanza
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bt1tl7$9em$1@newsreader2.netcologne.de>
sajiimori wrote:

>>It would be more helpful if you could give some more information about
>>what you are actually trying to do.
> 
> 
> I get where you're coming from, but I'm only out for information myself.  I
> have no immediate problem to solve, and perhaps that causes some annoyance.
> Some folks seem to feel cheated if they take the time to answer a question,
> if their answer is not immediately applied to the development of a specific
> project.
> 
> Is the proliferation of wisdom not a worthy end in itself?

Sure, but it's really better to do so by programming in the language. I 
have once read a proverb: "You don't learn how to cook by studying 
recipe measures." (translated from German, might sound strange in 
English, but I hope you get the point ;)

The same holds for programming in a language.

There are several good tutorials out there, some of them even for free. 
You will find links at http://alu.cliki.net and at the various websites 
by commercial and free vendors. Those tutorials give you a good taste on 
what it is like to program in Lisp, and might give you good ideas about 
what you actually would want to program yourself.

Furthermore, don't worry too much about the choice of a free or 
commercial implementation, and whether it's fast enough. For example, 
CLISP is an interpreted implemetation but was chosen by Paul Graham for 
Yahoo Stores because it had one of the fastest stream implementations 
around, and this was by far more important than other factors. AFAIK, it 
has also one of the fastest numerical libraries for Common Lisp. So it 
depends a lot on what you actually want to program, and the interpreter 
vs. commercial issue is not necessarily among the most important ones.

What is really more important, at least in my experience, is whether you 
want to develop with emacs or with an IDE. (but this might be subjective)

You see, the impression I have from your postings is that you worry too 
much about the wrong issues, especially because you admit that you don't 
have any actual programming project at hand. I don't think people find 
it annoying that you ask questions out of the blue, but rather that you 
are presenting some implicit assumptions that sound like the usual 
prejudices against Lisp - you know, "it's slow", "all those silly 
parentheses", and so on. People are just a little irritated by these 
false but wide-spread beliefs, that's all. I don't think you are doing 
it consciously, but this makes it even more irritating, you see?


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Bob Coyne
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <3FF492A3.5E6B69A4@worldnet.att.net>
Pascal Costanza wrote:

> Furthermore, don't worry too much about the choice of a free or
> commercial implementation, and whether it's fast enough. For example,
> CLISP is an interpreted implemetation but was chosen by Paul Graham for
> Yahoo Stores because it had one of the fastest stream implementations
> around, and this was by far more important than other factors. AFAIK, it
> has also one of the fastest numerical libraries for Common Lisp. So it
> depends a lot on what you actually want to program, and the interpreter
> vs. commercial issue is not necessarily among the most important ones.

Maybe I've lost track of the question, but if it still has to do
with writing a 3d game in Lisp, I doubt CLISP would be the best
choice.  Almost any 3d game is going require high performance
floating point math and from what I know of CLISP, that's not
one of it's strengths.  I think Allegro, Lispworks or CMUCL would
be much better choices where floating point performance is important.

Also, to get the most out of any of the CL implementations, it's necessary
to put in the right declarations and take care about passing/returning floating
point numbers to functions (to avoid boxing). Packaging x,y,z coordinates into
arrays and passing those around is one way to avoid this problem.  Anyway, the
main thing to keep in mind writing 3d games or other 3d applications is that
performance will probably be iimportant and that will affect how the code is
written (and the choice of Lisp compiler).
From: Brian Downing
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <BL1Jb.710397$HS4.5073887@attbi_s01>
In article <·················@worldnet.att.net>,
Bob Coyne  <········@worldnet.att.net> wrote:
> Also, to get the most out of any of the CL implementations, it's
> necessary to put in the right declarations and take care about
> passing/returning floating point numbers to functions (to avoid
> boxing). Packaging x,y,z coordinates into arrays and passing those
> around is one way to avoid this problem.  Anyway, the main thing to
> keep in mind writing 3d games or other 3d applications is that
> performance will probably be iimportant and that will affect how the
> code is written (and the choice of Lisp compiler).

Is there any generational GC out there that is fast enough that you
could collect the nursery after every frame in a 3D environment, say at
60 Hz?  I know the current free implementations (in CMUCL and SBCL)
aren't currently up to this, but I'm not sure it's impossible.

This would seem to be a decent way to get both automatic memory
management and consistent time behavior (by making the pauses
incremental enough to not be noticed and hiding them in between the
screen refreshes).

-bcd
--
*** Brian Downing <bdowning at lavos dot net> 
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7xllorjl96.fsf@ruckus.brouhaha.com>
Brian Downing <·············@lavos.net> writes:
> Is there any generational GC out there that is fast enough that you
> could collect the nursery after every frame in a 3D environment, say at
> 60 Hz?  I know the current free implementations (in CMUCL and SBCL)
> aren't currently up to this, but I'm not sure it's impossible.

There are realtime GC algorithms with a guaranteed maximum latency and
cpu share, though they don't work quite the usual way.
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <n097qf5j.fsf@comcast.net>
Brian Downing <·············@lavos.net> writes:

> Is there any generational GC out there that is fast enough that you
> could collect the nursery after every frame in a 3D environment, say at
> 60 Hz?  

I think you could do this if you designed a custom GC.  I wrote an
interpreter once that used Baker's `Cheney on the MTA' technique.  The
stack is used as a nursery and it is recycled pretty quickly.  I'm
pretty sure it GC'd at better than 60hz.

-- 
~jrm
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <r7yjqg0f.fsf@comcast.net>
Bob Coyne <········@worldnet.att.net> writes:

> Maybe I've lost track of the question, but if it still has to do
> with writing a 3d game in Lisp, I doubt CLISP would be the best
> choice.  Almost any 3d game is going require high performance
> floating point math and from what I know of CLISP, that's not
> one of it's strengths.  

Any reason one couldn't use integers?

-- 
~jrm
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7xhdzfru1k.fsf@ruckus.brouhaha.com>
Joe Marshall <·············@comcast.net> writes:
> > Maybe I've lost track of the question, but if it still has to do
> > with writing a 3d game in Lisp, I doubt CLISP would be the best
> > choice.  Almost any 3d game is going require high performance
> > floating point math and from what I know of CLISP, that's not
> > one of it's strengths.  
> 
> Any reason one couldn't use integers?

I think you'd want to use a SSE-aware vector library through an FFI,
sort of like what Doom and other games do.
From: Rahul Jain
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <87k74browp.fsf@nyct.net>
Paul Rubin <·············@NOSPAM.invalid> writes:

> I think you'd want to use a SSE-aware vector library through an FFI,
> sort of like what Doom and other games do.

Christophe was working on this at some point for SBCL and SSE2. No FFI
needed. It is implemented as part of the compiler itself and the
assembly bits are written as vops.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Greg Menke
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <m34qvfhxvx.fsf@europa.pienet>
Joe Marshall <·············@comcast.net> writes:

> Bob Coyne <········@worldnet.att.net> writes:
> 
> > Maybe I've lost track of the question, but if it still has to do
> > with writing a 3d game in Lisp, I doubt CLISP would be the best
> > choice.  Almost any 3d game is going require high performance
> > floating point math and from what I know of CLISP, that's not
> > one of it's strengths.  
> 
> Any reason one couldn't use integers?

OpenGL wants to use floats for lots of things, but single precision
will do pretty well in general so you're not automatically forced into
double.

Floating point readily handles much of the wide range of exponents so
often seen in the physics models and graphics, albeit with the loss of
some accuracy.  32 bit ints can't handle the same range as easily, so
pretty soon you'll be into bignums and homebrew arithmetic to deal
with the exponents so at that point fp starts to look a whole lot more
attractive.

Gregm
From: Michael Hudson
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <m3pte2784p.fsf@pc150.maths.bris.ac.uk>
Joe Marshall <·············@comcast.net> writes:

> Bob Coyne <········@worldnet.att.net> writes:
> 
> > Maybe I've lost track of the question, but if it still has to do
> > with writing a 3d game in Lisp, I doubt CLISP would be the best
> > choice.  Almost any 3d game is going require high performance
> > floating point math and from what I know of CLISP, that's not
> > one of it's strengths.  
> 
> Any reason one couldn't use integers?

You want to take advantage of the superscalar nature of the chip
you're running on?

Cheers,
mwh

-- 
  It's actually a corruption of "starling".  They used to be carried.
  Since they weighed a full pound (hence the name), they had to be
  carried by two starlings in tandem, with a line between them.
                 -- Alan J Rosenthal explains "Pounds Sterling" on asr
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <d6a2rwqs.fsf@ccs.neu.edu>
Michael Hudson <···@python.net> writes:

> Joe Marshall <·············@comcast.net> writes:
>
>> Bob Coyne <········@worldnet.att.net> writes:
>> 
>> > Maybe I've lost track of the question, but if it still has to do
>> > with writing a 3d game in Lisp, I doubt CLISP would be the best
>> > choice.  Almost any 3d game is going require high performance
>> > floating point math and from what I know of CLISP, that's not
>> > one of it's strengths.  
>> 
>> Any reason one couldn't use integers?
>
> You want to take advantage of the superscalar nature of the chip
> you're running on?

I want to avoid using (and consing) floats where they are unnecessary.
The floating point unit is still slower than the integer unit (units)
and in any case one can offload a lot of the math to the graphics
processor.  Certainly floats are easier to use, but maybe integers are
possible.
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <ODmJb.31732$Pg1.17510@newsread1.news.pas.earthlink.net>
> I want to avoid using (and consing) floats where they are unnecessary.

Ideally, you wouldn't be consing anything, just allocating them on the stack
(do you guys call it "dynamic-extent"?).

> The floating point unit is still slower than the integer unit (units)

Depends on the CPU.  Athlons and P4s have multiple pipelined FP units, not
to mention SSE and 3DNow.

> and in any case one can offload a lot of the math to the graphics
> processor.

Of course -- it's normal to offload as much as possible.  But for most
games, the CPU still has its hands full, and it can even be the performance
bottleneck (as it usually is on my system when running newer games).

> Certainly floats are easier to use, but maybe integers are
> possible.

You can always emulate floats using integers, but why would anybody want to
when we have pipelined FP?  Floats have been the norm ever since Pentium 1.
Fixed-point math is really only used on systems like GameBoy Advance, where
there is no hardware support for floats.
From: Russell Wallace
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <40053203.155236650@news.eircom.net>
On Fri, 02 Jan 2004 14:11:55 -0500, Joe Marshall <···@ccs.neu.edu>
wrote:

>I want to avoid using (and consing) floats where they are unnecessary.
>The floating point unit is still slower than the integer unit (units)

Actually these days the floating point unit is usually faster than the
integer unit. (Though yes, you do want to be careful to choose a
compiler that can handle unboxed floats.)

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <lloaqr7v.fsf@ccs.neu.edu>
················@eircom.net (Russell Wallace) writes:

> On Fri, 02 Jan 2004 14:11:55 -0500, Joe Marshall <···@ccs.neu.edu>
> wrote:
>
>>I want to avoid using (and consing) floats where they are unnecessary.
>>The floating point unit is still slower than the integer unit (units)
>
> Actually these days the floating point unit is usually faster than the
> integer unit. (Though yes, you do want to be careful to choose a
> compiler that can handle unboxed floats.)

For throughput or round-trip?
From: Michael Hudson
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <m3llo9v2hi.fsf@pc150.maths.bris.ac.uk>
Joe Marshall <···@ccs.neu.edu> writes:

> ················@eircom.net (Russell Wallace) writes:
> 
> > On Fri, 02 Jan 2004 14:11:55 -0500, Joe Marshall <···@ccs.neu.edu>
> > wrote:
> >
> >>I want to avoid using (and consing) floats where they are unnecessary.
> >>The floating point unit is still slower than the integer unit (units)
> >
> > Actually these days the floating point unit is usually faster than the
> > integer unit. (Though yes, you do want to be careful to choose a
> > compiler that can handle unboxed floats.)
> 
> For throughput or round-trip?

For the only CPU I've ever bothered to look this sort of thing up for
(the MPC750CX aka G3 in my ibook) I think the FPU and integer unit can
retire one instruction each per clock, but the integer instructions
all take less cycles than the corresponding floating point
instruction.

It seems unlikely to me that any modern CPU will be able to retire
more FPU than integer instructions per clock (consider the P4: *each*
integer unit can retire *two* instructions per clock), and even less
likely that FPU instructions will take less cycles than integer.  But
I'm hardly an expert in this area.

Of course, all applications are likely to be working the integer unit
somewhat, so you may get overall better performace by utilizing the
FPU.

Was this relavent to anything?

Cheers,
mwh

-- 
  My hat is lined with tinfoil for protection in the unlikely event
  that the droid gets his PowerPoint presentation working.
                               -- Alan W. Frame, alt.sysadmin.recovery
From: Russell Wallace
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <4006b84b.255163879@news.eircom.net>
On Thu, 15 Jan 2004 12:08:10 GMT, Michael Hudson <···@python.net>
wrote:

>It seems unlikely to me that any modern CPU will be able to retire
>more FPU than integer instructions per clock (consider the P4: *each*
>integer unit can retire *two* instructions per clock)

For an extreme example, consider the Playstation 2's CPU, which per
clock can retire something like one or two integer operations, and
*twenty* floating point operations.

>and even less
>likely that FPU instructions will take less cycles than integer.

There's one chip (trying to remember which - maybe the Pentium 4?)
which does integer multiply by shipping the operands across the chip
to the floating point multiply unit and back again.

>But
>I'm hardly an expert in this area.

Me neither; ask on comp.arch if you want an expert opinion.

>Of course, all applications are likely to be working the integer unit
>somewhat, so you may get overall better performace by utilizing the
>FPU.

Yep.

>Was this relavent to anything?

I forget :)

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Russell Wallace
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <4006b7db.255052045@news.eircom.net>
On Wed, 14 Jan 2004 14:12:52 -0500, Joe Marshall <···@ccs.neu.edu>
wrote:

>················@eircom.net (Russell Wallace) writes:
>
>> Actually these days the floating point unit is usually faster than the
>> integer unit. (Though yes, you do want to be careful to choose a
>> compiler that can handle unboxed floats.)
>
>For throughput or round-trip?

Usually for throughput and sometimes for latency (assuming that's what
you mean by round-trip).

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <vfnw65pp.fsf@comcast.net>
"sajiimori" <··········@hotmail.com> writes:

> Anyway, I didn't specify only game logic code.  I mean the engine and all.
>
> To be specific:  Let's assume that JC has used the same approach, and that
> none of the assembly specializations are applicable to our platform.  Would
> it be appropriate to use CL in place of all C code?

All other things being equal, certainly.

-- 
~jrm
From: Kenny Tilton
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <t7FIb.72478$4F2.6883678@twister.nyc.rr.com>
sajiimori wrote:
> How about this:  Raise your hand if you honestly believe it would have been
> appropriate to use Common Lisp to write Doom 3 (assuming availability of
> necessary API hooks).

Please clarify how (you seem to think) CL would be inappropriate? Are 
you thinking using CL means /not/ using OpenGL or a scene graph engine?

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <5cFIb.14233$lo3.1672@newsread2.news.pas.earthlink.net>
> sajiimori wrote:
> > How about this:  Raise your hand if you honestly believe it would have
been
> > appropriate to use Common Lisp to write Doom 3 (assuming availability of
> > necessary API hooks).
>
> Please clarify how (you seem to think) CL would be inappropriate? Are
> you thinking using CL means /not/ using OpenGL or a scene graph engine?

Of course not.  Anyway, I'm not making any positive claim here.  I don't
have enough experience with CL to do that.
From: Kenny Tilton
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bpFIb.72479$4F2.6891546@twister.nyc.rr.com>
sajiimori wrote:
>>sajiimori wrote:
>>
>>>How about this:  Raise your hand if you honestly believe it would have
> 
> been
> 
>>>appropriate to use Common Lisp to write Doom 3 (assuming availability of
>>>necessary API hooks).
>>
>>Please clarify how (you seem to think) CL would be inappropriate? Are
>>you thinking using CL means /not/ using OpenGL or a scene graph engine?
> 
> 
> Of course not.  Anyway, I'm not making any positive claim here.  I don't
> have enough experience with CL to do that.

Well then why would it not be appropriate to use CL? CL is very good at 
a very long list of things including speed, so the default answer is to 
raise my hand, but your question is specifically about Doom 3, so I 
think the burden is on you to clarify your question in terms of Doom 3 
requirements. You do not know CL, I do not know Doom 3 internals (or 
externals, come to think of it, tho IIRC it is first-person shooter or 
whatever they call it). This should not require knowledge of CL, just 
Doom 3.

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <isjw657y.fsf@comcast.net>
"sajiimori" <··········@hotmail.com> writes:

> Anyway, I'm not making any positive claim here.  I don't have enough
> experience with CL to do that.

Then I suggest that you do!  

Also, when you come across something that doesn't seem to be working,
feel free to ask here.  The people here are quite helpful if you have
actual code (they can get rather testy if all you have are questions).

-- 
~jrm
From: David Golden
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <DvFIb.2687$HR.6465@news.indigo.ie>
sajiimori wrote:

>
> 
> How about this:  Raise your hand if you honestly believe it would have
> been appropriate to use Common Lisp to write Doom 3 (assuming availability
> of necessary API hooks).

I'm old enough to remember the days when not-so-forward-thinking people
tutted at people writing action games in C instead of assembly...

Having been playing vaguely with cl-sdl for the past while, I'd say lisp
is fast becoming appropriate for nearly all aspects of high-end games.

Don't forget, people upgrade their computers just to play games like the
newest Dooms and Quakes, so a sufficiently compelling game for the PC
doesn't need to be extremely tightly written. And anyway, commodity
hardware capabilities are just amazing these days and eat any slack
(probably mostly a 3000fold increase or so in most areas since I started in
computing back in the 8-bit days, though CPU<->RAM bandwidth + latency
haven't quite kept pace with the rest of the increases, tragically...). 

In my own tests, the point for me where [modern, native-compiled common-]
lisp becomes eminently suitable for 3D game development and any
inefficiencies (that mainly stem from programmer laziness, BTW - it is
POSSIBLE to write tight code in lisp that doesn't result in wild GC
activity, if you can be arsed...) are swallowed by sheer speed on x86 is 1
GHz + a middling radeon (about half the spec of my present system, and well
below the modern hard-core gamer trendsetter that drives the industry). 

Now, I'm assuming someone who knows modern lisp a bit better than a newbie
but after all Carmack etc. know C and C++ and OpenGL rather better than the
average C newbie, too.

Perhaps you should learn a little more modern lisp :-)
From: Pascal Costanza
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bsv5sr$k7u$1@newsreader2.netcologne.de>
sajiimori wrote:

> Honestly, I was expecting at least one or two people say that while Lisp is
> their favorite language, it's not appropriate for all applications.

The important point to note here is that Lisp is not so much a language, 
but rather a language framework for building you own domain-specific 
languages. At least, that's one of the approaches usually taken when 
programming in Lisp.

Therefore, it's indeed hard to find a domain in which Lisp cannot 
successfully be used. One approach, for example, is to use a full-blown 
Common Lisp IDE to develop an application but then to use code 
generators that produce code for a limited deployment environment from 
the same sources. I think ECL is a good example of a CL implementation 
that generates C sources from Lisp.

Among my standard recommendations are the following papers: Paul Graham, 
"The Roots of Lisp", at http://www.paulgraham.com/rootsoflisp.html - Guy 
Steele and Gerald Sussman, "The Art of the Interpreter", at 
http://library.readscheme.org/page1.html - and then the chapters on 
macro programming in Paul Graham's "On Lisp" at 
http://www.paulgraham.com/onlisp.html

> How about this:  Raise your hand if you honestly believe it would have been
> appropriate to use Common Lisp to write Doom 3 (assuming availability of
> necessary API hooks).

Given the fact that it is already used for computer games?


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Wade Humeniuk
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <MvGIb.105103$ss5.97274@clgrps13>
sajiimori wrote:

> How about this:  Raise your hand if you honestly believe it would have been
> appropriate to use Common Lisp to write Doom 3 (assuming availability of
> necessary API hooks).
> 


I think your major concern is with GC, probably that an app in this
case Doom 3 will pause at some critical section.  I do not think there is
any issue that has to do with performance as much of the hard real time
stuff is on the graphics cards and drivers of the time.  The simple
answer is that some thought would have to be given when to do (or
allow) GC.  This is under control of the developer and is only limited
by a developer's skill.  Programming is still not a the stage where
a high performance app like Doom 3 can be "just coded" without a deep
understanding of _all_ of the system.  Using CL would just change the
focus where most of the attention is needed.

Is it appropriate?  Hmm..., I would have to answer, it depends (maybe).

Wade
From: Paul Rubin
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <7xllos67d6.fsf@ruckus.brouhaha.com>
Wade Humeniuk <········@delete-this-antispam-device.telus.net> writes:
> I think your major concern is with GC, probably that an app in this
> case Doom 3 will pause at some critical section.  I do not think there is
> any issue that has to do with performance as much of the hard real time
> stuff is on the graphics cards and drivers of the time. 

It's pretty common in video games to cons up structure on any given
game level without making any real attempt to manage the memory or GC
anything.  When the user finishes that game level, the game just wipes
out the whole heap and starts fresh at the next level.  There's just a
little bit of state that has to stay around from level to level (like
what gun the player is using or something like that) and that's kept
in a static area and also not GC'd.  Doom 3 could possibly be written
like that.
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <znd865wu.fsf@comcast.net>
"sajiimori" <··········@hotmail.com> writes:

> How about this:  Raise your hand if you honestly believe it would have been
> appropriate to use Common Lisp to write Doom 3 (assuming availability of
> necessary API hooks).

<hand goes up>

It is what *I* would have done (assuming everything else was equal).



-- 
~jrm
From: Joe Marshall
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <n09865bl.fsf@comcast.net>
"sajiimori" <··········@hotmail.com> writes:

> Honestly, I was expecting at least one or two people say that while Lisp is
> their favorite language, it's not appropriate for all applications.

Lisp is my favorite language.  I have written things as low level as
page-fault handlers and as high-level as inference engines in Lisp.
Although I have come across situations that dictated uses of other
languages, it was *never* because of the merits of the language
itself.

-- 
~jrm
From: jan
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <u65fut112.fsf@iprimus.com.au>
"sajiimori" <··········@hotmail.com> writes:

> How about this: Raise your hand if you honestly believe it would
> have been appropriate to use Common Lisp to write Doom 3 (assuming
> availability of necessary API hooks).

Games aren't cpu bound these days. The critical code for Doom 3 will
run on the GPU and will be written in GLslang*, which is compiled by
the OpenGL drivers. So any performance hit for using CL probably wont
be significant, on the other hand, CL does have significant advantages
over C++ for developing games.



* GLslang is the shader language that is part of the OpenGL 2 spec.
It's very C like with the addition of some types like matrices and
vectors and various other domain specific enhancements.
see  http://www.3dlabs.com/support/developer/ogl2/index.htm

-- 
jan
From: David Golden
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <Kz6Jb.2848$HR.6763@news.indigo.ie>
jan wrote:

> 
> * GLslang is the shader language that is part of the OpenGL 2 spec.
> It's very C like with the addition of some types like matrices and
> vectors and various other domain specific enhancements.
> see  http://www.3dlabs.com/support/developer/ogl2/index.htm
> 


Actually, that raises a point - future opengl lisp bindings might need
an sexpification of shader languages if such a thing makes sense ?
From: sajiimori
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <%mnJb.31818$Pg1.13558@newsread1.news.pas.earthlink.net>
As an aside, Doom 3 is indeed CPU bound on my PC (don't ask).

And hey, when it comes down to it, a 5% difference in CPU-targeted-code
efficiency means a 5% difference in CPU requirements.  (It's currently
expected to require a 1GHz CPU.)

Before anyone flips their lid over the 5% example, notice that I didn't even
specify what direction the difference goes. ^_^
From: Will Hartung
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <bt56qi$3faf0$1@ID-197644.news.uni-berlin.de>
"sajiimori" <··········@hotmail.com> wrote in message
··························@newsread1.news.pas.earthlink.net...
> As an aside, Doom 3 is indeed CPU bound on my PC (don't ask).
>
> And hey, when it comes down to it, a 5% difference in CPU-targeted-code
> efficiency means a 5% difference in CPU requirements.  (It's currently
> expected to require a 1GHz CPU.)
>
> Before anyone flips their lid over the 5% example, notice that I didn't
even
> specify what direction the difference goes. ^_^

Either way, this seems to have boiled down into a generic Lisp performance
thread vs a Lisp w/o GC thread.

C/C++ is more popular for gaming now more so because it has a large body of
understanding on how it behaves with regard to performance, rather than
necesarily being more performant for a given task.

The bare-metal coding necessary for many games for performance would end up
being similar regardless of the language involved, at least algorithmicly
(sp?) because it tends to be tied very close to the architecture of the
platform and makes any compromises over a conceptual alogorithmic ideal
towards the indiosyncratic platform dependencies.

Of course, Lisp can more easily abstract even such dependent, low level code
through its macro facility more so than C/C++ can, I feel.

The compiler vendors understand their respective systems well enough to give
the pointers and other tweaks necessary to get something like a Doom 3
project as close to the metal as required.

For example, Xanalys, makers of LispWorks, (I understand) has lots of
expertise in GC technology, both inside their system, and just from a
conceptual point of view. I'm sure they'd be happy to contract their
expertise to your project if GC is your concern.

Or, if you have specific optimizations that you'd like to see implemented in
a Lisp system, no doubt the folks at Corman or Franz would love to help you
out by adding them to their system.

I hear of all sorts of high end game projects that wrap a scripting language
around their core engine to actually write their game. Python, Java,
JavaScript, HomeMadeScript, etc. But I assert that you can do MORE in a
modern CL environment, and push that high level envelope deeper into your
core system, and therefor have less low level code to deal with in the long
term than you can by simply wrapping a scripting language around your core.

Because those scripting languages will always punish you on performance
compared to compiled CL, and they become more just a glue language of system
components.

I feel you'll also be able to use more of your prototypical code written in
CL directly in the final project, with tuning, than if you used one of these
scripting languages to prototype and then have to completely rewrite it to
get it performant.

Going the CL route WILL be more work, simply because there isn't a published
body of knowledge already charting the path to performance and integration
in the environment. I'm sure there are several sites on the web that will
tell you how to write GCC code or MS code to get it to compile "correctly"
compared to CL. Many projects end up writing their own memory allocators to
get around the problems with standard malloc() and free() (neither of which
is necessarily "pause-less").

But, once you get over that hurdle of understanding, and perhaps wrap up
some nice, higher level macrology to make it more useable, you'll eventually
be writing in straight CL and we'll be able to do more, more quickly, than
if you were writing in something else.

The CL vendors are VERY interested in performant, efficient CL projects.
They are motivated to making projects like this work, because they'd love to
have more projects like this work. Of course, the free CL implementations
are very interested as well, they simply don't have the resources to
dedicate to the effort. I'll bet lots of bits of CMUCL can get fixed if you
hired one of the current CMUCL-Python compiler hackers on to the project,
even to the point of adding specific, game specific bits to the compiler,
solely for this task.

Who wouldn't want the tag line "Used for the smash hit 'Doom 3' and for the
neo-sentinent control system on the ISS" in their glossy magazine ads?

But then you think "But that is so much work!". Of course it is, and truth
is, the work needs to be done ANYWAY. If whatever compiler you end up using,
for whatever language, isn't up to snuff for the task, you need to work
around it no matter what. If their memory allocator isn't up to task, you
have to write your own. So, you might as well use a language that makes even
that part less painful.

Regards,

Will Hartung
(·····@msoft.com)
From: Paolo Amoroso
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <87znd71slx.fsf@plato.moon.paoloamoroso.it>
sajiimori writes:

> The reason I ask is because I intend to develop such a language if it's
> worth the effort.

If you are insterested in existing options, you might consider the
Common Lisp implementations ThinLisp and Movitz.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Pascal Bourguignon
Subject: Re: Lisp w/out GC
Date: 
Message-ID: <87d69kutkc.fsf@thalassa.informatimago.com>
"sajiimori" <··········@hotmail.com> writes:

> Note: I've only been using CL for a few weeks.
> 
> This question is directed mostly toward experienced users of both Lisp and
> system-level or embedded C.  If you think that Lisp can be practical in all
> cases where C is currently used, this thread is not for you.  (Think GameBoy
> Advance.)
> 
> Clearly, a Lisp without garbage collection is no Lisp at all.  Explicit
> memory management would turn currently elegant code into bloated cludgery.
> Previously simple tasks would become arduous and bug-prone.
> 
> But let's forget that for a moment and look at it from a different
> perspective:  If a language had all the features of Lisp (most notably the
> equivalence of code and data) except those which make it impractical for
> small systems (especially garbage collection), would it still be
> significantly more expressive than C?
> 
> The reason I ask is because I intend to develop such a language if it's
> worth the effort.
 

You could as well program in C without ever call free().

I've seen a lot of C tools and servers doing just that and counting on
the use of fork/exit to collect the garbage.


What's the purpose?  Garbage collectors don't seem so difficult to write.


-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/