[sf-lug] K & R errata

[Jeff Bragg]

Let's try this again, to the list this time (sorry for the repeat, Jim).

Ken,
I think I should be fine, from what you're telling me; so far, I haven't
really had compile-time problems with variable declarations/definitions,
save when I was (well ahead of the topic's introduction in my reading of
K&R) trying to re-familiarize myself with something like proper pointer
declaration/usage (which was never that familiar to me anyway).

Jim,
I don't know the answer to that question, though I would also be interested
in it, if someone has it in broad strokes.

I did, however, think of something related to real-world usage of functional
programming languages (relating to our brief conversational digression
towards Haskell).  Erlang, a similar functional programming language,
started life as a telecom language (at Ericsson), and today is used in a few
major projects where concurrency, distribution, and/or message passing are
critical.  For reasons I only passingly understand (related mostly to the
type system employed, I think), it is supposedly less mathematically
rigorous than Haskell (and perhaps some others, like OCaml), which is to
say, if I understand correctly, that it is a less faithful implementation of
or the calculi/logic systems and type/constraint systems that serve as the
theoretical underpinning of at least some other languages classified as
"functional".  The consequences of such deviations from purity are probably
not that relevant, provided you aren't, for instance, trying to implement
"provers" (of mathematical theories), as some folks do in Haskell and a
handful other languages.

Erlang is sort of exceptional in its inclusion in some major projects, as I
can't think of another functional language that has a noticeable market
presence; maybe to some degree Clojure (a LISPy language targeting the JVM
and CLR) or F# (assuming it is regarded as truly functional; I know very
little about it, as it's connections to the Microsoft world limit my
interest in it), but little else that seems to be getting anywhere, as far
as I can tell.  One of Erlang's selling points is legendary uptime, and the
ability to do some rather cool things (assuming you planned a little for it
and hooked in support for it) like updating running code _without_
restarting the server; the new code just kicks in at the first request to be
serviced after it is added.  Also, since it is very much "functional" in
that variables are variables in the mathematical sense (single-assignment),
this bit of functional purity is theorized to be much of the reason for the
legendary uptime (no possibility of cross-process/-object contamination due
to actor model/message passing rather than shared memory, fewer
opportunities for race conditions).  I'm not saying it's particularly
practical; it still often requires a very different approach, which is not
easily won, and can make solving messy, real world problems seem more
difficult (and sometimes it truly is).  Nevertheless, it's an example of a
functional programming language that was conceived and implemented in and
for the real world for practical (if specialized) use, rather than in
academia as a tool for teaching language construction/design/theory.

On Sun, Jul 3, 2011 at 3:13 PM, jim <jim at systemateka.com> wrote:

>
>
> I think declaring a variable is
> type identifier, e.g.
> int i;
>
> and defining a variable is
> type identifier assign value, e.g.
> int j = 3;
>
> declaring a function (not in K&R) is prototyping
> type identifier argtypes, e.g.
> int doit(int, char *);
>
> defining a function is
> type identifier arguments block, e.g.
> int doit(int k, char * s) { while (k--) puts(s); }
>
>
>    As to when memory is actually reserved is puzzling
> (to keep it simple, stick to variables):
>
>    when it encounters a variable declaration, the c
> compiler updates its symbol table to record the
> identifier (name of the variable) and its type.
>    when it encounters a variable definition, the c
> compiler updates its symbol table and is forced to
> enter the assigned value somewhere in the region that
> will ultimately be (in) the data segment.
>
>    (assuming the above is more or less correct) the
> puzzling part has to do with the optimizing pass of the
> compiler and the linking pass. any c compiler must
> correctly implement the specification of the c language
> but may do so however its designers choose. there is no
> requirement that the compiler "allocates" memory at any
> particular point in the process.
>    the compiler may set up images of segments for
> machine code (the text segment), data, and the stack(s)
> during its compile phase or defer that work until it's
> in the optimizing phase.
>    regardless, it may "allocate" memory for a declared
> variable or not, depending on the variable's status as
> global or as local within some function. it will likely
> defer such allocation until it has determined that the
> variable is used at some point in the program's flow (or
> issue a warning of an unused identifier).
>    the optimizing stage may do the allocation or change
> the compile-pass allocation (possibly determining that
> the variable needs no allocation in the data segment).
>    the linker (or link phase) may revise any and all
> uses of memory, likely reorganizing the data segment
> into sub-segments (e.g. constants all together, ints all
> together, strings all together...).
>
>    put succinctly, who could ever say?
>    the language designers themselves were careful to
> keep I/O and platform and compiler designs out of the
> specification.
>    i present the above respectfully as a question: what's
> the actual answer?
>
> with thanks
>
>
>
>
> On Sun, 2011-07-03 at 14:30 -0700, Ken Shaffer wrote:
> > Jeff,
> > My memory of the item in the K &R C Programming book which was wrong
> > was jogged by scanning the errata:  I think the problem involved the
> > definition vs. declaration of a variable, and when memory actually was
> > reserved.  I did pass my copy of the book along, so I can't check my
> > margin notes.
> > Ken
> > _______________________________________________
> > sf-lug mailing list
> > sf-lug at linuxmafia.com
> > http://linuxmafia.com/mailman/listinfo/sf-lug
> > Information about SF-LUG is at http://www.sf-lug.org/
>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20110703/4c192c9d/attachment.html>