gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] conditions/clos/gcl unified build patch and instruct


From: Thomas F. Burdick
Subject: Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions.
Date: Fri, 7 Jun 2002 12:56:03 -0700 (PDT)

Camm Maguire writes:

 > I really need some intelligent commentary here from people wanting to
 > make real use of gcl, if any.  From my own limited perspective, I
 > cannot see how lisp could ever be used for anything *simple* if each
 > binary will be at least 8 meg.  This would seem to limit gcl to large
 > maxima-sized projects.  Not to mention using these programs in a
 > multi-user environment.

Well, if you ship a core plus compiled lisp files, the same core can
be used for many programs.  An 8 Mo dependency for *one* small program
might be a bit much, but if someone were to start writing small, free
systems in Lisp, I assume they'd write more than one.  As it is, you
could make a small program in Lisp, and make a Debian package of it
that requires the gcl package, and just have your application load its
fasl files into the gcl image.  It'll be a bit slower to load than a
custom image, but this is generally how Unix works nowadays --
libraries that are linked-in dynamically.

 > It seems that lisp started out assuming that it was the entire OS
 > for a single user, or something.

Well, this is how Lisp Machines worked.  But that's not how all lisp
systems work/worked.  As far as I know, MACLISP expected each user to
be running an image, and I /know/ that's how CMUCL works and worked.

 > I've never understood this -- perhaps someone could enlighten me.
 > At very least, as much as possible of this image should be in a
 > shared lib, no?

Right, the way modern Unixes work, if you already have one user
running the lisp image, additional users running it come essentially
for free.  It might be worthwhile to break the standard library into
pieces (like streams, maths, CLOS, formatted i/o, etc) that can be
loaded on use.  That way, a simple string-munging utility, for
example, will only link to the base core and some of the fasl's, but
there's no need for even one copy of CLOS to be loaded into memory.

This is the approach we're taking on the CMUCL-derived proprietary
system I'm working on.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



reply via email to

[Prev in Thread] Current Thread [Next in Thread]