Lisp functions are not math functions. Lisp functions are pieces of interpreted or compiled Lisp code and AFAIK there is no way to compare the math semantics of Lisp function objects other than to write a set of tests and compare the results.

Also note that (equalp next1 next2) does not compare two

SYMBOL-FUNCTIONs (the function objects), instead it compares the

SYMBOL-VALUEs (the variable values) of the symbols NEXT1 and NEXT2. To compare the function objects of the symbols NEXT1 and NEXT2 you need to write:

- Code: Select all
`(equalp #'next1 #'next2) => NIL`

This also results NIL because

EQUALP compares two different

SYMBOL-FUNCTION objects, bound to two different Lisp symbols, NEXT1 and NEXT2.

In ANSI-CL, there is

FUNCTION-LAMBDA-EXPRESSION, returning the textual definition of a Lisp function object as a list, but only if this information is available at all. With high

OPTIMIZE settings a Lisp compiler is free to strip out this information from compiled Lisp function objects, in which case

FUNCTION-LAMBDA-EXPRESSION just simply returns NIL.

Here is what happens with SBCL 1.0.59 (and default

OPTIMIZE settings):

- Code: Select all
`CL-USER> (defun next1 (x) (+ x 1))`

NEXT1

CL-USER> (defun next2 (y) (+ y 1))

NEXT2

CL-USER> (function-lambda-expression #'next1)

(SB-INT:NAMED-LAMBDA NEXT1

(X)

(BLOCK NEXT1 (+ X 1)))

NIL

NEXT1

CL-USER> (function-lambda-expression #'next2)

(SB-INT:NAMED-LAMBDA NEXT2

(Y)

(BLOCK NEXT2 (+ Y 1)))

NIL

NEXT2

You see that even if

FUNCTION-LAMBDA-EXPRESSION returns useful results, you still need to write some code to find out if the math semantics of the textual function definitions are equal or not. In Lisp, such a program is called a "code walker" (ask Google about it).

- edgar