Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!EU.net!news2.EUnet.fr!news.fnet.fr!ilog!news
From: haible@laplace.ilog (Bruno Haible)
Subject: Re: Why is Lisp not more widely used?
In-Reply-To: Blake McBride's message of 17 Aug 1995 18:53:04 GMT
Message-ID: <HAIBLE.95Aug21190152@laplace.ilog>
Lines: 63
Sender: news@ilog.fr
Nntp-Posting-Host: laplace
Organization: ILOG S.A., Gentilly, France
References: <40j8lv$l5j@geraldo.cc.utexas.edu> <40ng4k$kg8@excalibur.edge.net>
	<19950817.131530.57@arcangel.demon.co.uk>
	<41036g$40r@excalibur.edge.net>
Date: 21 Aug 1995 17:01:52 GMT

Blake McBride <blake@edge.net> writes:

   I don't know or really care which compiler you
   use but I can assure you they use macros with missing arguments in
   many, many places.  This is not ANSI C.  I can not speak about what
   compilers do or do not support this *feature*.  If the thing works
   on your machine than obviously your compiler definitly supports the
   feature, period.

Yes, the CLISP source use this kind of C feature. For those C compilers
which don't support it, the Makefile gets a little bit more complicated
by the use of  "sed -e 's/,)/,__EMPTY_MACRO_ARGUMENT__)/g'"  commands.
It is not worth talking about.


   Oh, I don't doubt that they will insert an ifdef or two.  That's not the
   problem.  The problem has to do with fundemental design issues which
   were chosen not out of necessity, but out of disregard for anything
   but academic environments (although I understand that they certainly
   have this right).

You are alluding to three design decisions in CLISP:

- To write half of CLISP in C, and rely on existing C compilers (ANSI C
  or C++ compilers are not required). Some other Lisp's ability to be widely
  used is suffering from the fact they are written in 8086 or 68k assembly
  language.

- To write the entire bytecode interpreter as a single C function.
  This is your "functions so large" complaint. It did hurt me with
  Turbo C 2.0 three years ago because this compiler could not compile
  functions with more than 32 KB object code. Please tell us, did you
  encounter a similar limitation with Microsoft C?

- To implement the arithmetic and number system as a single compilation unit,
  about 950 KB C code. This was done because a lot of subroutines are
  realized as macros (similar to inline functions), for efficiency.
  When this is compiled using WATCOM C (9.5 or 10.0) the C compiler reports
  an "internal table overflow" because it cannot handle more than 108 KB
  object code per compilation, and suggests splitting the module.

And, no, the CLISP maintainers will not revise these design decisions.

Peter Burwood <pjb@arcangel.demon.co.uk> writes:

   I don't like speculating, but it is starting to sound like you wanted
   Bruno to split the source into smaller modules and functions and he
   refused. Maybe I'm wrong, and I suspect there is more to it, but if not,
   then I repeat - get a decent compiler.

That's exactly what Blake McBride wanted me to do, and I refused and
suggested complaining at WATCOM.


Similarly, when your text editor says it cannot handle text files larger
than 64 KB, will you split your files or will you choose another text
editor? I would choose another text editor.

                Bruno


Bruno Haible                                     email: <haible@ilog.fr>
Software Engineer                                phone: +33-1-49083585
