(defmacro compose (&rest functions)
  (labels ((compose-sexp (functions var)
             (cond
               ((null functions) var)
               ((symbolp (car functions))
                (list (car functions) (compose-sexp (cdr functions) var)))
               (t
                (list 'funcall (car functions) (compose-sexp (cdr functions) var))))))
    `(lambda (x) ,(compose-sexp functions 'x))))

(defmacro define (name expression)
  `(progn (setf (symbol-function ',name) ,expression)
          (setf (documentation ',name 'function)
                ',(format nil "~S is a function defined with DEFINE~%Source: ~S"
                          name expression))
          ',name))

;; These ones still use parameters; you only need to write more utility functions
;; to be able to easily write them in functional style too.
(defun transpose    (x) (apply (function mapcar) (function list) x))
(defun apply-to-all (f) (lambda (x) (mapcar (lambda (y) (apply f y)) x)))
(defun insert       (f) (lambda (x) (reduce f x)))

;; Here is inner-product = (insert +) o (apply-to-all x) o transpose

(define inner-product
    (compose (insert (function +))  (apply-to-all (function *))  transpose))

(inner-product '((1 2 3) (4 5 6)))
 --> 32

user=> (defn inner-product [x] (apply + (apply map * x)))

Lisp does not do functional level programing. Can't. Nor does almost
all the well known functional langs such as Ocaml, Haskell,
Mathematica.

See:
http://en.wikipedia.org/wiki/Function-level_programming

I learned about it last year. See:
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/87935...

I quote:

hard to summarize in one sentence... but basically like functional
programing but with one characteristic formalism that sets it apart,
namely: creation of functions are limited to a particular set of
higher-order functions, and you cannot arbitrary birth functions
(e.g.  the moronicity of lisp's macros).

The force of this particular formalism is that it makes it more
subject to mathematical analysis (and thus makes it more powerful and
flexible), similar to for example to the clear separation of features
in 2nd order logic from first order logic. Wikipedia said it best,
quote:

«This restriction means that functions in FP are a module (generated
by the built-in functions) over the algebra of functional forms, and
are thus algebraically tractable. For instance, the general question
of equality of two functions is equivalent to the halting problem, and
is undecidable, but equality of two functions in FP is just equality
in the algebra, and thus (Backus imagines) easier.»

«Even today, many users of lambda style languages often misinterpret
Backus' function-level approach as a restrictive variant of the lambda
style, which is a de facto value-level style. In fact, Backus would
not have disagreed with the 'restrictive' accusation: he argued that
it was precisely due to such restrictions that a well-formed
mathematical space could arise, in a manner analogous to the way
structured programming limits programming to a restricted version of
all the control-flow possibilities available in plain, unrestricted
unstructured programs.»

--------------------------------

This thread, illustrates, how often comp lang fanatics propagate
patently false things, in their fanaticism. This, includes those
lispers who are regulars at comp.lang.lisp. (other similar issues, is
how lisp syntax is regular, and how lisp are adept at lisp
manipulation)

  Xah
∑ http://xahlee.org/

And yeah, you don't need to have DEFMACRO in your function-level
programming package either. Why would you?