Newsgroups: comp.lang.lisp
From: cyber_surfer@wildcard.demon.co.uk (Cyber Surfer)
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!news.sprintlink.net!demon!wildcard.demon.co.uk!cyber_surfer
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
References: <35urdq$31p@relay.tor.hookup.net> <Cwsy26.Et2@cogsci.ed.ac.uk> <36g8e6$2f4@relay.tor.hookup.net> <Cx5xsA.681@cogsci.ed.ac.uk>
Organization: The Wildcard Killer Butterfly Breeding Ground
Reply-To: cyber_surfer@wildcard.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
Lines: 112
Date: Thu, 6 Oct 1994 14:19:41 +0000
Message-ID: <781453181snz@wildcard.demon.co.uk>
Sender: usenet@demon.co.uk

In article <Cx5xsA.681@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk "Jeff Dalton" writes:

> In any case, someone learning Lisp doesn't have to learn everything
> at once, so I don't see why closures have to be an obstacle.

Agreed. In fact, the 2nd ed of Winston and Horn avoids some of the
CL semantics of closures. This was probably so that their code could
work with Golden CL, which I believe used dynamic scoping at the time.
Is that an example of what were saying about closures, if GCL didn't
support them?

I wonder if AutoLisp supports closures? It wouldn't have to, even
if it would be handy if it did. I've seen an embedded language in
another CAD program that didn't support closures, and I can't even
recall if it used lists.

> I find this very odd.  Doing calculations on paper gives a useful
> model for C but not for Lisp?

I think it could still be done for Lisp. I'm reading a book about
Hope that shows each step in a calculation, and there's no reason
to say that it can be done in Hope but not in Lisp.

Since the languages I'm familiar with are all procedural at some
level, this can be done, but that may be because I'm thinking of
what the implementation does, not the language. There must, however,
be a point at which I won't know how the implementation works,
and I learned Lisp long before I ever used it, so the model I used
back then is likely to have been simpler than the one I use now.

> The C compiler manipulates programs.  Do people suppose it works
> in a mysterious way?  Don't they think "cat" and "grep" are programs?

I know that some of my friends have no idea how a compiler works.
In the same way, I have no idea how some other things work.

> When I was in high school, I wrote a Lisp interpreter in Basic.
> It was a couple of pages long.  I couldn't have written a C compiler,
> or at least I'd have found it much harder.  I'm surprised that you
> think a C compiler might be easier.

I wrote my first compiler in Basic. It dumped the screen to a
source file, along with the code to load and display the screen
image. The rest of the Basic code created a logo on the screen,
and then ran the compiler. The last step was to run the assembler.

Now I do similar things in Lisp, C, Forth etc. The main difference
is that Lisp and Forth make the implementation of a "compiler"
much easier, as it has a lot of leverage. All of Forth is part
of the Forth compiler, even if you don't exactly intend it to be.
You have to either tell Forth not to create a header for the word,
or remove it later. The reason I say that your word will be part
of the Forth compiler is because of the way the compiler and text
interpreter may be the same code in many Forths. There's no single
monolithic unit of code that can be identified as "the compiler".

In a similar way, in CL you could claim that CL some functions
and all macros perform the same function. Because of the limited
way they interact, there's a lot of information hiding. One macro
doesn't need to know what another macro does, or how it does it.
If it needs to look at the expanded code, it can call macroexpand.
That kind of decoupling makes it very easy to write "compilers".
 
> >Interactive environments like lisp and smalltalk are clearly winners over
> >the compile/link/debug cycle of C (or the compile/link/reboot cycle in
> >Windows -- yes, it is even more dramatic in windows).  However, some
> >of these C/C++ compilers on PCs are getting awfully fast.
> 
> I was thinking of the interactive rather than the speed.

So was I. ;-) For me, interactive _is_ speed. Perhaps a better
word to use is immediate, as you can see the result of an expr
immediately, rather than after compiling and then running the
code.

>   let a$ = b$
>   let a$ = "b$"
> 
> Would you now say quotation in Basic is "in support of manipulating
> software by programs"?

It could if your Basic has an Eval function, as some do, but
you'd still do all your "software manipulation" thru string
processing. That might be great in SNOBOL4, but I'd hate to try
it in Basic. Of course, I did first design my first interpreter,
as a thought experiment, in Basic. I didn't write it then, as
I had no idea what an interpreter could be used for, but I
remember imagining how to use arrays to simulate the memory
for operators and operands. I later used that idea in a Lisp
compiler/interpreter, with the addition of a stack. I expect
I could have done that in Basic instead of C, but I didn't
have good enough Basic at that time (it had too many bugs
and was hideously slow, even for a token-based Basic).

> >I think we will always have languages for programming hardware
> >and languages for programming software.
> 
> I think it's an interesting data point that I spend lots of time
> programming in Lisp, also program in C, and find that position odd.

Plus, it's possible to program for hardware in Lisp and Prolog
etc. In fact, you could say that the VIPER CPU was designed
using a declarative language interpreted by Prolog, and then
compiled by Prolog into silicon, via a CAD/CAM system. If that
can be done, however "badly" (it produced a 1 Mhz CPU), then
I can believe anything is possible.

Years ago I heard someone say, "You can do anything in Forth.
All you have to do is implement it." I suspect that this is
also true of many other languages, including Lisp. Some people
are busy proving it!

