Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!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: <429:Mar3122:07:4191@kramden.acf.nyu.edu> Date: 31 Mar 91 22:07:41 GMT References: <1991Mar28.064405.13664@Think.COM> <2328:Mar2819:54:2491@kramden.acf.nyu.edu> <1991Mar29.064102.24914@Think.COM> Organization: IR Lines: 44 In article <1991Mar29.064102.24914@Think.COM> barmar@think.com (Barry Margolin) writes: > 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. So what? Just because code is portable doesn't mean it will produce the same results on different machines. What's 32767 * 32767 in Ada? The code works, is useful, and has well-defined results under any C compiler. It can't be translated into portable Lisp code. > Or did you mean "select among possibly available libraries"? Yep, that one. It is not a failure of C that different C platforms provide different nonstandard libraries, and an application that can take advantage of such libraries is hardly ``loaded with machine-dependent #ifdefs.'' > 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. Yes, it is, and wouldn't it be a lot simpler if all these assumptions were isolated in a couple of configuration options in a single program? > 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! No. I didn't say elisp code was written in C. I said Emacs was written in C. Just because it happens to come with a whole bunch of elisp add-ons doesn't change the language Emacs is written in. Would you say C is written in C, just because C platforms come with a whole bunch of libraries that C programs can use? ---Dan