Links: Functional programming ebooks

In a subscribe Spb Haskell User Group I've met several interesting links to files garbage with books on the functional programming.

I've dig out Introduction to Functional Programming by Mike Gordon. Judge by the first chapter a lot of text and samples but less mathematics is expecting further. Such a real programmers book.

I do not understand somehow what do they want...

Find an example to show that if V₁=V₂ then even if V₂ is not free in E₁ it is not necessarily the case that
(\V1 V2.E)E₁E₂ = E[E₁/V₁][E₂/V₂]

Links: Lisp without parentheses in book

It is recommended to fans of rubber women, alcohol-free beer and lisp without parentheses - G J Chaitin THE UNKNOWABLE

CONTENTS
   1. A Hundred Years of Controversy Regarding the Foundations of Mathematics
   2. LISP: A Formalism for Expressing Mathematical Algorithms
   3. Gödel's Proof of his Incompleteness Theorem
   4. Turing's Proof of the Unsolvability of the Halting Problem
   5. My Proof that You Can't Show that a LISP Expression is Elegant
   6. Information & Randomness: A Survey of Algorithmic Information Theory
   7. Mathematics in the Third Millennium?
   8. Bibliography 

An excellent example of how a good idea can be spoiled. After removing parentheses an author has to comment every(!) line of a source code... otherwise everything is completely confusing.

Running over it, I started to mess about just on the phrase

[is set empty?]

The first thought is... aha it's usual thing - besides parenthesis we add square brackets for easing of understanding. I.e. after translating to human language we get:

(define (is v p)
  (p v))

(define empty? null?)

(is set empty?)

Oops... it turned out it was just a comment. Further it's getting worse huge sconses instead of one call of list, strange "'.

For educational purposes Lisp-1 can be used resolutely, and functions and usual variables may not be separated.

SQL Programming Style

I've finished «SQL Programming Style» by Joe Celko. Chapter about scales and measures is great, I'll read it again.
I laughed a lot at the book pages telling what won't do. I'm fully agree with it. All negative examples I'm watching in the real life.

The author's devotion to natural keys seemed very strange to me.

Argument against it — very often the appearance of a natural key is the result of concrete stage of a workflow. When building database scheme based on natural key we implicitly specify the actions order. Business rules are changed a little - oops, on basic stages we lost the key.

But in general the book is consist as it is expected from the title of personal rules of code writing style. Too many moot points...