C as Universal Standard

[barmar@Think.COM (Barry Margolin)]

   Date: Fri, 18 Jan 91 19:34:04 -0800
   From: magerman@Neon.Stanford.EDU

   But C bashing is going too far.  In many ways, C is a much more powerful
   language than common-lisp.  I can think of many non-trivial applications
   that require number-crunching, text searching and sorting, and/or massive I/O
   that can't afford to wait for garbage collection or consing of any sort:

	   Computer vision (although I am not an expert)

Hmm, we've been doing vision work in *Lisp for years.

	   Statistical Models for Natural Language

I'm not sure what this is (as opposed to other forms of Natural Language
research).

	   Regular expression search (a la grep)

Lisp is a natural for this!  Translate the regular expression into a Lisp
expression, compile it, and then call it.  Or implement it as an FSM, where
the states are implemented as alists mapping events to a function to call
and a new state.

	   Any application associated with loading large data sets into a
		   connection machine without a data vault

Huh?  Yes, there's a bug in our Lucid interface to the CMFS library, that
causes excessive array allocation for networked CM file servers.  This
should hardly be used to indict Lisp in general.

   There are many situations where you want to have control over the way memory
   is allocated and where in memory things get written.  In the case of large
   data sets, you frequently want to allocate memory in such a way that data
   objects that will be compared or used together will be close together (i.e.
   on the same page) in memory.  Otherwise your OS goes crazy.  This type of
   situation (IMHO) *demands* C programming.

How do you guarantee that two objects will be on the same page in C?  The
best you can do is guarantee that they'll be close together, by allocating
one big array and then carving it up yourself.

   Lisp is great for writing very clear, concise code.  But when clear, concise
   code causes your OS to thrash on large data sets, it's time to recode the
   algorithm in C.  IMHO, it is precisely the non-trivial problems that
   eventually need to be written in C.

If you don't mind writing less clear code, you can do what you want in
Lisp.  All the Common Lisps I'm familiar with implement the elements of
unsigned-byte (with a byte size up to 32) arrays as immediate data, so no
pointer chasing is done.  So, you can make a big array, and then carve it
up into small arrays (perhaps using indirect arrays, if you don't mind
allocating a few extra objects) in Common Lisp.  Of course, the elements of
this array can't be arbitrary objects, they can only be positive integers,
but you can write macros and functions to build some more complex data
structures out of them.