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!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: Why do people like C? (Was: Comparison: Beta - Lisp)
Message-ID: <Cx3zo5.5sE@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <CwJ82u.7nL@csfb1.fir.fbc.com> <Cwsvrs.Dtv@cogsci.ed.ac.uk> <780822729snz@wildcard.demon.co.uk>
Date: Mon, 3 Oct 1994 18:07:17 GMT
Lines: 90

In article <780822729snz@wildcard.demon.co.uk> cyber_surfer@wildcard.demon.co.uk writes:
>In article <Cwsvrs.Dtv@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk "Jeff Dalton" writes:
>
>> >C's conceptual machine model is similar to that of the most common
>> >beginner/teaching languages, BASIC and Pascal, without many of the
>> >limitations of those languages. 
>> 
>> I'd be interested in hearing what people think this conceptual
>> machine model is.  I suspect that Lisp could be explained in 
>> terms of that model or one fairly similar to it.
>
>That's exactly how I think of it. [...]

>> I also wonder how people learning C understand certain things.
>> For instance, if a variable has type int, there are a couple
>> of ways to think of this:
>> 
>>   * It ensures that you can assign only ints to it.
>
>Um, doesn't the compiler ensure that the result of an expression will
>be coerced to an int, if that's possible? If it's not possible, then
>the compiler complains. 

Just so.  That's how it ensures it.  I meant in C, BTW.

>   I don't know what CL is supposed to do, as
>that's never been clear to me, even after reading CTtL1/2. I assume
>that it's handled at runtime by the interpreter, but I've no idea
>what the compiler is supposed to do about it.

Neither *has* to do anything.  I suspect that many interpreters
ignore type declarations, though some (e.g. Lucid) check.  Compilers
often allocate fixnums and some other types specially (directly as
ints in registers or on the stack).  It may depend on the optimization
settings.  I'm not sure whether the standard specifies anything in
particular.

>>   * It says how to interpret the bits at the address that corresponds
>>     to the variable (including how many of them are part of the var's
>>     value).
>
>I'm also unsure about this. 

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.
That's all I meant anyway.  Again I meant in C, not CL.  Or,
rather, in the model used to understand C.

>I know, Steele's book isn't enough. I should read the ANSI CL doc.
>I would, but it's too big for me, so I don't have a copy of it.
>Hopefully, it'll someday be available on a CD-ROM, along with
>any other useful Lisp documents (like CTtL).

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

>> BTW, there's a clash between Basic and C when it comes to strings.
>> Strings are much easier to deal with in a good Basic (to my mind, at
>> least), but the required machine-level model is fairly complex.
>
>Arrays are similar. In interpreted Basics in the early 80, I could
>redimension an array at runtime. In a compiled Basic for the same
>dialect, the array would have to be statically dimensioned. There's
>no really good reason for this, but that's how compiler writers
>chose to do it.

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.

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

>> Do novice programmers normally study the hardware instruction set?
>> That sounds like a rather hacker-like set of novices to me!
>
>When I began programming, Basic was all I knew, and I thought
>of the machine as running Basic directly! It was a pleasant
>shock to discover that there was another level below that.
>After that, _everything_ became a lot easier!

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.
But I'd be surprised if novices typically learned such things
at / near the start.

-- jeff
