Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!EU.net!uknet!festival!jeff
From: jeff@festival.ed.ac.uk (J W Dalton)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
References: <CwJ82u.7nL@csfb1.fir.fbc.com> <Cwsvrs.Dtv@cogsci.ed.ac.uk> <780822729snz@wildcard.demon.co.uk> <Cx3zo5.5sE@cogsci.ed.ac.uk> <781301566snz@wildcard.demon.co.uk>
Message-ID: <CxBFF1.28C@festival.ed.ac.uk>
Organization: Edinburgh University
Date: Fri, 7 Oct 1994 18:30:36 GMT
Lines: 143

cyber_surfer@wildcard.demon.co.uk (Cyber Surfer) writes:

>In article <Cx3zo5.5sE@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk "Jeff Dalton" writes:

>> There are 32 bits in a longword at some location.  They can be
>> interpreted as an int, as a float, as a pointer, etc.  The type
>> of the var that corresponds to that location says what they are.

>Assuming a CPU with a 32bit word for longs, of course. That implies
>that an int would be 16bit. You're also assuming that a long will
>be the same size as a pointer. I never make explicit assumptions
>like that in my C code, as it will be wrong on some machines.

I know all that.  But writing something that's exactly right
in general, rather than describing a simple example, would take
too long.  I assumed people could vary it to suit.

Now, in fact, 32 bits in a longword does not imply 16-bit ints.
Think of a VAX.  "Longword" is VAX terminology.  "Word" continued
to mean 16-bits, as on a PDP-11.

>> That's all I meant anyway.  Again I meant in C, not CL.  Or,
>> rather, in the model used to understand C.

>In one model used to understand C.

Well, what are the hardware models people keep talking about.
I still await an explanation.

> Sadly, I have to use more than
>one model, as some CPUs are rather odd. The Intel x86 family, for
>example. ;-) I usually use "real mode", but when I can, I prefer
>to use the 32bit protected mode. The size of a pointers and ints
>are different, depending on the CPU mode chosen for the program,

The idea that hardware fits C seems rather odd to me.  For
instance, Basic's "if <cond> then <line number>" is closer to
what the hardware's like.

Note too that the hardware's data is (usally) typeless.  Whether
some bit are a float or a pointer depends on what instructions
are used to operate on them.  This is similar to what happens
in an "everything is a list" Lisp.  This analogy was frequently
made in the past, but went out of favor as the various freedoms
of assembly code (self-modifying, typeless) were increasingly
seen as "bad".

>CL hides all of this from the programmer. An implementation might
>eveal some of it, but I've yet to use a Lisp that does that. If
>CL code run by CLISP can distinguish between 32bit "flat" pointers
>and 32bit far segmented pointers, I've yet to find a way to do it,
>and I'd be very suprised if it could use both.

C code can't distinguish either.  All the type info is compiled
away, as you no doubt know.  I don't really understand what you're
getting at here.

>> The ANSI doc is on the net, somewhere.  I think Barmar said where
>> a short while back.

>Yes, but 3 MB is too big for me. What file format is it in, anyway?

LaTex and .dvi.

>> That's interesting.  In my experience, you could typically redim the
>> array but only within its original total size.  So only the address
>> calculation, not the size, was dynamic.

>I don't remember that feature, but it's still only a variation of
>static allocation. If I understand what you're saying correctly.

Just so.  What I find interesting is that arrays were treated so
differently from strings.

>> For some reason, a number of languages (C, some Basics, some Lisps,
>> ...) treat arrays in a more "static" way than similar types (structs
>> in C, strings in Basic).

>With Basic, it really depends on the compiler. There are so many
>dialects that I've never seen two compatible systems. With CL, I
>might distinguish between the language and the compiler, but with
>Basic, I could only do that with ANSI Basic and an implementation.
>I've yet to ever use an implementation of ANSI Basic, so I can't
>comment on it.

There was always a language description that could have been
followed: Basic Nth edition, from Dartmouth.  This is roughly
analogous to the Lisp 1.5 book plus various manuals for particular
Lisp languages/implementations.  But for both Basic and Lisp,
implementors seldom felt constrained to follow such descriptions.
I find this interesting as well and would be interested in comments.

I suspect that the ease of implementing Basic and Lisp was an
important factor.  That is, it was fairly easy to implement a
Basic or a Lisp.  Why try to match another exactly when you
could make your task easier -- or add your own neat features --
by inventing a variant?

>> I find it difficult to judge how much difference it makes to learn
>> assembler.  I did learn an assembly language fairly early on, and
>> I'm not sure how difficult things would have been if I hadn't.

>I wouldn't want anyone to beging to learn programming at that
>level. I'm currently reading Roger Bailey's Hope tutorial, and
>the idea of teaching programming with Hope is one that appeals
>to me a lot. It might not have features like arrays, but that
>might actually _help_ the teaching process, rather than hinder it.

But some people have, evidently, encountered hardware-level
stuff rather early-on.  I haven't seen this Hope tutorial
(is it available on the net?) but it sounds like the kind
of thing that appeals to the mathematically inclined but
perhaps not the the raised-on-hardware types?

>> But I'd be surprised if novices typically learned such things
>> at / near the start.

>The point where I learned about the CPU was when I had to.
>I was beginning to outgrow Basic, and the "Basic" model was
>certainly holding me back. It was difficult to imagine what
>the machine was doing.

Why did you care what the machine was doing?  I'm not saying
you shouldn't, just asking the reasons.

I'm glad I learned assembler for a couple of machines, but I
don't have much desire to do the same again, and I've never
cared very much about the hardware details (logic circuits
and the like).

>Curiously, I could do all of that in Cambridge Lisp, on my 3rd
>machine. Not only that, but the code performed as fast as if
>I'd written it in C. That Lisp had no trouble interfacing to
>the OS, but then, it had a decent FFI, while the Basic on my
>first machine didn't. 

Can you remember what the FFI looked like?  Could you manipulate
C structs in Lisp or what?

BTW, I find it amusing that "foreign" seems to mean "C"
these days (though perhaps not in _your_ usage).

-- jeff
