Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: The powerlessness of Lisp
Message-ID: <1991Mar28.064405.13664@Think.COM>
Date: 28 Mar 91 06:44:05 GMT
References: <16060:Mar2515:41:5691@kramden.acf.nyu.edu> <1991Mar26.165516.13035@daffy.cs.wisc.edu> <26146:Mar2804:56:5791@kramden.acf.nyu.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 70

In article <26146:Mar2804:56:5791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <1991Mar26.165516.13035@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
>> Byte copying is trivial in Common Lisp.
>So translate *(int *)&buf = n; into Lisp. Here char *buf; int n.

Assuming buf was created with

(defvar buf (make-string <size>))

and <size> is large enough to hold a fixnum:

(let ((temp (make-array () :element-type 'fixnum :displaced-to buf)))
  (declare (dynamic-extent temp))
  (setf (aref temp) n))

Note, however, that this is not portable, but I'm not sure the original C
code was, either.

>> A typical
>> "portable" C program running on n different platforms is usually n different
>> programs selected by conditional compilation via #ifdef's.
>
>What a load of crap. My latest compressor, for example, has so far been
>reported to work on platforms from about fifty vendors. Four of the
>configuration options enable optimizations that depend on available
>libraries. One enables extra code to handle a common stdio bug in older
>systems. Four set defaults for user options. The rest select between
>machine-independent optimizations. There aren't any #ifdefs other than
>the configuration options. This is hardly atypical of C programs.

Yes, it's quite possible to write such code.  I'll bet pty is loaded with
system-dependency #ifdef's, though.  My guess is that the C world is
probably split about even between those two classes of programs.

>> Emacs is written in elisp.
>
>What a(nother) load of crap. Next Doug will be claim that sh, csh, and
>ksh are written not in C, but in shell code! After all, the vast
>majority of code that people use while executing the shell is, indeed,
>in an interpreted language, even if under the scenes there's that dirty
>C code actually running and doing all the work.

If Emacs is implemented in C, then the shell is implemented in machine
language.  The Emacs interface that users see is written in a combination
of C (most of the character-level I/O, and the Lisp interpreter) and ELisp
(most of the commands).  Similarly, the shell is implemented in C, but the
commands that users type are implemented in a mixture of mostly C and shell
script.

>> The major advantage of lisp over C here is the fact that
>> lisp is much more easily extensible.
>
>Yep, and the major advantage of sh over C here is the fact that sh is
>much more easily extensible. Do I conclude that sh is written in sh?
>Yes or no?

I think this is a flawed analogy.  When dealing with the shell, we normally
distinguish the shell itself from the commands it executes (ignoring
built-in shell commands), since the commands aren't directly associated
with the shell -- if you change your search path, the command set changes.
Emacs, however, starts up with a large collection of Lisp-written commands
and functions built in, and many of them are fundamental to the operation
of the editor.  The shell will continue to run without any of the shell
scripts that people ordinarily use, but Emacs will fall flat on its face
without some of the Lisp functions.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar