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: <1991Mar29.064102.24914@Think.COM>
Date: 29 Mar 91 06:41:02 GMT
References: <26146:Mar2804:56:5791@kramden.acf.nyu.edu> <1991Mar28.064405.13664@Think.COM> <2328:Mar2819:54:2491@kramden.acf.nyu.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 80

In article <2328:Mar2819:54:2491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
[Regarding my Lisp translation of '*(int *)&buf = n':]
>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.

I guess we are now stuck on agreeing what "portable" means.  After
executing:

	char buf[sizeof int];
	*(int *)&buf = 1;

what is the value of buf[0]?  On some machines it will be 0, on other
machines it will be 1, and some strange machines could produce other
values.

I admit that it's *more* portable than the Lisp translation; the C code has
implementation-dependent results, whereas the Common Lisp version has
undefined consequences.  Indeed, you'll notice that my example used FIXNUM
rather than INTEGER as the type of the displaced array, because a Lisp
Machine will signal an error if you try to store a bignum, or any
non-immediate data type, into an array displaced to a character array.

I believe Fortran 77 also disallows equivalencing character arrays with
other data types.

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

When you say "select among available libraries", are you implying that all
the libraries are available in all the Unix implementations that pty runs
on, and it's the choice of the user running the configuration script which
one to use?  Or did you mean "select among possibly available libraries"?
If the latter, I thought that was the kind of dependencies that were being
described; whether the choice is made by a configuration script or #ifdef
directives seems like an insignificant detail.

Don't different Unix flavors have different naming schemes for pseudotty
devices?  I don't think SunOS has any libraries that deal specifically with
pseudotty's; every SunOS program I've ever seen that uses them contains an
inlined loop to find an available pty, open it, fork, etc.  It's really a
shame, because they each have different assumptions about the maximum
number of possible ptys, and frequently have to be updated when we increase
the number of ptys.

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

I just remembered another difference.  The Emacs that end-users run is
created by starting up a bootstrap program that is written in C and
contains the Elisp interpreter and the C portions of the editor, loading in
Lisp libraries, and dumping the memory image out into an executable file.

By your reasoning, a program that I implement by loading code into Lucid
Lisp and dumping out the image is written in the language that Lucid Lisp
is written in, even though I might not even know how to program in that
language!
--
Barry Margolin, Thinking Machines Corp.

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