Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: The powerlessness of Lisp
Message-ID: <2328:Mar2819:54:2491@kramden.acf.nyu.edu>
Date: 28 Mar 91 19:54:24 GMT
References: <1991Mar26.165516.13035@daffy.cs.wisc.edu> <26146:Mar2804:56:5791@kramden.acf.nyu.edu> <1991Mar28.064405.13664@Think.COM>
Organization: IR
Lines: 29

In article <1991Mar28.064405.13664@Think.COM> barmar@think.com (Barry Margolin) writes:
> Note, however, that this is not portable, but I'm not sure the original C
> code was, either.

Yes, it *is* portable in C, provided that buf is aligned as an int. I'll
grant that Common Lisp has as much pointer support as Ada---i.e., the
operations necessary to regard memory as a set of bytes was grafted on
afterwards, with so few guarantees that you cannot write portable code
in it.

> 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.

Nope, none at all in pty's case, except the common idiom #ifdef BSD
#include <limits.h> #endif isolated in one include file. Everything else
is a configuration option to select among available libraries. I think
this is rather typical of both systems code and non-systems code in C.

  [ comments about whether Emacs is written in elisp or in C ]

I see your point, but, as I've said before: I refuse to admit that you
can change any fundamental characteristics of a language simply by
adding a library. Sure, the GNU Emacs distribution comes with a lot of
elisp code, without which you'd be insane to use the system. But that
elisp code is on *top* of the Emacs program. Emacs is written in C, and
no amount of library writing can change this fact.

---Dan