Re: Malcolm's new book - Chapter 1 review


"Eric Sosman" <Eric.Sosman@xxxxxxx> wrote in message news:1186440511.431078@xxxxxxxxxxx
Malcolm McLean wrote On 08/06/07 15:55,:
The book begins with a non-conforming implementation of
strlen(). It's kind enough to point out the nonconformity,
and goes on to provide a conforming replacement -- but one
wonders what purpose the bogus version serves, other than
to add thickness to the book.

The non-conforming implementation is an example of the book's style. It is not written in C that happens to conform to the standards of the day, but in C which I expect to still compile and work in a hundred years' time.

The book's implementation of mystrdup() compels a C99
compiler to emit diagnostics.

You repeat this several times. What you mean is that the function bodies are given without headers. As you delve into deeper chapters you will soon see why this is - text interspersed with code means that the headers make too much visual mess without adding enough information content to justify inclusion.
The problem is that by saying "a C99 compiler is compelled to emit diagnostics" rather than "I think it would have been better to include headers and prototypes" you really disqualify yourself as an objective commentator.

At about this point, the text draws attention to some
coding conventions. Among them: the use of the identifier
`answer' to hold a function's return value. Oddly enough,
this mention is the last appearance of "answer" in the
chapter; the rest of the functions do not follow the
stated convention.

The convention applies for the whole book. "answer" isn't absolutely uniform, but it is my normal choice for a variable to hold a return value.

There follows a peculiarity: A day-of-the-week function
that the author confesses he does not understand. The code
was "lifted from the net," says the book, but does not say
whether it was lifted from a reliable or from an unreliable
source. The text says it's all right to use a function you
don't understand, provided you "trust the author" -- but
since the author is unnamed, we do not have the means to
tell whether he is trustworthy.

Exactly. If you are doing very advanced programming then either you have to be brillinat and encyclopedic, or you have to use code you don't understand. Not an ideal situation, but it is very often necessary to do that.

The book next offers two macros (mentioning two more,
but not implementing them). The most obvious thing about
the book's macros is that their names consist entirely of
lower-case letters. While this is legal in C, it is far
more usual to name macros in upper-case -- some coding
standards, in fact, insist on this. The macros the book
offers aren't wrong, exactly, just in poor taste.

They are function-like macros. Unfortunately some of the arguments are evaluated twice - a sng with the C macro system. I find lower case more tasteful than upper

x = clamp(x, 0, 255);

is far easier on the eye than

x = CLAMP(x, 0, 255);

The upper case gives the macro an emphasis it shouldn't have.

The chapter closes with an argument that putting code
in libraries that can be shared by many programs is a Bad
Thing; the "right" way to re-use code is to paste a copy
wherever you happen to need one. (No, I am not making this
up!) And just for laughs, the chapter ends with an English
error.

Cut and paste is generally a far superior method. Libraries are fine if you are implemeting something fundamental like OpenGL, but not when you need a list of dependencies in your code. No one wants to link in five libraries all with conflicting definition of "bool" just to use a few string functions.

Statistical summary of "Some Simple Functions:"

- Number of function implementations shown: ten

- Number of functions that require compile-time
diagnostics: five

- Number of functions with bugs (beyond required
diagnostics) spotted by this reader: four

Need to check those bugs.

- Number of functions with bugs known to the author
(but published anyhow): one

- Number of macro implementations shown: two

- Number of bad macro implementations shown: two

- Influence of this more extensive reading on the
reader's opinion of the book: negative

Thanks for the input.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

.

Relevant Pages

  • Re: Problem with the lambda form
    ... ...but you actually changed the internals of two implementations, so this is an example where the claim that you can implement any language feature using just macros does not hold. ... If you want an embedded language that is implemented strictly by macros, you can have one, but it may need its own explicit stack, its own explicit GC, or similarly. ... If you want a language extension, don't require it to be "implemented strictly by macros", and do want to not have to alter the compiler or other development tools or the runtime's binaries, then shadowing eval is perfectly legitimate. ... Another way to regain some portability may be to find out what redefining eval actually does on various CL implementations, and write per-platform code appropriately, awkward though that may be. ...
    (comp.lang.lisp)
  • Re: Two newbie questions about Scheme implementations
    ... "Teach Yourself Scheme in Fixnum Days" tutorial, ... I'm also working on learning macros. ... Several implementations support this, and I've made a few simple ones. ...
    (comp.lang.scheme)
  • Re: macrolet like flet
    ... the local macros may not call one another." ... Only the body of the _expander_ can be relevant, ... I really don't like it when implementations make me put in (locally ... rationale for not making free variables defaultly special wasn't to ...
    (comp.lang.lisp)
  • Re: macrolet like flet
    ... the local macros may not call one another." ... Only the body of the _expander_ can be relevant, ... I really don't like it when implementations make me put in (locally ... rationale for not making free variables defaultly special wasn't to ...
    (comp.lang.lisp)
  • Re: Scheme macros
    ... > macros were likely to use. ... It almost sounds like it was so that Common Lisp could be ... redefinition of Lisp symbols and preventing accidental redefinition ... implementations do differ on the behavior of macro expansions. ...
    (comp.lang.lisp)