[sf-lug] K & R errata

[jim]

Thanks both. 
    my blurb on declare/define, i think, has little 
or no practical value. i'm in the middle of teaching 
a C seminar, so that stuff is on my mind, and i'm 
interested in the truth of things, especially if i've 
got any of it wrong. 
    your blurb on haskell/erlang is just right for me, 
more and more thanks. if i ever go functional, i'll 
first turn to erlang. 


On Sun, 2011-07-03 at 16:31 -0700, Jeff Bragg wrote:
> 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/
> 
> _______________________________________________
> 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/