🚀 go-pugleaf

   Date: Mon, 14 Sep 92 10:33:40 -0400
   From: kanderso@BBN.COM
     ...

     A general philosophical point is in order, however: The traditional
     problem of Lisp systems has been creating minimal applications.
     Carrying around lots of extra baggage such as optimizing code,
     compilers, and interpreters just continues this negative aspect.  The
     problem that we should be attacking in designing modern Lisps is the
     ability to create small, efficient applications which do not require
     enormous complexity to implement.  I think this is the major general
     complaint against Common Lisp and CLOS + MOP.  (Of course, there are
     any number of problems with specific language aspects due to
     featurosity accretion.)

   You can certainly blame Lisp for being big, but you can also blame your
   operating system.  For example, a lot of your extra baggage could be shared
   among all your applications.  While this happens on Lisp machines, it does
   not happen, yet on UNIX machines.

Well, Le-Lisp v. 16 uses dynamic librairies for all module loading.
However, dynamic librairies only allow you to share code between
applications.  There is no good way of sharing data, which takes up
the lion's share of space in Lisp.

It could be that many operating systems don't support Lisp well
enough, but blaming others doesn't help anything.  The fact is, we are
stuck with Unix (and MS-DOS, and Windows, and NT, and even VMS) and if
Lisp wants to compete, it must work in these environments and not some
fantasy world.  Lisp must adapt, because the world won't.

   What would you leave out of CLOS and the MOP?

In November, Harry Bretthauer, Juergen Kopp, Keith Playford, and I are
presenting a paper in the IMSA conference which discusses the design
philosophy of the EuLisp MOP and some of the differences it has with
TELOS (TELOS is The EuLisp Object System).  It is not so much a
question of what we have left out of CLOS and the MOP, but where we
put various aspects.  For example, TELOS does much at load time that
CLOS does at runtime.  Even better would be to do more at compile
time.  TELOS also relegates certain rarely used but expensive features
of CLOS to library modules, simplifying in a trivial way the creation
of smaller applications.  For example, CHANGE-CLASS and EQL methods
are not directly supported by the TELOS kernel.

     Scheme has solved the problem to some extent, but the price is a
     language which many Lisp users would consider lacking in utility.

     EuLisp and Le-Lisp version 16 try to solve this problem by adding
     module systems and eliminating the guaranteed runtime mapping of all
     symbols to functions/values, along with some other improvements.

	Also, I'm not sure how your point about functions is related to
	dispatch optimization, but many unwanted runtime bindings between
	names and functions could be eliminated with some combination of
	unintern and setf of fdefinition.  (Not so for common-lisp package
	functions, of course.)

     If you accept that I was talking about a different kind of
     optimization than you, it should be clear that the points are related:
     both the fully extensible MOP and the guaranteed runtime name/function
     binding make it difficult to create small applications.

   Why?  I can imagine a delivery strategy where the MOP could be
   quite useful in delivering smaller applications.  For example, once
   you are willing to crystalize your application by doing a DISKSAVE
   or whatever, CLOS has as much knowledge about your program as C++
   does.  Simply by loading the appropriate metaclasses, and
   recompiling your software, you could have a more compact, efficient
   application.  This would be better than having a bunch of compiler
   switches because it makes things more user accessable.

You didn't understand what I wrote.  The fact is that CommonLisp does
not allow this sort of operation because all symbols and their
function/dynamic variable bindings are accessible at runtime.  This is
part of the definition of the language, and application generators
cannot ignore this aspect without violating the specification.  This
is the case only for CommonLisp.  I completely agree that Lisp needs
the kind of capability you are talking about, and it is one of the
primary motivations for the design of EuLisp.

A MOP could be a good vehicle for this kind of description, but CLOS's
MOP is not that kind of MOP.  There are no facilities described in
CLOS or AMOP for this kind of description. The fact that no CommonLisp
implementor has come up with a reasonable way to make small
applications using the MOP is evidence that it is difficult or
impossible to do in CommonLisp.

I also think there is something indicative in your statement that at a
certain point you should "crystallize your application by doing a
DISKSAVE or whatever".  This idea that the state of memory somehow is
the best representation of your application is deadly in today's
computing environments.  As I said, we must integrate Lisp into
existing environments, and one of the fundamental principles of
program development in traditional OS's is that your code (statically
known) plus a static program description (eg a Makefile) constitutes
your application.  If you stray too far from this simple (and
admittedly frustratingly limited) model, you are bound to end up in
trouble.  Lisp has fought an uphill battle in the conventional world
because Lisp program development has been seen as incremental
modification of the state of the Lisp image.

I'm afraid that if Lisp is to survive, we Lisp programmers must
abandon our traditional way of working and adapt.  One possible way of
adapting is, as you state below, to write sophisticated development
environments like those now found in the C++ world in which the
application is completely separate from the development environment,
and debugging happens via interprocess procedure calls.  I think this
strategy could be successfully adopted by Lisp without giving up too
much.  However, I don't see this happening with CommonLisp.

   Now your application may still be big because of other Lisp
   baggage, but not because of the MOP.  Lucid's Energize environment
   for C++ development provides a clean separation betweeen powerful
   development tools, and compact delivery.  If we had a Lisp that
   could make that same separations, i don't see why it wouldn't fit
   quite well into the constraints of some "modern" operating system.

I heartily agree, but that Lisp is not CommonLisp.  EuLisp and Le-Lisp
v16 are steps in the right direction.

-- Harley Davis

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France